On Fri, May 26, 2017 at 12:43 PM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> Brett Stahlman wrote:
>
%--snip--%
>>
>> Yes. Very much like that. I'm implementing a sort of transient mode, in
>> which I'll "shadow" existing maps with very short (generally single
>> character) mappings, which are expected to be ambiguous/conflicting with
>> existing maps, and even builtin operators. Of course, when I exit the
>> transient mode, I'd need to restore the mappings that were shadowed.
>>
>> The global and builtin maps are not a problem, since the transient maps use
>> <buffer> and <nowait>; however, without parsing the output of one of the :map
>> functions, I have no way of knowing which buf-local mappings will be ambiguous
>> with the transient maps I'm defining. And parsing the :map output is
>> problematic for the reasons already mentioned: e.g., no way to tell the
>> difference between function key <F8> and the corresponding 4 characters. I'd
>> actually considered taking some sort of iterative approach: e.g., trying all
>> possible permutations of lhs as input to maparg() and testing the results, in
>> an attempt to deduce the canonical form, but this would be extremely messy,
>> and I don't even know whether it would be deterministic... The maplist()
>> function you mentioned, if it returned all ambiguous left hand sides in
>> canonical form, or even a list of the corresponding maparg()-style
>> dictionaries, would be perfect. Of course, there would also need to be a way
>> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the maparg()
>> or maplist() dictionary.
>
> OK, so for this you would use maplist() to get the list of mappings to
> disable, use maparg() to get the current mapping, clear the mapping, do
> your stuff, then restore the cleared mappings. You then need to make
> sure you restore the mappings exactly as they were, even when your
> "stuff" fails miserably.
>
> It's a lot easier if we would have a way to temporarily disable
> mappings. It's mostly the same as above, but you won't need to use
> maparg() to get the current mapping and the restore operation. Instead
> you would disable instead of clear, and later re-enable instead of
> restore. Still need to make sure the re-enbling does happen, no change
> in that part.
>
> Big advantage is that if we evern add functionality to mappings, it will
> keep working, while your save/restore pair probably fails.
>
> Ah, your later post goes in the same direction.
Yes. My thinking exactly. No need to translate back and forth between
internal and external representations if it's not too difficult to
provide a clean interface supporting sensible map operations at a
higher level.
So then maplist() would return a list of handles of some sort (rather
than a list of lhs)? I suppose the interface could even support
functions for mapping a handle to the information currently returned
in the maparg() dictionary (but perhaps with lhs/rhs in canonical
form) - unless you feel that would be leaking too much internal
state... I guess the bottom line is that if there is still a valid use
case for remapping/executing the rhs returned by maparg(), there
should probably be a way to obtain it in a more deterministic format.
E.g., I'm thinking this example (from the help on maparg()) might be
susceptible to breakage if user changes 'cpo' after mappings have been
created...
exe 'nnoremap <Tab> ==' . maparg('<Tab>', 'n')
To make this sort of operation safer, the map interface could provide
an "execute" function, which would allow you to execute even a
currently disabled or shadowed map on demand. Something along the
lines of what might be achieved with maparg(), :normal!, or even
feedkeys(), but cleaner and safer. At any rate, the enable/disable
functions would suffice for the save/restore use case I described...
Thanks,
Brett S.
>
> --
> DENNIS: Look, strange women lying on their backs in ponds handing out
> swords ... that's no basis for a system of government. Supreme
> executive power derives from a mandate from the masses, not from some
> farcical aquatic ceremony.
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
> /// Bram Moolenaar -- Bram@Moolenaar.net -- 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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment