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

On Wed, May 24, 2017 at 9:28 AM, Brett Stahlman <brettstahlman@gmail.com> wrote:
> On Wed, May 24, 2017 at 2:08 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>>
>> Brett Stahlman wrote:
>>
>>> On Tuesday, May 23, 2017 at 8:25:33 AM UTC-5, Brett Stahlman wrote:
>>> > On Tue, May 23, 2017 at 4:35 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>>> > >
>>> > > Brett Stahlman wrote:
>>> > >
>>> %--snip--%
>>> > >
>>> > > 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.
>>>
>>> Perhaps mapcheck() could take an optional arg requesting something more than a simple boolean return. When called with this extra arg, mapcheck() could return a conflicting/ambiguous lhs (or list thereof) in some canonical format (possibly determined by the value of the extra arg itself). As long as the format returned could be fed to maparg(), it would be possible to find conflicting mappings, remove them temporarily, and subsequently restore them...
>>
>> If you define a mapping you will want to know whether the mapping
>> already exists and needs to be restored. For that you can use maparg(),
>> no need to use mapcheck().
>>
>> Not sure why you would want to remove "conflicting" mappings. Perhaps
>> when you map the ; key, and the user has ;x mapped? Then you would need
>> a list. Adding a maplist() function would be better than adding
>> arguments to mapcheck().
>
> 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.

One other possibility occurs to me... I haven't looked at the internal
map representation, but I'm guessing it might be possible to return
some sort of "map handle" for ambiguous maps, rather than lhs/rhs in
canonical form. These handles could be passed to functions like
disable_map() and enable_map(), and would preserve the opacity of the
implementation. Just a thought...

Thanks,
Brett S.

>
> Thanks,
> Brett S.
>
>>
>>
>> --
>> Kiss me twice. I'm schizophrenic.
>>
>> /// 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.