On Mon, May 29, 2017 at 3:31 PM, Nikolay Aleksandrovich Pavlov
<zyx.vim@gmail.com> wrote:
> 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 don't know about "extremely local", but given that the tests *can*
be done by the plugin developer, the increased control over map
detection/execution discussed earlier (e.g., map callbacks, in
conjunction with enhanced control over the typeahead buffer) strikes
me as more "game-changing" for plugin developers. Thus, I would tend
to prioritize it above enhanced conflict/ambiguity detection...
>
> 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.
I guess Bram would need to decide whether such a deprecation would
have unacceptable backwards compatibility implications. I agree that
it's probably not something done very often, doing it could be
problematic, and the logic needed to support it probably complicates
the implementation for an uncommon use case...
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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment