On Jun 29, 2013 3:59 PM, "Bram Moolenaar" <[email protected]> wrote:
>
>
> Nikolay Pavlov wrote:
>
> > On Jun 29, 2013 1:04 AM, "Bram Moolenaar" <[email protected]> wrote:
> > >
> > >
> > > ZyX wrote:
> > >
> > > > Steps to reproduce:
> > > >
> > > >     vim -u NONE -c 'set keymap=hebrew' -c 'inoremap ,, \' -s <(<<<
$'i,,\e')
> > > >
> > > > . Expected output is
> > > >
> > > >     \
> > > >
> > > > in buffer, actually seen
> > > >
> > > >     תת
> > > >
> > > > . If you use my patch and add `-c 'set wgm'` you will see what was
> > > > expected. Likely the same prior to vim-7.3.1179.
> > >
> > >
> > > So the problem is that you have both:
> > >
> > >         :imap ,
> > >         i  ,,          * '
> > >         :lmap ,
> > >         l  ,           *@ת
> > >
> > > If you remove the last then the other works again:
> > >
> > >         :lunmap <buffer> ,
> > >
> > > So, you have conflicting mappings.  The problem is that you didn't
> > > explicitly specify one of them.  We could not do this for lmaps.
> > >
> > > Try this patch:
> > >
> > > *** ../vim-7.3.1257/src/getchar.c       2013-06-12 21:00:18.000000000
+0200
> > > --- src/getchar.c       2013-06-28 21:29:14.000000000 +0200
> > > ***************
> > > *** 2134,2141 ****
> > >                             if (expecting_global_mappings && mp2 ==
NULL)
> > >                             {
> > >                                 /* This is the first global mapping.
If we've
> > > !                                * got a complete buffer-local match,
use it. */
> > > !                               if (mp_match)
> > >                                     break;
> > >                                 expecting_global_mappings = FALSE;
> > >                             }
> > > --- 2135,2144 ----
> > >                             if (expecting_global_mappings && mp2 ==
NULL)
> > >                             {
> > >                                 /* This is the first global mapping.
If we've
> > > !                                * got a complete buffer-local match
that is
> > > !                                * not from lmap, use it. */
> > > !                               if (mp_match != NULL
> > > !                                        && (mp_match->m_mode &
LANGMAP) == 0)
> > >                                     break;
> > >                                 expecting_global_mappings = FALSE;
> > >                             }
> >
> > This won't work if I have two *maps: buffer-local and global. One
example
> > is translit3 and various leader mappings (translit3 maps nearly any
ASCII
> > printable character including backslash and comma). Second is using
> > quickfix and q as a leader. Guess more will emerge as users update.
> >
> > We do need an option.
>
> An option won't work to solve these problems and still have buffer-local
> mappings work properly.  We need an argument on the mapping itself.
> After all, the problem to be solved is that some buffer-local mappings
> don't take effect until another character is typed.

Is not it solved with timeout* setting?

I do not see any problems here: *any* mapping does not take effect until
the next character is typed if it prefixes another mapping. Why
buffer-local mappings always do not have to wait? Using timeout with the
problem described in initial discussion is better solution then current
state. I can additionally suggest to create :map-<final> (same as current
variant, but applies to one mapping only) or repeat the suggestion for
making my option buffer-local. But the current state is not a fix.

> --
> I still remember when I gave up Smoking, Drinking and Sex.  It was the
> most *horrifying* hour of my life!
>
>  /// Bram Moolenaar -- [email protected] -- 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 [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Raspunde prin e-mail lui