2017-05-27 0:12 GMT+03:00 Nikolay Aleksandrovich Pavlov <zyx....@gmail.com>:
> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>
>> 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 <b...@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.
>>
>> 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.
>
> Not sure I understood what exactly you suggest to disable/restore. All
> mappings at once with one command? I would actually disagree here: I
> need something similar for translit3, but it only remaps
> single-character mappings, leaving most of other user mappings alone.
> One mapping at a time? It would be good, but given that request is
> temporary remapping naming the functionality enable/disable looks
> strange. And there are still issues with determining {lhs}.
>
> One of the logical variants would be `:map <push> {lhs}
> {new-rhs}`/`:unmap <push> {lhs}`+`:map <pop> {lhs}`, but this is hard
> to implement and is rather limited, though less limited then
> enable/disable everything variant.
>
> I would instead suggest a function mappings_dump()/mappings_add():
> first is similar to `nvim[_buf]_get_keymap` and should dump all
> mappings as a list of maparg()-like dictionaries. Second should define
> mappings being given a list of them. Of course, this means that
> dictionaries need to be fixed to allow correctly saving/restoring.
>
> The advantages:
>
> 1. Easier to implement. Code for creating a maparg() dictionary is
> already there, iterating over all mappings is not a problem. Results
> needs to be incompatible with maparg() or use additional keys though:
> e.g. Neovim altered the contents of `noremap` and `buffer` keys: first
> is now 0, 1 or 2 (you can’t correctly restore a mapping if you can’t
> distinguish `map <script>` and `noremap`) and second is a buffer
> number or zero.
> 2. More flexible: you can save and restore everything, push or pop
> individual mappings, create a temporary mapping which is just like
> mapping X, but has `<Plug>(Translit3TemporaryMap)` lhs instead (to be
> returned from `<expr>` mappings in order to select either plugin
> behaviour or fall back to previously present user mapping instead).
>
> I can imagine other usages enable/disable or push/pop could not
> achieve: generating configuration with mappings like :mkvimrc, but
> allows doing adjustments (parsing `:mkvimrc` output is not fun,
> especially if you want to be forward compatible), creating a plugin
> which analyses how often different mappings are used (need to copy all
> mappings to temporary then replace existing mappings with plugin
> ones).
BTW, when we come at it: is not there *already* a code which gets lhs
and rhs in determenistic format for `:mkvimrc`? It should be possible
to just reuse it.
> 3. This is also forward compatible: just need to state in the
> documentation that new significant keys may be added in the future to
> the dictionaries so they should be preserved.
>
>>
>> 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.
>>
>> --
>> 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 -- b...@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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
