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