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

Re: Problem with patch 274

Expand Messages
  • 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 1 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 2 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 3 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.