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

Re: Setting cedit= causes vimincr :I to fail

Expand Messages
  • Christian Brabandt
    Hi Gary! ... Here is a patch, that makes :norm! ignore the cedit key, while :norm behaves as is. regards, Christian -- Wer die Menge unbedeutender
    Message 1 of 4 , Mar 19, 2013
      Hi Gary!

      On Di, 19 Mär 2013, Gary Johnson wrote:

      > On 2013-03-19, Christian Brabandt wrote:
      > > On Tue, March 19, 2013 17:43, Gary Johnson wrote:
      > > > On 2013-03-19, Christian Brabandt wrote:
      > > >> On Fri, March 15, 2013 20:29, Gary Johnson wrote:
      > > >>
      > > >> > Should the function of "!" in :normal and of "nore" in mappings be
      > > >> > extended to also ignore any non-default settings of 'cedit'?
      > > >>
      > > >> I think, plugin writers should take care of properly escaping
      > > >> the cedit key by themselves. That is, if they issue a search like this
      > > >> :exe "norm! /"
      > > >> they need to take care to replace the cedit key by Ctrl-V cedit key.
      > > >
      > > > But the writer in this case was not trying to use the cedit key--he
      > > > was innocently using another key (<Esc>) that I had chosen to be the
      > > > cedit key.
      > >
      > > I don't see, how this is different from other settings that might
      > > interfer plugins (e.g. 'gdefault', 'magic', 'remap', 'ed').
      >
      > That's why I suggested that the plugin function save the current
      > 'cedit' setting, set the default, do the work of the function, then
      > restore the original setting before returning.
      >
      > > Say you don't want to use the search() function,
      > > but want to use
      > > :exe variable
      > > with variable being something like 'norm! /....<Esc>'
      > >
      > > There shouldn't be a problem with first substituting that variable by
      > > :let variable = substitute(variable, &cedit, '^V'.&cedit, 'g')
      > > where ^V is the literal Ctrl-V (and not the 2 distinct characters ^ and V)
      >
      > Maybe I'm just being thick this morning--haven't even finished my
      > first coffee--but I don't think you understand the problem. The
      > 'cedit' key is used to open the command-line window. The plugin
      > writer doesn't want to open the command-line window. The plugin
      > writer doesn't even care that command-line window exists. All he
      > wants to do is execute a normal-mode command that ends with an
      > <Esc>,
      >
      > exe 'norm! /\%'.leftcol."v\<Esc>"
      >
      > which :help says should behave as follows in that context:
      >
      > <Esc> When typed and 'x' not present in 'cpoptions', quit
      > Command-line mode without executing. In macros or
      > when 'x' present in 'cpoptions', start entered command.
      >
      > Instead of getting that documented behavior, the normal-mode command
      > is interpreting that <Esc> as the cedit key and entering the
      > command-line window. The plugin writer just wants to execute his
      > command. I don't see any way to escape that <Esc> to make it do
      > what :help says it does and not enter the command-line window when
      > 'cedit' is set to <Esc>.
      >
      > I think if the &cedit character was escaped with ^V as you
      > suggested, that would place a literal &cedit in the text, which is
      > not what the plugin writer wants, either.
      >
      > The only solution I see, without modifying Vim as I suggested, is to
      > save and restore 'cedit' as I also suggested.

      Here is a patch, that makes :norm! ignore the cedit key, while :norm
      behaves as is.

      regards,
      Christian
      --
      Wer die Menge unbedeutender ungenial(ischer) Bücher sieht, hält die
      Menschen für noch unbedeutender.
      -- Jean Paul

      --
      --
      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
      ... Thanks. Looks like some stuff was left behind, commented with //. The logic is a bit hard to follow, perhaps typebuf_norm_remap() should only check for
      Message 2 of 4 , Mar 19, 2013
        Christian Brabandt wrote:

        > Hi Gary!
        >
        > On Di, 19 Mär 2013, Gary Johnson wrote:
        >
        > > On 2013-03-19, Christian Brabandt wrote:
        > > > On Tue, March 19, 2013 17:43, Gary Johnson wrote:
        > > > > On 2013-03-19, Christian Brabandt wrote:
        > > > >> On Fri, March 15, 2013 20:29, Gary Johnson wrote:
        > > > >>
        > > > >> > Should the function of "!" in :normal and of "nore" in mappings be
        > > > >> > extended to also ignore any non-default settings of 'cedit'?
        > > > >>
        > > > >> I think, plugin writers should take care of properly escaping
        > > > >> the cedit key by themselves. That is, if they issue a search like this
        > > > >> :exe "norm! /"
        > > > >> they need to take care to replace the cedit key by Ctrl-V cedit key.
        > > > >
        > > > > But the writer in this case was not trying to use the cedit key--he
        > > > > was innocently using another key (<Esc>) that I had chosen to be the
        > > > > cedit key.
        > > >
        > > > I don't see, how this is different from other settings that might
        > > > interfer plugins (e.g. 'gdefault', 'magic', 'remap', 'ed').
        > >
        > > That's why I suggested that the plugin function save the current
        > > 'cedit' setting, set the default, do the work of the function, then
        > > restore the original setting before returning.
        > >
        > > > Say you don't want to use the search() function,
        > > > but want to use
        > > > :exe variable
        > > > with variable being something like 'norm! /....<Esc>'
        > > >
        > > > There shouldn't be a problem with first substituting that variable by
        > > > :let variable = substitute(variable, &cedit, '^V'.&cedit, 'g')
        > > > where ^V is the literal Ctrl-V (and not the 2 distinct characters ^ and V)
        > >
        > > Maybe I'm just being thick this morning--haven't even finished my
        > > first coffee--but I don't think you understand the problem. The
        > > 'cedit' key is used to open the command-line window. The plugin
        > > writer doesn't want to open the command-line window. The plugin
        > > writer doesn't even care that command-line window exists. All he
        > > wants to do is execute a normal-mode command that ends with an
        > > <Esc>,
        > >
        > > exe 'norm! /\%'.leftcol."v\<Esc>"
        > >
        > > which :help says should behave as follows in that context:
        > >
        > > <Esc> When typed and 'x' not present in 'cpoptions', quit
        > > Command-line mode without executing. In macros or
        > > when 'x' present in 'cpoptions', start entered command.
        > >
        > > Instead of getting that documented behavior, the normal-mode command
        > > is interpreting that <Esc> as the cedit key and entering the
        > > command-line window. The plugin writer just wants to execute his
        > > command. I don't see any way to escape that <Esc> to make it do
        > > what :help says it does and not enter the command-line window when
        > > 'cedit' is set to <Esc>.
        > >
        > > I think if the &cedit character was escaped with ^V as you
        > > suggested, that would place a literal &cedit in the text, which is
        > > not what the plugin writer wants, either.
        > >
        > > The only solution I see, without modifying Vim as I suggested, is to
        > > save and restore 'cedit' as I also suggested.
        >
        > Here is a patch, that makes :norm! ignore the cedit key, while :norm
        > behaves as is.

        Thanks. Looks like some stuff was left behind, commented with //.

        The logic is a bit hard to follow, perhaps typebuf_norm_remap() should
        only check for remapping and ex_normal_busy is checked separately?


        --
        Ed's Radiator Shop: The Best Place in Town to Take a Leak.

        /// 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! ... Fixed. regards, Christian -- Es sind nicht die Dinge, die uns beunruhigen, sondern die Meinungen, die wir von den Dingen haben. -- Epiktet
        Message 3 of 4 , Mar 19, 2013
          Hi Bram!

          On Di, 19 Mär 2013, Bram Moolenaar wrote:

          > Thanks. Looks like some stuff was left behind, commented with //.
          >
          > The logic is a bit hard to follow, perhaps typebuf_norm_remap() should
          > only check for remapping and ex_normal_busy is checked separately?

          Fixed.

          regards,
          Christian
          --
          Es sind nicht die Dinge, die uns beunruhigen, sondern die Meinungen,
          die wir von den Dingen haben.
          -- Epiktet (griechischer Stoiker, 50-138 n.Chr.)

          --
          --
          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.
        • Gary Johnson
          ... I applied this patch, backed out the fixes in the visincr plugin, and performed the test I reported initially. The patch fixes the problem. Thank you.
          Message 4 of 4 , Mar 19, 2013
            On 2013-03-19, Christian Brabandt wrote:
            > Hi Bram!
            >
            > On Di, 19 Mär 2013, Bram Moolenaar wrote:
            >
            > > Thanks. Looks like some stuff was left behind, commented with //.
            > >
            > > The logic is a bit hard to follow, perhaps typebuf_norm_remap() should
            > > only check for remapping and ex_normal_busy is checked separately?
            >
            > Fixed.

            I applied this patch, backed out the fixes in the visincr plugin,
            and performed the test I reported initially. The patch fixes the
            problem. Thank you.

            Regards,
            Gary

            --
            --
            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.