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