2017-05-29 4:25 GMT+03:00 Brett Stahlman <brettstahlman@gmail.com>:
> On Sun, May 28, 2017 at 4:19 PM, Nikolay Aleksandrovich Pavlov
> <zyx.vim@gmail.com> wrote:
> [...]
>>>>>>
>>>>>> And why do you think that "do not make plugins reinwent the wheel" is
>>>>>> the same statement as "write needed functionality in C code"? You can
>>>>>> always add a new file to `autoload`, writing VimL code is easier then
>>>>>> writing C code.
>>>>>
>>>>> You mean implementing a sort of "DSL" layer (using the primitive
>>>>> functions you've proposed) in Vim script, and including it in the
>>>>> official distribution as an autoload file? If so, I suppose this could
>>>>> be done, but as part of the official distribution, it would still need
>>>>> to be thought through and tested pretty thoroughly, so I don't see much
>>>>> advantage over implementing it in source, where it would be
>>>>> significantly more efficient. But perhaps I misunderstood what you were
>>>>> suggesting...
>>>>
>>>> I think you have only written VimL code, but not C one. VimL does not have
>>>> - Memory leaks. You can provoke one, of course, but 90% of code will
>>>> not ever cause any memory leaks unless you intentionally wrote a code
>>>> which causes memory leak (e.g. an always-growing cache of something
>>>> which is never cleaned up).
>>>> - Using some resource after freeing it. Especially applies to memory.
>>>> You can do something with trying to use channels after closing, but at
>>>> maximum this will show you a nice error which even will not crash Vim.
>>>> Similar error with using memory after freeing it at best will crash
>>>> Vim and provide a big message with lots of hex codes which may even
>>>> frighten some unexperienced user. At worst all you get is crashing Vim
>>>> a message to stderr (GVim users may never see it depending on how they
>>>> run GVim) about catching deadly signal SEGV without any details at
>>>> all. (As you see, Vim will crash in any case.)
>>>> - Crash due to out-of-bounds array access, with same amount of data as
>>>> above. VimL will just show a nice error message. Python will show
>>>> nicer error message, but the point is that it will not crash.
>>>>
>>>> And do not forget about one other good thing about VimL: if a user has
>>>> a distribution with two-years-old Vim to fix problem in C code he will
>>>> need C compiler, git, some shell experience and at least six commands
>>>> to update Vim (clone, configure, build, install, update bashrc or
>>>> whatever; plus one command per shell to load the update or reboot;
>>>> plus maybe something to make *.desktop files with GVim menu entries
>>>> point to a newly compiled Vim location). With VimL code user just
>>>> needs to drop a new version of the file into `~/.vim/autoload`.
>>>>
>>>> I was suggesting autoload because it is easier to write and maintain,
>>>> not because you will need to write less *functionality*. Same DSL
>>>> implemented purely in VimL on top of my proposal will run slower, but
>>>> take much less lines of code.
>>>
>>> I have programmed a great deal in both C and VimL. While I'm not sure
>>> I agree that the possibility of memory leaks is a compelling reason
>>> for implementing the functionality in a script, I don't really have
>>> strong feelings on this. Would the functionality be documented in the
>>> official Vim help? I can't think of any user-facing Vim functions
>>> currently implemented outside Vim. Though it's certainly easier to
>>> update/override a distributed script than to download or build a new
>>> executable, as a plugin developer, I would probably not want to rely
>>> upon tweaked distribution scripts, since most of the plugin users
>>> would get the updated scripts only when they got the updated
>>> executable. Sure, the plugin README could instruct users with older
>>> Vim versions to install an updated autoload file manually outside the
>>> plugin directory, but users have grown accustomed to one-click plugin
>>> installation methods, and might consider this an annoyance...
>>
>> 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.
>
> 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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment