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

On Mon, May 29, 2017 at 3:19 AM, Nikolay Aleksandrovich Pavlov
<zyx.vim@gmail.com> wrote:
[...]
>>>
>>> This is not actually different from the current situation: was needing
>>> to check for `exists('*win_id2win')`, will need to check for existence
>>> of autoload functions (though probably better with EAFP since they are
>>> autoload: run, catch the case when function not exists, assume old
>>> version). The only bad thing is that for some rare cases you would not
>>> be able to construct `bug_present()` condition where you could
>>> previously rely on the availability of Vim patch. Not a big deal I
>>> guess: you better not do this thing anymore in presence of Neovim
>>> which may have neither a bug nor a patch which has fixed a bug (not
>>> actually not have the patch, not have the information available).
>>>
>>> Also while Vim with Bram for some reason does not rely on runtime,
>>> Neovim has a growing set of runtime files required for normal
>>> operation. And we are not against bundling libraries, though I am not
>>> aware of any except for my autoload/shada.vim and autoload/msgpack.vim
>>> which are so far mainly used for standard plugin operation.
>>>
>>> I have programmed for Neovim in VimL, C and lua and can say for sure
>>> that probability of making a hidden bug in C code is far greater then
>>> probability of making a hidden bug in lua or VimL. Especially if you
>>> do refactoring of core functionality (which you will need to in order
>>> to be able to hide mappings) and not just adding methods for accessing
>>> already-existing internal structures (which is all you need for my
>>> proposal; I can bet that diff for necessary functionality may only
>>> contain additions (better actually not though, in order to share some
>>> code with maparg())). Since I do not propose to alter existing
>>> functionality (except for some small refactorings to share code) new
>>> features are most likely to not break anything not using them even if
>>> new bugs are introduced.
>>
>> While I agree that your approach represents fewer changes to Vim's
>> core, and hence, reduced risk of bugs, including but not limited to
>> memory leaks, I don't believe that adding a function like
>> mappings_get_conflicts() - or making mappings_dump() accept some sort
>> of filter specification that allows this case to be handled
>> idiomatically - would result in a dramatic increase in the complexity
>> of the implementation, and I see definite advantages to having Vim
>> implement the logic for ambiguity/conflict detection in its core.
>
> I do not understand the point. *Last few messages I was agreeing on
> that prefix filter would be useful.* Never called this "conflict
> detection" though because who knows what "conflict" may actually mean
> while "filter out mappings which share the same specified prefix" is
> simple to understand.

Depends on what is meant by "ambiguous" and "conflicting", I
suppose... If you define these terms by "shared prefix" only (the way
mapcheck() works today), then...

:nmap <buffer><nowait> foo foo

...would conflict with the following, previously defined global map
(though in fact, there is really no conflict at all):

:nmap foobar foobar

I guess I was envisioning a smarter detection logic, which would
consider modifiers like <buffer> and <nowait>, as well as current
enabled/disabled status, with the goal of answering the following
questions: If I were to create the following map (defined by lhs,
mode(s), scope (buffer/global), <nowait>, etc.), would there be
ambiguity/conflict with any existing maps? And if so, which ones? In
your approach, "disable" is simply "remove/clear", so that check
becomes unnecessary. So you're probably thinking that Vim's map
scoping/shadowing logic is sufficiently simple that the plugin
developer could easily include the applicable checks in his map filter
expression. As things stand now, you may be right, though the idea of
requiring each plugin developer who needs this check to implement the
logic independently still suggests a missing primitive to me. I
concur, however, that the plugin developer would have all the
information he needs to do it himself, provided that the map filter
expression has access to a sufficiently canonicalized lhs: i.e., one
that uniquely represents both multi-byte characters (:help
map-multibyte for special considerations) and special keys (:help
map-special-keys), even across changes to 'encoding' and 'cpo'...

Sincerely,
Brett Stahlman

>
>>
>> Sincerely,
>> Brett Stahlman
>>
>>>
>>>>
>>>> Thanks,
>>>> Brett S.
>>>>
>>>>>
>>>>>>
>>>>>> Sincerely,
>>>>>> Brett Stahlman
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> A village. Sound of chanting of Latin canon, punctuated by short, sharp
>>>>>>>> cracks. It comes nearer. We see it is a line of MONKS ala SEVENTH SEAL
>>>>>>>> flagellation scene, chanting and banging themselves on the foreheads with
>>>>>>>> wooden boards.
>>>>>>>> "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.