Re: Avoiding the escape timeout
Christian Brabandt
On Sa, 23 Okt 2010, Andy Koppe wrote:
> On Oct 22, 12:37�pm, Andy Koppe wrote:
> > On Oct 22, 9:38�am, Christian Brabandt wrote:
> > > Do you have 'x' present in your cpoptions?
> > >
> > > If you do, that is the default
> > > behaviour of <ESC> in command mode to execute the typed command.
> >
> > Ah, so it looks like a mapping to <ESC> bypasses the vim default of
> > cancelling the command and instead goes straight to the vi behaviour
> > of executing the command, irrespective of the 'x' flag in cpoptions.
> > Is that as intended?
> >
> > I also stumbled across what looks like a solution: map the application
> > escape keycode to ^C instead when in command line (or insert) mode:
> >
> > let &t_ti.="\e[?7727h"
> > let &t_te.="\e[?7727l"
> > noremap <Esc>O[ <Esc>
> > noremap! <Esc>O[ <C-c>
> >
> > Does that make sense?
>
> More to the point, is it possible to map that keycode in such a way
> that the 'x' option is respected? Mapping to <C-c> of course does not
> do that. And is it a bug that mapping to <Esc> triggers the vi
> compatibility behaviour of accepting rather than cancelling a command
> line, even if the 'x' option isn't set?
All I can say is, this happens on purpose. It doesn't feel right, but
may be there is a reason for it. If I read the code correctly, the
following patch "fixes" it:
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -740,7 +740,7 @@
#endif
if (c == '\n' || c == '\r' || c == K_KENTER || (c == ESC
- && (!KeyTyped || vim_strchr(p_cpo, CPO_ESC) != NULL)))
+ && vim_strchr(p_cpo, CPO_ESC) != NULL))
{
/* In Ex mode a backslash escapes a newline. */
if (exmode_active
regards,
Christian