Hi
May
gvim.exe <file> +<linenumber>
work?
Cheers
Meino
On 05/29 02:33, Ni Va wrote:
> Hi,
>
> I need to modify makefile to build vim and I wonder if the way I took is the fastest one.
>
> I launch gvim by command to setline I need to modify.
>
>
> [''D:\Logiciels\Vim\vim80/gvim.exe'', ''-c'', ''edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak'', ''-c'', ''call setline(1,''''set SDK_INCLUDE_DIR = C:\Program Files (x86)\Windows Kits\8.1\Include'''')'']
>
> launched by job_start or :! and it works but is it the fastest way ?
> Thank you !
> Niva
>
> --
> --
> 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.
--
--
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.
Monday, May 29, 2017
Fastest way to edit file by command gvim launched
Hi,
I need to modify makefile to build vim and I wonder if the way I took is the fastest one.
I launch gvim by command to setline I need to modify.
[''D:\Logiciels\Vim\vim80/gvim.exe'', ''-c'', ''edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak'', ''-c'', ''call setline(1,''''set SDK_INCLUDE_DIR = C:\Program Files (x86)\Windows Kits\8.1\Include'''')'']
launched by job_start or :! and it works but is it the fastest way ?
Thank you !
Niva
--
--
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.
I need to modify makefile to build vim and I wonder if the way I took is the fastest one.
I launch gvim by command to setline I need to modify.
[''D:\Logiciels\Vim\vim80/gvim.exe'', ''-c'', ''edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak'', ''-c'', ''call setline(1,''''set SDK_INCLUDE_DIR = C:\Program Files (x86)\Windows Kits\8.1\Include'''')'']
launched by job_start or :! and it works but is it the fastest way ?
Thank you !
Niva
--
--
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.
Re: E114: Missing quote in gvim.exe', '-c'
Le lundi 29 mai 2017 11:15:48 UTC+2, Ni Va a écrit :
> Le lundi 29 mai 2017 10:29:53 UTC+2, Ni Va a écrit :
> > Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
> > > Hi,
> > >
> > > An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
> > >
> > > let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
> > > call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
> > >
> > >
> > > Errors appear like that :
> > > rror detected while processing command line:
> > > E114: Missing quote: "SDK_INCLUDE_DIR)
> > > E116: Invalid arguments for function setline
> > >
> > >
> > > I don't understand why.
> > > Thank by advance !
> > > Niva
> >
> > Just another point :
> >
> > start:['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"setSDK_INCLUDE_DIR\")', '-c', 'wq']
> >
> > How can I setline with space char in text, "set SDK_INCLUDE_DIR" out of "setSDK_INCLUDE_DIR".
> >
> > Thanks
>
> This in a job_start command fails due to setline(1,\"set\ SDK_INCLUDE_DIR\")' :
>
> [['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nnn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"set\ SDK_INCLUDE_DIR\")', '-c', 'wq']]
>
> gvim launched says "SDK_INCLUDE_DIR")" [New File]
Ok solved by permutting simple by double quote
"call setline(1,'set SDK_INCLUDE_DIR')"
Thank you. done
--
--
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.
> Le lundi 29 mai 2017 10:29:53 UTC+2, Ni Va a écrit :
> > Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
> > > Hi,
> > >
> > > An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
> > >
> > > let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
> > > call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
> > >
> > >
> > > Errors appear like that :
> > > rror detected while processing command line:
> > > E114: Missing quote: "SDK_INCLUDE_DIR)
> > > E116: Invalid arguments for function setline
> > >
> > >
> > > I don't understand why.
> > > Thank by advance !
> > > Niva
> >
> > Just another point :
> >
> > start:['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"setSDK_INCLUDE_DIR\")', '-c', 'wq']
> >
> > How can I setline with space char in text, "set SDK_INCLUDE_DIR" out of "setSDK_INCLUDE_DIR".
> >
> > Thanks
>
> This in a job_start command fails due to setline(1,\"set\ SDK_INCLUDE_DIR\")' :
>
> [['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nnn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"set\ SDK_INCLUDE_DIR\")', '-c', 'wq']]
>
> gvim launched says "SDK_INCLUDE_DIR")" [New File]
Ok solved by permutting simple by double quote
"call setline(1,'set SDK_INCLUDE_DIR')"
Thank you. done
--
--
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.
Re: E114: Missing quote in gvim.exe', '-c'
2017-05-28 23:10 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
>> Hi,
>>
>> An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
>>
>> let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
>> call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
>>
>>
>> Errors appear like that :
>> rror detected while processing command line:
>> E114: Missing quote: "SDK_INCLUDE_DIR)
>> E116: Invalid arguments for function setline
>>
>>
>> I don't understand why.
>> Thank by advance !
>> Niva
>
> Done sorry for disturbing
> -c call setline(1,\"SDK_INCLUDE_DIR\"
This looks like a problem with escaping for cmd.exe, you should not
need escaping quotes on your own, this is to be done by Vim.
>
> --
> --
> 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.
--
--
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.
> Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
>> Hi,
>>
>> An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
>>
>> let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
>> call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
>>
>>
>> Errors appear like that :
>> rror detected while processing command line:
>> E114: Missing quote: "SDK_INCLUDE_DIR)
>> E116: Invalid arguments for function setline
>>
>>
>> I don't understand why.
>> Thank by advance !
>> Niva
>
> Done sorry for disturbing
> -c call setline(1,\"SDK_INCLUDE_DIR\"
This looks like a problem with escaping for cmd.exe, you should not
need escaping quotes on your own, this is to be done by Vim.
>
> --
> --
> 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.
--
--
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.
Re: E114: Missing quote in gvim.exe', '-c'
Le lundi 29 mai 2017 10:29:53 UTC+2, Ni Va a écrit :
> Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
> > Hi,
> >
> > An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
> >
> > let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
> > call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
> >
> >
> > Errors appear like that :
> > rror detected while processing command line:
> > E114: Missing quote: "SDK_INCLUDE_DIR)
> > E116: Invalid arguments for function setline
> >
> >
> > I don't understand why.
> > Thank by advance !
> > Niva
>
> Just another point :
>
> start:['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"setSDK_INCLUDE_DIR\")', '-c', 'wq']
>
> How can I setline with space char in text, "set SDK_INCLUDE_DIR" out of "setSDK_INCLUDE_DIR".
>
> Thanks
This in a job_start command fails due to setline(1,\"set\ SDK_INCLUDE_DIR\")' :
[['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nnn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"set\ SDK_INCLUDE_DIR\")', '-c', 'wq']]
gvim launched says "SDK_INCLUDE_DIR")" [New File]
--
--
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.
> Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
> > Hi,
> >
> > An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
> >
> > let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
> > call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
> >
> >
> > Errors appear like that :
> > rror detected while processing command line:
> > E114: Missing quote: "SDK_INCLUDE_DIR)
> > E116: Invalid arguments for function setline
> >
> >
> > I don't understand why.
> > Thank by advance !
> > Niva
>
> Just another point :
>
> start:['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"setSDK_INCLUDE_DIR\")', '-c', 'wq']
>
> How can I setline with space char in text, "set SDK_INCLUDE_DIR" out of "setSDK_INCLUDE_DIR".
>
> Thanks
This in a job_start command fails due to setline(1,\"set\ SDK_INCLUDE_DIR\")' :
[['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nnn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"set\ SDK_INCLUDE_DIR\")', '-c', 'wq']]
gvim launched says "SDK_INCLUDE_DIR")" [New File]
--
--
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.
Re: E114: Missing quote in gvim.exe', '-c'
Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
> Hi,
>
> An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
>
> let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
> call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
>
>
> Errors appear like that :
> rror detected while processing command line:
> E114: Missing quote: "SDK_INCLUDE_DIR)
> E116: Invalid arguments for function setline
>
>
> I don't understand why.
> Thank by advance !
> Niva
Just another point :
start:['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"setSDK_INCLUDE_DIR\")', '-c', 'wq']
How can I setline with space char in text, "set SDK_INCLUDE_DIR" out of "setSDK_INCLUDE_DIR".
Thanks
--
--
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.
> Hi,
>
> An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
>
> let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
> call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call setline(1,"SDK_INCLUDE_DIR")'])
>
>
> Errors appear like that :
> rror detected while processing command line:
> E114: Missing quote: "SDK_INCLUDE_DIR)
> E116: Invalid arguments for function setline
>
>
> I don't understand why.
> Thank by advance !
> Niva
Just another point :
start:['D:\Logiciels\Vim\vim80/gvim.exe', '-c', 'edit C:\Users\nn\AppData\Local\Temp\vim\src\Make_mvc.mak', '-c', 'call setline(1,\"setSDK_INCLUDE_DIR\")', '-c', 'wq']
How can I setline with space char in text, "set SDK_INCLUDE_DIR" out of "setSDK_INCLUDE_DIR".
Thanks
--
--
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.
Re: Bug/non-determinism in output of maparg() and map commands
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.
> 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:
Posts (Atom)