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

Re: Vim hangs with insertion after long line

Expand Messages
  • Bram Moolenaar
    ... There are several other one-character matches. Do they not cause a problem? ... Not a nice solution. ... Yeah, this pattern is a problem. It matches
    Message 1 of 17 , Feb 13, 2013
    • 0 Attachment
      Christian Brabandt wrote:

      > Hi oldcapecod!
      >
      > (CC'ing HTML indent maintainer)
      >
      > On Mo, 11 Feb 2013, oldcapecod wrote:
      >
      > > OK, all that's needed is ...
      > >
      > > filetype plugin indent on
      > >
      > > in the .vimrc file.
      >
      > The indent html file causes this. There are actually two problems there.
      >
      > First the indent-expression already matches <img> tags, while it should
      > only match <i> tags. This can be circumvented by this patch:
      >
      > --- html.vim.orig 2013-02-12 12:57:48.416440086 +0100
      > +++ html.vim 2013-02-12 13:41:30.609442857 +0100
      > @@ -63,7 +63,7 @@
      > call <SID>HtmlIndentPush('h4')
      > call <SID>HtmlIndentPush('h5')
      > call <SID>HtmlIndentPush('h6')
      > -call <SID>HtmlIndentPush('i')
      > +call <SID>HtmlIndentPush('i[^m]') " don't match img tag
      > call <SID>HtmlIndentPush('iframe')
      > call <SID>HtmlIndentPush('ins')
      > call <SID>HtmlIndentPush('kbd')

      There are several other one-character matches. Do they not cause a
      problem?

      > Second, the HtmlIndentOpen and HtmlIndentClose() function use expansive
      > regular expressions, that make vim hang on very long lines. We can tweak
      > the RE a little bit (using \%( instead of \() but this doesn't help here
      > much, so instead I would propose to generally skip lines that are, say
      > longer > 1000 chars:

      Not a nice solution.

      > Alternatively, we could skipt the expansive .\{-} part (I am not sure,
      > how essential this part is, it looks at a first glance superfluous and
      > causes the many expansive backtracking to happen many many times:

      Yeah, this pattern is a problem. It matches anything of any length.
      It would be much faster to first find a match with a:pattern and only
      then look back for what's before it.

      Still have a long pending job of making the fast RE code work properly
      and test it...


      --
      It is illegal to take more than three sips of beer at a time while standing.
      [real standing law in Texas, United States of America]

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Christian Brabandt
      Hi Bram! ... Can t we just have an experimental setting, that enables experimental features, e.g. the new fast RE? This would get this feature a lot more
      Message 2 of 17 , Feb 13, 2013
      • 0 Attachment
        Hi Bram!

        On Mi, 13 Feb 2013, Bram Moolenaar wrote:

        > Still have a long pending job of making the fast RE code work properly
        > and test it...

        Can't we just have an 'experimental' setting, that enables experimental
        features, e.g. the new fast RE? This would get this feature a lot more
        testing and we could check, whether it suffers the same bug (otherwise
        we never know, when this feature has enough testing to be ready to be
        included).

        (Also, patches to the regular expression engine like the last patch
        /[^\n] that shouldn't match linebreaks possibly also need to be applied
        to the new RE engine).

        regards,
        Christian
        --

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bram Moolenaar
        ... The idea was to have a whitelist for the pattern. If it passes that then use the new RE code, otherwise fall back to the old stuff. Gradually the
        Message 3 of 17 , Feb 13, 2013
        • 0 Attachment
          Christian Brabandt wrote:

          > On Mi, 13 Feb 2013, Bram Moolenaar wrote:
          >
          > > Still have a long pending job of making the fast RE code work properly
          > > and test it...
          >
          > Can't we just have an 'experimental' setting, that enables experimental
          > features, e.g. the new fast RE? This would get this feature a lot more
          > testing and we could check, whether it suffers the same bug (otherwise
          > we never know, when this feature has enough testing to be ready to be
          > included).
          >
          > (Also, patches to the regular expression engine like the last patch
          > /[^\n] that shouldn't match linebreaks possibly also need to be applied
          > to the new RE engine).

          The idea was to have a "whitelist" for the pattern. If it passes that
          then use the new RE code, otherwise fall back to the old stuff.
          Gradually the whitelist would get longer.

          Main thing still to do is testing. We can't really expect users to just
          run in bugs all the time. It's complicated stuff. Don't want the same
          long time bug fighting as we had with the conceal mode.
          For testing we would have a way to force the old or new RE engine,
          and compare the results.

          --
          Why is "abbreviation" such a long word?

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ an exciting new programming language -- http://www.Zimbu.org ///
          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Christian Brabandt
          Hi Bram! ... Ok. But my idea is to have it included and only use it, if users explicitly set the experimental option. So by default users would still use the
          Message 4 of 17 , Feb 13, 2013
          • 0 Attachment
            Hi Bram!

            On Mi, 13 Feb 2013, Bram Moolenaar wrote:

            >
            > Christian Brabandt wrote:
            >
            > > On Mi, 13 Feb 2013, Bram Moolenaar wrote:
            > >
            > > > Still have a long pending job of making the fast RE code work properly
            > > > and test it...
            > >
            > > Can't we just have an 'experimental' setting, that enables experimental
            > > features, e.g. the new fast RE? This would get this feature a lot more
            > > testing and we could check, whether it suffers the same bug (otherwise
            > > we never know, when this feature has enough testing to be ready to be
            > > included).
            > >
            > > (Also, patches to the regular expression engine like the last patch
            > > /[^\n] that shouldn't match linebreaks possibly also need to be applied
            > > to the new RE engine).
            >
            > The idea was to have a "whitelist" for the pattern. If it passes that
            > then use the new RE code, otherwise fall back to the old stuff.
            > Gradually the whitelist would get longer.
            >
            > Main thing still to do is testing. We can't really expect users to just
            > run in bugs all the time. It's complicated stuff. Don't want the same
            > long time bug fighting as we had with the conceal mode.
            > For testing we would have a way to force the old or new RE engine,
            > and compare the results.

            Ok. But my idea is to have it included and only use it, if users
            explicitly set the 'experimental' option. So by default users would
            still use the old, working RE, but users that like to test and
            contribute can enable the new RE engine so that the new RE engine can be
            tested more easily.

            regards,
            Christian
            --
            Der Mensch wird ohne Grundsätze, aber mit der Fähigkeit geboren, sie
            alle in sich aufzunehmen.
            -- François Marie Voltaire

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Ben Fritz
            ... I like this idea. I d be happy to turn the option on and run with it as long as I had the ability to revert to the old mode when needed if I run into a
            Message 5 of 17 , Feb 13, 2013
            • 0 Attachment
              On Wednesday, February 13, 2013 4:57:15 PM UTC-6, Christian Brabandt wrote:
              >
              >
              > Ok. But my idea is to have it included and only use it, if users
              >
              > explicitly set the 'experimental' option. So by default users would
              >
              > still use the old, working RE, but users that like to test and
              >
              > contribute can enable the new RE engine so that the new RE engine can be
              >
              > tested more easily.
              >

              I like this idea. I'd be happy to turn the option on and run with it as long as I had the ability to revert to the old mode when needed if I run into a problem. Then we also don't need to worry about a whitelist. Just keep it as an "experimental" feature and people know to turn it off (and submit a bug report!) if they run into situations where it doesn't work.

              --
              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Bram Moolenaar
              ... Question is, if you run into a problem, how do you know you have to turn off that option? If syntax highlighting is off it might be obvious, but when some
              Message 6 of 17 , Feb 14, 2013
              • 0 Attachment
                Ben Fritz wrote:

                > On Wednesday, February 13, 2013 4:57:15 PM UTC-6, Christian Brabandt wrote:
                > >
                > >
                > > Ok. But my idea is to have it included and only use it, if users
                > >
                > > explicitly set the 'experimental' option. So by default users would
                > >
                > > still use the old, working RE, but users that like to test and
                > >
                > > contribute can enable the new RE engine so that the new RE engine can be
                > >
                > > tested more easily.
                > >
                >
                > I like this idea. I'd be happy to turn the option on and run with it
                > as long as I had the ability to revert to the old mode when needed if
                > I run into a problem. Then we also don't need to worry about a
                > whitelist. Just keep it as an "experimental" feature and people know
                > to turn it off (and submit a bug report!) if they run into situations
                > where it doesn't work.

                Question is, if you run into a problem, how do you know you have to turn
                off that option? If syntax highlighting is off it might be obvious, but
                when some plugins behave badly you might not have a clue.

                --
                [The rest of the ARMY stand around looking at a loss.]
                INSPECTOR END OF FILM: (picks up megaphone) All right! Clear off! Go on!
                "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ an exciting new programming language -- http://www.Zimbu.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --
                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php

                ---
                You received this message because you are subscribed to the Google Groups "vim_dev" group.
                To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              • Christian Brabandt
                Hi Bram! ... Anybody that uses such an option should be aware, that this can have consequences. So I would expect the first thing to do when one notices
                Message 7 of 17 , Feb 14, 2013
                • 0 Attachment
                  Hi Bram!

                  On Do, 14 Feb 2013, Bram Moolenaar wrote:

                  > Question is, if you run into a problem, how do you know you have to turn
                  > off that option? If syntax highlighting is off it might be obvious, but
                  > when some plugins behave badly you might not have a clue.

                  Anybody that uses such an option should be aware, that this can have
                  consequences. So I would expect the first thing to do when one notices
                  something strange to turn that option off.

                  regards,
                  Christian
                  --
                  Ich gehe jetzt in den Birkenwald,
                  denn meine Pillen wirken bald.

                  --
                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php

                  ---
                  You received this message because you are subscribed to the Google Groups "vim_dev" group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                • François Ingelrest
                  ... I think as well that such an option could be a good idea, not just for RE but for any bigger changes that strives to be eventually included into the main
                  Message 8 of 17 , Feb 14, 2013
                  • 0 Attachment
                    On Thu, Feb 14, 2013 at 12:54 PM, Christian Brabandt wrote:
                    >> Question is, if you run into a problem, how do you know you have to turn
                    >> off that option? If syntax highlighting is off it might be obvious, but
                    >> when some plugins behave badly you might not have a clue.
                    >
                    > Anybody that uses such an option should be aware, that this can have
                    > consequences. So I would expect the first thing to do when one notices
                    > something strange to turn that option off.

                    I think as well that such an option could be a good idea, not just for
                    RE but for any bigger changes that strives to be eventually included
                    into the main development line. I'm sure many people on this list
                    would go for experimental just to help testing new features. I
                    personally don't have enough time to help in Vim development, but I'm
                    always happy to run into various issues and report them.
                    "experimental" could be a compilation option as well to avoid having
                    both "old" and "new" code compiled into the program. It should be
                    reported with bug reports like any other compilation option (just as
                    in "happens with big features but not with tiny").

                    --
                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php

                    ---
                    You received this message because you are subscribed to the Google Groups "vim_dev" group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                    For more options, visit https://groups.google.com/groups/opt_out.
                  • Ben Fritz
                    ... With a runtime configurable option I d be able to test at work where I actually exercise Vim more rigorously just because I use it for more stuff. I doubt
                    Message 9 of 17 , Feb 14, 2013
                    • 0 Attachment
                      On Thursday, February 14, 2013 6:54:39 AM UTC-6, François Ingelrest wrote:
                      >
                      > I think as well that such an option could be a good idea, not just for
                      >
                      > RE but for any bigger changes that strives to be eventually included
                      >
                      > into the main development line. I'm sure many people on this list
                      >
                      > would go for experimental just to help testing new features. I
                      >
                      > personally don't have enough time to help in Vim development, but I'm
                      >
                      > always happy to run into various issues and report them.
                      >
                      > "experimental" could be a compilation option as well to avoid having
                      >
                      > both "old" and "new" code compiled into the program. It should be
                      >
                      > reported with bug reports like any other compilation option (just as
                      >
                      > in "happens with big features but not with tiny").

                      With a runtime configurable option I'd be able to test at work where I actually exercise Vim more rigorously just because I use it for more stuff. I doubt I'd go to the trouble of installing two different versions of Vim at work, and I know I don't compile myself at work, at least not for Windows. I'm toying with the idea of compiling a version for running on our Solaris servers, because the one provided by IT is stuck at version 6.x.

                      --
                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php

                      ---
                      You received this message because you are subscribed to the Google Groups "vim_dev" group.
                      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
                      For more options, visit https://groups.google.com/groups/opt_out.
                    Your message has been successfully submitted and would be delivered to recipients shortly.