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

Re: Setting cedit= causes vimincr :I to fail

Expand Messages
  • 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 1 of 9 , Mar 19 3:01 PM
    • 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.