2017-05-29 22:17 GMT+03:00 Brett Stahlman <brettstahlman@gmail.com>:
> 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'...
Still can be put into runtime file if properly implemented. Also from
what I have read all you need to do is find mappings falling into one
of the following conditions:
1. Same mode as your mappings, and exactly the same lhs, and <buffer>.
2. Same mode as your mappings, and lhs which is non-full prefix of
your lhs, and <nowait>.
: basically keeping as much user mappings as you can, but finding
those which may prevent user from accessing your mappings in your
"transient" mode.
While this is more efficient to implement in C, this looks like
something extremely local and not making much sense to actually do
implement it in C in a way other then "find mappings which conflict
with given mapping***s***". Singular would mean iterating and thus not
much gained performance compared to `filter()`-based variant,
"extremely local" means "I do not think other plugin authors would
actually need this to bother with maintaining the solution, be it in C
or VimL":
I have seen plugins which have their pseudo-mode and even wrote one
myself, and normally they either not bother sparing user mappings due
to this making not much sense due to the nature of pseudo-mode (e.g.
you don't need user mappings if you are doing fuzzy matching the
buffers or files to open: most of them make no sense and if user needs
mappings to input text specifically into your prompt then you have
dramatically failed as a fuzzy finder), or are actually using
single-character mappings (e.g. like my translit3) which makes 2. not
needed (no "non-full prefix" possible), though I still need at least
maparg() and mappings_load(), latter in my code is just using
`:execute` for mappings_load() absense.
//
BTW, for :h map-multibyte: discard that. Sane people are not changing
&encoding in the runtime (after vimrc was loaded, *before* vimrc
defines any mappings or uses other non-ASCII string) because it makes
any non-ASCII text present in memory invalid which is going to provoke
bugs, Neovim has even disabled the ability to change &encoding at all,
forcing it be utf-8 always. Do not remember any complains from users
about this move.
>
> 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.
No comments:
Post a Comment