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

Re: Vim hangs with insertion after long line

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