Bram,
Life's been a bit hectic lately (as I'm sure you'd find familiar
:-)), and I haven't had a chance to follow up regarding the
various options for the idea below. The original patch provided
a Vim option to control the behavior of buffer-local mappings
that have global mappings as prefixes. The modified patch below
removed the idea of a new Vim option.
If there is anything you'd like me to adjust about either patch
to make the change suitable for inclusion, please let me know.
Thanks,
Michael Henry
On 01/30/2013 09:14 AM, Michael Henry wrote:
> On 01/29/2013 04:33 PM, Bram Moolenaar wrote:
>> I do not like the behavior to depend on timing. I would prefer the
>> local mapping to always take precedence, also when another character was
>> already typed that causes a global mapping to match. Otherwise the
>> behavior depends on how busy your computer is, or the remote connection.
>
> Agreed. The patch eliminates the dependence on timing, which I
> see as a good thing, too.
>
>> Even better would be if we do not need an option at all. Every option
>> makes it more difficult for a Vim user to understand what's happening.
>
> Agreed.
>
>> So would it be "the right thing to do" to always let local mappings
>> overrule any matching global mapping? It's a slightly incompatible
>> change though. But the current behavior is bad enough to accept that
>> (you need to type another chacter to stop waiting for the possibility
>> that the global mapping would match).
>
> I'd be in favor of making the behavior non-optional. Here is a
> modification to the patch that removes the option.
>
> Michael Henry
>
> diff -r 274c841f033a runtime/doc/map.txt
> --- a/runtime/doc/map.txt Fri Jan 25 20:11:01 2013 +0100
> +++ b/runtime/doc/map.txt Wed Jan 30 09:13:18 2013 -0500
> @@ -654,6 +654,18 @@
> you type slowly, or your system is slow, reset the 'timeout' option.
> Then you
> might want to set the 'ttimeout' option.
>
> + *map-precedence*
> +Buffer-local mappings (defined using |:map-<buffer>|) take precedence
over
> +global mappings. When a buffer-local mapping is the same as a global
> mapping,
> +Vim will use the buffer-local mapping. In addition, Vim will use a
> complete
> +buffer-local mapping immediately, even if a longer global mapping has the
> +buffer-local mapping as a prefix. For example, given the following two
> +mappings: >
> + :map <buffer> \a :echo "Local \a"<CR>
> + :map \abc :echo "Global \abc"<CR>
> +The buffer-local mapping \a will be used immediately. Vim will not
> +wait for more characters to see if the user might be typing \abc.
> +
> *map-keys-fails*
> There are situations where key codes might not be recognized:
> - Vim can only read part of the key code. Mostly this is only the first
> diff -r 274c841f033a src/getchar.c
> --- a/src/getchar.c Fri Jan 25 20:11:01 2013 +0100
> +++ b/src/getchar.c Wed Jan 30 09:13:18 2013 -0500
> @@ -1912,6 +1912,7 @@
> mapblock_T *mp;
> #ifdef FEAT_LOCALMAP
> mapblock_T *mp2;
> + int expecting_global_mappings;
> #endif
> mapblock_T *mp_match;
> int mp_match_len = 0;
> @@ -2093,6 +2094,7 @@
> /* First try buffer-local mappings. */
> mp = curbuf->b_maphash[MAP_HASH(local_State, c1)];
> mp2 = maphash[MAP_HASH(local_State, c1)];
> + expecting_global_mappings = (mp && mp2);
> if (mp == NULL)
> {
> mp = mp2;
> @@ -2116,6 +2118,20 @@
> #endif
> (mp = mp->m_next))
> {
> +#ifdef FEAT_LOCALMAP
> + 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;
> + }
> +#endif
> /*
> * Only consider an entry if the first character
> * matches and it is for the current state.
>
--
--
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.
