Loading ...
Sorry, an error occurred while loading the content.
 

Problem with patch 274

Expand Messages
  • Frederic Hardy
    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
    Message 1 of 7 , Dec 30, 2009
      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-322
      Compiled by fch@...
      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



      --
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • Dominique Pellé
      ... 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
      Message 2 of 7 , Dec 30, 2009
        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)

        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

        --
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
      • Frederic Hardy
        ... cw is instantaneous for me. The problem appear only then i m inserting text at the place of string ogoUnitTest , after class keyword. ... I have the
        Message 3 of 7 , Dec 31, 2009
          Dominique Pellé wrote:
          > 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)
          >
          cw is instantaneous for me.
          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
          >
          I have the problem when i'm starting vim with vim -u NONE -U NONE and
          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)
          >
          I have installed vim from freeBSD ports, which not apply all available
          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.

          --
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
        • Lech Lorens
          ... [...] ... 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
          Message 4 of 7 , Jan 4, 2010
            On 30-Dec-2009 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.
            >
            [...]
            >
            > 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

            --
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
          • Bram Moolenaar
            ... 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,
            Message 5 of 7 , Jan 5, 2010
              Lech Lorens wrote:

              > On 30-Dec-2009 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.
              > >
              > [...]
              > >
              > > 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.

              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 -- Bram@... -- 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 ///

              --
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
            • Ben Fritz
              ... 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
              Message 6 of 7 , Jan 6, 2010
                On Jan 5, 5:25 am, Bram Moolenaar <B...@...> 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
                ... 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
                Message 7 of 7 , Jan 6, 2010
                  Ben Fritz wrote:

                  > On Jan 5, 5:25=A0am, Bram Moolenaar <B...@...> 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."

                  /// Bram Moolenaar -- Bram@... -- 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 ///
                Your message has been successfully submitted and would be delivered to recipients shortly.