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. 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.
