Re: Bug/non-determinism in output of maparg() and map commands

On Tue, May 23, 2017 at 4:35 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> Brett Stahlman wrote:
>
>> I would like to be able to save and restore mappings programmatically. In
>> order to do so, however, I need to be able to determine the exact lhs and
>> rhs used to create the mapping. I had assumed the lhs/rhs members of the
>> dictionary returned by maparg() would provided this information, but as the
>> simple example below illustrates, it does not. The problem is that both the
>> 4 character mapping...
>> "<F7>"
>> ...and the single character function key mapping produce the same output
>> for maparg()['lhs'] and `nmap <buffer>'. (The nmap output does at least
>> colorize the function key, but the text output is identical.) The 'rhs'
>> member seems to be treated slightly differently, but still inconsistently:
>> in particular, for the maps created under default 'cpo', 'rhs' looks
>> correct, but for <F9> (created with '<' in 'cpo'), it looks wrong. I
>> suspect what's happening is that 'rhs' is always reporting exactly what was
>> typed, but since in the general case I have no way of knowing what 'cpo'
>> was in effect when the map was created, this isn't very helpful.
>>
>> Is there a programmatic way to determine lhs and rhs in some sort of
>> canonical form? Also helpful would be if hasmapto() (or something like it)
>> told you exactly which lhs was mapped to the specified rhs. (I realize
>> there could be more than one, since hasmapto() doesn't require an exact
>> match, but there's a similar situation with mapcheck(), and it just picks
>> one mapping to return, which can be useful in certain use cases.) More
>> generally, it seems there should be some way to determine a list of lhs
>> from a given rhs...
>>
>> -- Test commands --
>> set cpo&
>> nmap <buffer> <F7> <F7>
>> nmap <buffer> <lt>F8> <lt>F8>
>> set cpo+=<
>> nmap <buffer> <F9> <F9>
>> set cpo&
>>
>> -- Output of nmap and maparg --
>> nmap <buffer>
>> n <F9> @<F9>
>> n <F8> @<F8>
>> n <F7> @<F7>
>>
>> echo maparg('<F7>', 'n', 0, 1)
>> {'silent': 0, 'noremap': 0, 'lhs': '<F7>', 'mode': 'n', 'nowait': 0,
>> 'expr': 0, 'sid': 66, 'rhs': '<F7>', 'buffer': 1}
>> echo maparg('<lt>F8>', 'n', 0, 1)
>> {'silent': 0, 'noremap': 0, 'lhs': '<F8>', 'mode': 'n', 'nowait': 0,
>> 'expr': 0, 'sid': 66, 'rhs': '<lt>F8>', 'buffer': 1}
>> echo maparg('<lt>F9>', 'n', 0, 1)
>> {'silent': 0, 'noremap': 0, 'lhs': '<F9>', 'mode': 'n', 'nowait': 0,
>> 'expr': 0, 'sid': 66, 'rhs': '<F9>', 'buffer': 1}
>
> The best solution is probably to also add the raw rhs, with the terminal
> codes replaced. This won't work when changing the terminal type, but
> that is very unlikely to happen.

You mean adding a key such as "raw_rhs" to the dictionary returned by
maparg()? If so, then yes this would help, but there would still need to
be a way to determine lhs, which is currently even more ambiguous than
rhs. While it's true that I probably already have lhs if I'm calling
maparg(), I need a way to determine which lhs(s) is/are ambiguous with a
given lhs. Mapcheck() gives me only the rhs of the conflicting map. To
save and restore, I'd need to know the lhs in canonical form as well.

When you say "with the terminal codes replaced", do you mean replaced
using method #2 or #3 under :map-special-keys? These both sound as
though they could provide a canonical form for both lhs and rhs, and
unless I'm misunderstanding the paragraph beginning "The advantage of
the second and third method...", these methods would not be broken by a
terminal switch...

Thanks,
Brett S.
>
> --
> ARTHUR: The swallow may fly south with the sun, or the house martin or the
> plover seek warmer hot lands in winter, yet these are not strangers to
> our land.
> SOLDIER: Are you suggesting coconuts migrate?
> "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.