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

Re: Setting cedit= causes vimincr :I to fail

Expand Messages
  • Christian Brabandt
    Hi Gary! ... Ah, I misunderstood the problem. But why not simply use ? But I don t have a solution to this problem. We could check, that the cedit key has
    Message 1 of 9 , Mar 19, 2013
    • 0 Attachment
      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>.

      Ah, I misunderstood the problem. But why not simply use <CR>?

      But I don't have a solution to this problem. We could check, that the
      cedit key has been typed by the user and is not coming from a macro or
      using :exe normal command. But this breaks mappings that might want to
      use the cedit key.

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

      Indeed. Although, this might not work correctly in <expr> mappings.

      regards,
      Christian
      --

      --
      --
      You received this message from the "vim_use" 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_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • 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 2 of 9 , Mar 19, 2013
      • 0 Attachment
        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_use" 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_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+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 3 of 9 , Mar 19, 2013
        • 0 Attachment
          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_use" 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_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+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.