2017-05-29 4:25 GMT+03:00 Brett Stahlman <[email protected]>: > On Sun, May 28, 2017 at 4:19 PM, Nikolay Aleksandrovich Pavlov > <[email protected]> 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 -- [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
