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

Re: Vim hangs with insertion after long line

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