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

Re: Vim hangs with insertion after long line

Expand Messages
  • Tony Mechelynck
    ... I know; but it s also about long lines. Best regards, Tony. -- Parallel lines never meet, unless you bend one or both of them. -- -- You received this
    Message 1 of 17 , Feb 12, 2013
    • 0 Attachment
      On 12/02/13 19:48, Lech Lorens wrote:
      > On 12 February 2013 19:01, Tony Mechelynck <antoine.mechelynck@...> wrote:
      >> On 12/02/13 13:59, Christian Brabandt wrote:
      >> [...]
      >>
      >>> 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:
      >>
      >>
      >> maybe tweak it using the 'synmaxcol' option, which stops syntax highlighting
      >> when the cursor abscissa exceeds a user-selectable value?
      >
      > It's about code indenting, not highlighting.
      >
      I know; but it's also about long lines.

      Best regards,
      Tony.
      --
      Parallel lines never meet, unless you bend one or both of them.

      --
      --
      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
      ... 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.