Problem with patch 274
Frederic Hardy
I have a problem with patch 274 about syntax highlighting.
If i'm apply this patch, syntax highlighting become very very very slow
when i'm modifying text in the start of a large fold.
My OS is FreeBSD 7.1-RELEASE-p9.
My vim version (without patch 274) is VIM - Vi IMproved 7.2 (2008 Aug 9,
compiled Dec 30 2009 17:38:06)
Included patches: 1-6, 8-35, 37-48, 50-70, 73, 75-87, 90-92, 94-100,
102-137, 139-149, 151-171, 173-190, 192-193, 195-203, 206-211, 213-215,
217-218, 220-232, 234-246, 251-259, 261-2
73, 275-301, 303-319, 321-322
Compiled by f...@diablo.local
Big version with GTK2 GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +cryptv +cscope
+cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags
+eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float
+folding -footer +fork() -gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
+linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse +mouseshape +mouse_dec
-mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_sysmouse +mouse_xterm
+multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra
-perl +postscript +printer -profile
+python +quickfix +reltime +rightleft -ruby +scrollbind +signs
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl
+terminfo +termresponse +textobjects +title +toolbar +user_commands
+vertsplit +virtualedit +visual +visualextra +viminfo +vreplace
+wildignore +wildmenu +windows +writebackup +X11
-xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-D_THREAD_SAFE -I/usr/local/include/gtk-2.0
-I/usr/local/lib/gtk-2.0/include -I/usr/local/include/atk-1.0 -I/usr/local/
include/cairo -I/usr/local/include/pango-1.0 -I/usr/local/include
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
-I/usr/local/include/pixman-1 -I/usr/local/include/f
reetype2 -I/usr/local/include -O2 -fno-strict-aliasing -pipe
-march=prescott -march=prescott -D_FORTIFY_SOURCE=1
-I/usr/local/include -I/usr/local/include/python2.6 -D_THREAD_SAF
E
Linking: cc -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib
-L/usr/local/lib -o vim -pthread -L/usr/local/lib -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo
-1.0 -lgio-2.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor
-lXcomposite -lXdamage -lpangoft2-1.0 -lXfixes -lcairo -lpango-1.0
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-
2.0 -lglib-2.0 -lXt -pthread -ltermlib -L/usr/local/lib/python2.6/config
-lpython2.6 -lutil -lm -Wl,--export-dynamic
You will find as attachment to this mail my syntax file and a php file
to reproduce the bug.
Just put syntax file in you ~/.vim/syntax directory, open the php file
with vim with patch 274, go to line 24 on word "ogoUnitTest" and do
"cw" and insert something.
All is ok without patch 274, so i'm sure that the problem is in this patch.
Best regards,
Fred
Dominique Pellé
> Hello !
>
> I have a problem with patch 274 about syntax highlighting.
>
> If i'm apply this patch, syntax highlighting become very very very slow
> when i'm modifying text in the start of a large fold.
>
> My OS is FreeBSD 7.1-RELEASE-p9.
>
> My vim version (without patch 274) is VIM - Vi IMproved 7.2 (2008 Aug 9,
> compiled Dec 30 2009 17:38:06)
> Included patches: 1-6, 8-35, 37-48, 50-70, 73, 75-87, 90-92, 94-100,
> 102-137, 139-149, 151-171, 173-190, 192-193, 195-203, 206-211, 213-215,
> 217-218, 220-232, 234-246, 251-259, 261-2
> 73, 275-301, 303-319, 321-32
I'm using Vim-7.2.323 on Linux x86 and for me, going to line 24
in your file ogoUnitTest.php and doing cw command is instantaneous
(24Gcw)
Maybe we have different settings? It would be nice if you could
give the minimal vimrc file which can reproduce the problem
so we can run vim with the same settings using something like:
vim -u minimal-vimrc -c 'norm 24Gcw' ogoUnitTest.php
Also, several patches are missing in your build (7.2.007, 7.2.0036,
7.2.49, etc.) It seems that all missing patches are those flagged
(extra). Not including all patches is not a good idea in my opinion.
Not only you're missing bug fixes, but one patch may very well
depend on an older missing patch. So unless you have a good
reason for skipping patches, I would include all of them till
latest version (currently 7.2.323)
Cheers
-- Dominique
Frederic Hardy
> Frederic Hardy wrote:
>
>
>> Hello !
>>
>> I have a problem with patch 274 about syntax highlighting.
>>
>> If i'm apply this patch, syntax highlighting become very very very slow
>> when i'm modifying text in the start of a large fold.
>>
>> My OS is FreeBSD 7.1-RELEASE-p9.
>>
>> My vim version (without patch 274) is VIM - Vi IMproved 7.2 (2008 Aug 9,
>> compiled Dec 30 2009 17:38:06)
>> Included patches: 1-6, 8-35, 37-48, 50-70, 73, 75-87, 90-92, 94-100,
>> 102-137, 139-149, 151-171, 173-190, 192-193, 195-203, 206-211, 213-215,
>> 217-218, 220-232, 234-246, 251-259, 261-2
>> 73, 275-301, 303-319, 321-32
>>
>
>
> I'm using Vim-7.2.323 on Linux x86 and for me, going to line 24
> in your file ogoUnitTest.php and doing cw command is instantaneous
> (24Gcw)
>
The problem appear only then i'm inserting text at the place of string
"ogoUnitTest", after "class" keyword.
> Maybe we have different settings? It would be nice if you could
> give the minimal vimrc file which can reproduce the problem
> so we can run vim with the same settings using something like:
>
> vim -u minimal-vimrc -c 'norm 24Gcw' ogoUnitTest.php
>
without any ~/.vim directory, so vim settings are not a part of the problem.
The problem occurs with vim and gvim.
> Also, several patches are missing in your build (7.2.007, 7.2.0036,
> 7.2.49, etc.) It seems that all missing patches are those flagged
> (extra). Not including all patches is not a good idea in my opinion.
> Not only you're missing bug fixes, but one patch may very well
> depend on an older missing patch. So unless you have a good
> reason for skipping patches, I would include all of them till
> latest version (currently 7.2.323)
>
patches.
I have no explaination about that, but i think that the port maintener
have a good reason.
Makefile used by freeBSD to compile vim is available here :
http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/vim/Makefile?rev=1.353
Best regards,
Fred.
Lech Lorens
> Hello !
>
> I have a problem with patch 274 about syntax highlighting.
>
> If i'm apply this patch, syntax highlighting become very very very slow
> when i'm modifying text in the start of a large fold.
>
> My OS is FreeBSD 7.1-RELEASE-p9.
>
>
> You will find as attachment to this mail my syntax file and a php file
> to reproduce the bug.
>
> Just put syntax file in you ~/.vim/syntax directory, open the php file
> with vim with patch 274, go to line 24 on word "ogoUnitTest" and do
> "cw" and insert something.
>
> All is ok without patch 274, so i'm sure that the problem is in this patch.
>
> Best regards,
>
> Fred
I haven't observed the behaviour you describe using the syntax file you
attached, but I should note that the fold you at line 24 only has 63
lines, which I wouldn't call large. Perhaps this isn't the file you
intended to attach.
However, Vim indeed gets very slow if I use the default syntax file and
set php_folding=1. This certainly is a consequence of applying the 274
patch, which itself IMHO does not seem to be wrong. The patch causes Vim
to update folds in all the lines from the beginning of the modified area
to the end of the fold in which the modification is being done. It will
take a significant amount of time for large folds but this seems a must
if the folds are to be updated correctly.
I am afraid the whole problem is an example of what I complained about
recently: the slowness of Vim when folding is syntax-based. Speaking of
which, this does not seem to be an issue which can be easily solved (at
least I am unable to come up with a simple solution): I've been trying to
optimise the folding code using a profiler but the results are less than
promising.
--
Cheers,
Lech
Bram Moolenaar
Lech Lorens wrote:
Syntax HL can be slow. It works best when continously moving forward.
When asking for the state before the last requested position it has to
re-sync, which can be very slow. Does this happen for syntax folding?
I haven't looked at the details, but if the problem is that folding is
being updated while inserting text, we could postpone the updating until
Insert mode is ended. The cursor line won't be folded anyway, and
typing more text is likely to change folds again. Moving the cursor
also is counted as leaving Insert mode, this is in stop_insert().
This won't be easy and there might be border cases where we do need to
update folds. E.g., when inserting a line break. But I assume the
speed gain is worth it.
--
From "know your smileys":
:^[/ mean-smiley-with-cigarette
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Ben Fritz
On Jan 5, 5:25 am, Bram Moolenaar <B...@Moolenaar.net> wrote:
> I haven't looked at the details, but if the problem is that folding is
> being updated while inserting text, we could postpone the updating until
> Insert mode is ended. The cursor line won't be folded anyway, and
> typing more text is likely to change folds again. Moving the cursor
> also is counted as leaving Insert mode, this is in stop_insert().
>
You're talking only about waiting to update the syntax folding, not
the syntax highlighting, correct? I really like the idea of postponing
the update of the folding. First, there's the speed issue mentioned
above. Secondly, I often get in the situation where I have carefully
closed various folds in my file, then go to insert a comment or
something else that opens a fold, and all the folds later in the file
get opened automatically. Waiting to update the folds would
potentially help or solve both these issues.
I don't like the idea of waiting until ending insert mode for updating
syntax highlighting, though. I think it would eliminate one of the
most useful features of syntax highlighting, which is a limited on-the-
fly syntax check. You were just talking about the folding, correct?
Bram Moolenaar
Ben Fritz wrote:
> On Jan 5, 5:25=A0am, Bram Moolenaar <B...@Moolenaar.net> wrote:
> > I haven't looked at the details, but if the problem is that folding is
> > being updated while inserting text, we could postpone the updating until
> > Insert mode is ended. =A0The cursor line won't be folded anyway, and
> > typing more text is likely to change folds again. =A0Moving the cursor
> > also is counted as leaving Insert mode, this is in stop_insert().
> >
>
> You're talking only about waiting to update the syntax folding, not
> the syntax highlighting, correct? I really like the idea of postponing
> the update of the folding. First, there's the speed issue mentioned
> above. Secondly, I often get in the situation where I have carefully
> closed various folds in my file, then go to insert a comment or
> something else that opens a fold, and all the folds later in the file
> get opened automatically. Waiting to update the folds would
> potentially help or solve both these issues.
>
> I don't like the idea of waiting until ending insert mode for updating
> syntax highlighting, though. I think it would eliminate one of the
> most useful features of syntax highlighting, which is a limited on-the-
> fly syntax check. You were just talking about the folding, correct?
Correct. Updating the visible text for syntax HL is not that slow. The
problem with folds is that also the text that is folded away must be
inspected for syntax HL.
It can still be slow if syntax HL has to resync after a closed fold.
Depending on the settings it can mean al the folded lines have to be
inspected for syntax HL. E.g. for C a /* inside a fold must be found to
dedice if the lines below the fold are a comment.
--
Warning label on a superhero Halloween costume:
"Caution: Cape does not enable user to fly."