On Wed, May 24, 2017 at 9:28 AM, Brett Stahlman <brettstahl...@gmail.com> wrote: > On Wed, May 24, 2017 at 2:08 AM, Bram Moolenaar <b...@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 <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.
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 -- 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.
