Re: Vim startup profiling

On Fr, 26 Mai 2017, Ken Takata wrote:

> > Ok I save 100ms using the plugin manager vim-plug but not enough for me.
> > Is anyone can advise me or explain to me why some files are loaded twice and take twice or more times N msec:
> > - vim80/menu.vim
> > - vim80\filetype.vim
>
> > 096.000 047.000 044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> > 096.000 072.000 025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim
>
> menu.vim uses `globpath()` to search some kind of files under the runtimepath.
> If you search `globpath` in menu.vim, you may find the following lines:
>
> let s:n = globpath(&runtimepath, "colors/*.vim")
> let s:n = globpath(&runtimepath, "keymap/*.vim")
> let s = globpath(&rtp, "spell/*." . enc . ".spl")
> let s:n = globpath(&runtimepath, "compiler/*.vim")
>
> Color schemes, keymaps, spell files and compiler plugins are searched when
> menu.vim is loaded.
> This is why it takes long time to be loaded.
>
> Unlike those items, file types are not listed automatically. If a user
> selects "Syntax" -> "Show File Types in Menu", they will be listed.
> If we use a similar way for color schemes etc., the startup time would be
> reduced.

I took a brief look into that. First, I don't think it would be easily
possible to avoid the globpath() for the colorschemes and other scripts.

The syntax script seems to be compile time dependent, so while this
works, I assume it does not work correctly for filetypes/syntax scripts
you installed as extra package and I guess this is not what we want for
colorschemes and the other script types.

I think, it could be beneficial, if globpath() and glob() did allow for
e.g. OR'ing the script, e.g. something like this should be a lot faster:

globpath(&runtimepath, "{colors,spell,keymap,compiler}/*.vim")

Because we could then manually filter the resulting list. Unfortunately,
this syntax is not supported by glob()/globpath(). That could be a
worthwhile addition.

Mit freundlichen Grüßen
Christian
--
Machen Sie sich erst einmal unbeliebt, dann werden Sie auch ernst
genommen.
-- Konrad Adenauer

--
--
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: Insert lines at begin of file with writefile

Le mercredi 31 mai 2017 18:59:13 UTC+2, Ken Takata a écrit :
> Hi,
>
> 2017/5/31 Wed 18:11:29 UTC+9 Ni Va wrote:
> > Le mardi 30 mai 2017 13:29:10 UTC+2, ZyX a écrit :
> > > 2017-05-30 14:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > > > Le mardi 30 mai 2017 13:03:38 UTC+2, ZyX a écrit :
> > > >> 2017-05-30 11:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > > >> > Hi,
> > > >> >
> > > >> >
> > > >> > Is that a way to tell writefile() func to append lines at the beginning of file?
> > > >>
> > > >> Just read the whole file, prepend and then write the whole file. In
> > > >> any case I do not know a way to actually prepend bytes to the file: if
> > > >> you seek to the end of file (or open it in append mode) and start
> > > >> writing to it you get appending. If you seek to the start and start
> > > >> writing you will just overwrite first bytes. So programming languages
> > > >> do not have "prepending" abstraction because it is not supported by
> > > >> the OS and thus is going to either cost very much or have problems
> > > >> like loosing data on crashes.
> > > >>
> > > >> >
> > > >> > 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.
> > > >
> > > > Do you think readfile writefile would be faster than that :
> > > >
> > > > let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
> > > > \"call append(0, ".string(lines2Append).")", "-c", "wq"]
> > > > call x.add_cmd(begin) " ==>>>> Launch cmd as job
> > >
> > > With readfile+writefile you load a file into memory and write there.
> > > With gvim you are forking, loading gvim.exe and a big bunch of
> > > libraries needed for GUI, loading a file into memory (though buffer
> > > structure should be a bit more efficient then a list from `readfile()`
> > > AFAIK), loading a big bunch of plugins (do not do such things without
> > > `-u NONE -i NONE`), loading GUI (use `--cmd` for such things, not
> > > `-c`). Which is faster? Actually may be your variant if you do not
> > > need to wait for gvim to finish prepending because time would be
> > > limited to only forking. readfile()+writefile() if you do need to
> > > wait.
> > >
> > > >
> > > > --
> > > > --
> > > > 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.
> >
> > Ok applying your advise it is sure the radfile writefile method is amazing faster in binary mode.
> >
> > Then this method 2 below can be done by job_start( ?
> >
> > Thank you
> >
> >
> >
> > " add append lines
> > let lines2Append = [
> > \ expand("SDK_INCLUDE_DIR=$ProgramFiles (x86)/Windows Kits/8.1/Include")
> > \, expand("VS_DIR=$ProgramFiles (x86)/Microsoft Visual Studio 14.0/VC")
> > \, 'CPU=AMD64'
> > \, 'FEATURES=HUGE'
> > \, 'OLE=yes'
> > \, 'GUI=yes'
> > \, 'XPM=no'
> > \, 'NETBEANS=no'
> > \, 'CSCOPE=no'
> > \, 'MBYTE=yes'
> > \, 'DYNAMIC_LUA=yes'
> > \, 'LUA=.\\lua53'
> > \, 'LUA_VER=53'
> > \, 'DYNAMIC_PYTHON=yes'
> > \, 'PYTHON=C:\Python27'
> > \, 'PYTHON_VER=27'
> > \, 'DYNAMIC_PYTHON3=no'
> > \, 'PYTHON3='
> > \, 'PYTHON3_VER='
> > \, 'EVENT_LOOP=yes'
> > \, '
> > '
> > \]
> > " method 1 : slow to add lines but job able
> > let cmd = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
> > \"call append(0, ".string(lines2Append).")", "-c", "wq"]
> > " call x.add_cmd(cmd) "started as job by job_start( and handlers
> >
> >
> > " method 2 : faster but no job able ??!?
> > let originalFile = readfile(makefile,'b')
> > call writefile( lines2Append, makefile, 'b')
> > call writefile( originalFile, makefile, 'a')
>
> Just curious.
> Why you edit Make_mvc.mak?
>
> Normally you just need to specify the option in the command line. E.g.:
>
> nmake -f Make_mvc.mak "SDK_INCLUDE_DIR=..." CPU=AMD64 FEATURES=... ...
>
> Another option is creating a batch file which sets the options to environment
> variables, then run nmake. E.g.:
>
> @echo off
> set SDK_INCLUDE_DIR=...
> set CPU=AMD64
> set FEATURES=...
> ...
> nmake -f Make_mvc.mak
>
>
> Regards,
> Ken Takata

Hi Ken,

My goal if it is possible is building all from within vim/gvim using and using new job_start serial sequencer I have done.

For instant, the script 1:download src from git 2:modify somes sources 3:prepare makefile 4:inprogress to set env vcvarsall 5:built gvim or vim.

To Keep out build.cmd and vcvarsall.bat I intend to.

This is the main part client vimscript written at the day :

" {{{ Make my Vim
fu! makemyvim#MakeMyVim()


" plan cmds
let x = cmdlauncher#new()


" 0 - Download vim from Github
let currentPath=getcwd()
cd $tmp
" call x.add_cmd('git init')
" call x.add_cmd('git clone https://github.com/vim/vim.git')
exe "cd ".currentPath

" 1 - Niva pack
"
let src = $VIM.'/nivamakepack'

call x.add_cmd(utils#Robocopy(src, $TMP.'/vim/src','*.ico' ))
call x.add_cmd(utils#Robocopy(src, $TMP.'/vim/src','tools.bmp' ))
call x.add_cmd(utils#Robocopy(src, $TMP.'/vim/src','configure.cmd' ))
call x.add_cmd(utils#Robocopy(src.'/lua53', $TMP.'/vim/src'.'/lua53','*'))

call x.add_cmd([$vimruntime."/gvim.exe", '-c', 'edit $tmp/vim/src/gui.h', '-c', '%s/\(TOOLBAR_BUTTON_\w\+\s\+\)\d\+/\148', '-c', 'wq'])

" 2 - build it
"
let nmake_path = globpath(expand('$ProgramFiles'.' (x86)/Microsoft Visual Studio 14.0/VC/bin'),'nmake.exe')
if !filereadable(nmake_path)
echomsg "nmake is not available"
echomsg "".nmake_path
return
endif

let makefile = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
if !filereadable(makefile)
echomsg "makefile is not available"
echomsg "".makefile
return
endif

let win32_mak = globpath(expand('$ProgramFiles'.' (x86)/Windows Kits/8.1/Include'),'win32.mak')
if !filereadable(win32_mak)
echomsg "win32_mak is not available"
echomsg "". win32_mak
return
endif

" add append lines
let lines2Append = [
\ expand("SDK_INCLUDE_DIR=$ProgramFiles (x86)/Windows Kits/8.1/Include")
\, expand("VS_DIR=$ProgramFiles (x86)/Microsoft Visual Studio 14.0/VC")
\, 'CPU=AMD64'
\, 'FEATURES=HUGE'
\, 'OLE=yes'
\, 'GUI=yes'
\, 'XPM=no'
\, 'NETBEANS=no'
\, 'CSCOPE=no'
\, 'MBYTE=yes'
\, 'DYNAMIC_LUA=yes'
\, 'LUA=.\\lua53'
\, 'LUA_VER=53'
\, 'DYNAMIC_PYTHON=yes'
\, 'PYTHON=C:\Python27'
\, 'PYTHON_VER=27'
\, 'DYNAMIC_PYTHON3=no'
\, 'PYTHON3='
\, 'PYTHON3_VER='
\, 'EVENT_LOOP=yes'
\, nr2char('<NL>',1)
\]

" method 1 : slow to add lines but job able
" let cmd = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
" \"call append(0, ".string(lines2Append).")", "-c", "wq"]
" call x.add_cmd(cmd) "started as job by job_start( and handlers


" method 2 : faster but no job able ??!?
let originalFile = readfile(makefile,'b')
call writefile( lines2Append, makefile, 'b')
call writefile( originalFile, makefile, 'a')

" build
let $VisualStudioVersion='14.0'
" let $path='14.0'
call x.add_cmd('"'.nmake_path.'" -f "'.makefile.'" clean')

" start all jobs
call x.start()

return

endfu
" }}}
" vim: set ft=vim ff=dos fdm=marker ts=4 :expandtab:



--
--
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: Insert lines at begin of file with writefile

Hi,

2017/5/31 Wed 18:11:29 UTC+9 Ni Va wrote:
> Le mardi 30 mai 2017 13:29:10 UTC+2, ZyX a écrit :
> > 2017-05-30 14:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > > Le mardi 30 mai 2017 13:03:38 UTC+2, ZyX a écrit :
> > >> 2017-05-30 11:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > >> > Hi,
> > >> >
> > >> >
> > >> > Is that a way to tell writefile() func to append lines at the beginning of file?
> > >>
> > >> Just read the whole file, prepend and then write the whole file. In
> > >> any case I do not know a way to actually prepend bytes to the file: if
> > >> you seek to the end of file (or open it in append mode) and start
> > >> writing to it you get appending. If you seek to the start and start
> > >> writing you will just overwrite first bytes. So programming languages
> > >> do not have "prepending" abstraction because it is not supported by
> > >> the OS and thus is going to either cost very much or have problems
> > >> like loosing data on crashes.
> > >>
> > >> >
> > >> > 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.
> > >
> > > Do you think readfile writefile would be faster than that :
> > >
> > > let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
> > > \"call append(0, ".string(lines2Append).")", "-c", "wq"]
> > > call x.add_cmd(begin) " ==>>>> Launch cmd as job
> >
> > With readfile+writefile you load a file into memory and write there.
> > With gvim you are forking, loading gvim.exe and a big bunch of
> > libraries needed for GUI, loading a file into memory (though buffer
> > structure should be a bit more efficient then a list from `readfile()`
> > AFAIK), loading a big bunch of plugins (do not do such things without
> > `-u NONE -i NONE`), loading GUI (use `--cmd` for such things, not
> > `-c`). Which is faster? Actually may be your variant if you do not
> > need to wait for gvim to finish prepending because time would be
> > limited to only forking. readfile()+writefile() if you do need to
> > wait.
> >
> > >
> > > --
> > > --
> > > 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.
>
> Ok applying your advise it is sure the radfile writefile method is amazing faster in binary mode.
>
> Then this method 2 below can be done by job_start( ?
>
> Thank you
>
>
>
> " add append lines
> let lines2Append = [
> \ expand("SDK_INCLUDE_DIR=$ProgramFiles (x86)/Windows Kits/8.1/Include")
> \, expand("VS_DIR=$ProgramFiles (x86)/Microsoft Visual Studio 14.0/VC")
> \, 'CPU=AMD64'
> \, 'FEATURES=HUGE'
> \, 'OLE=yes'
> \, 'GUI=yes'
> \, 'XPM=no'
> \, 'NETBEANS=no'
> \, 'CSCOPE=no'
> \, 'MBYTE=yes'
> \, 'DYNAMIC_LUA=yes'
> \, 'LUA=.\\lua53'
> \, 'LUA_VER=53'
> \, 'DYNAMIC_PYTHON=yes'
> \, 'PYTHON=C:\Python27'
> \, 'PYTHON_VER=27'
> \, 'DYNAMIC_PYTHON3=no'
> \, 'PYTHON3='
> \, 'PYTHON3_VER='
> \, 'EVENT_LOOP=yes'
> \, '
> '
> \]
> " method 1 : slow to add lines but job able
> let cmd = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
> \"call append(0, ".string(lines2Append).")", "-c", "wq"]
> " call x.add_cmd(cmd) "started as job by job_start( and handlers
>
>
> " method 2 : faster but no job able ??!?
> let originalFile = readfile(makefile,'b')
> call writefile( lines2Append, makefile, 'b')
> call writefile( originalFile, makefile, 'a')

Just curious.
Why you edit Make_mvc.mak?

Normally you just need to specify the option in the command line. E.g.:

nmake -f Make_mvc.mak "SDK_INCLUDE_DIR=..." CPU=AMD64 FEATURES=... ...

Another option is creating a batch file which sets the options to environment
variables, then run nmake. E.g.:

@echo off
set SDK_INCLUDE_DIR=...
set CPU=AMD64
set FEATURES=...
...
nmake -f Make_mvc.mak


Regards,
Ken Takata

--
--
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: Insert lines at begin of file with writefile

Le mardi 30 mai 2017 13:29:10 UTC+2, ZyX a écrit :
> 2017-05-30 14:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > Le mardi 30 mai 2017 13:03:38 UTC+2, ZyX a écrit :
> >> 2017-05-30 11:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> >> > Hi,
> >> >
> >> >
> >> > Is that a way to tell writefile() func to append lines at the beginning of file?
> >>
> >> Just read the whole file, prepend and then write the whole file. In
> >> any case I do not know a way to actually prepend bytes to the file: if
> >> you seek to the end of file (or open it in append mode) and start
> >> writing to it you get appending. If you seek to the start and start
> >> writing you will just overwrite first bytes. So programming languages
> >> do not have "prepending" abstraction because it is not supported by
> >> the OS and thus is going to either cost very much or have problems
> >> like loosing data on crashes.
> >>
> >> >
> >> > 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.
> >
> > Do you think readfile writefile would be faster than that :
> >
> > let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
> > \"call append(0, ".string(lines2Append).")", "-c", "wq"]
> > call x.add_cmd(begin) " ==>>>> Launch cmd as job
>
> With readfile+writefile you load a file into memory and write there.
> With gvim you are forking, loading gvim.exe and a big bunch of
> libraries needed for GUI, loading a file into memory (though buffer
> structure should be a bit more efficient then a list from `readfile()`
> AFAIK), loading a big bunch of plugins (do not do such things without
> `-u NONE -i NONE`), loading GUI (use `--cmd` for such things, not
> `-c`). Which is faster? Actually may be your variant if you do not
> need to wait for gvim to finish prepending because time would be
> limited to only forking. readfile()+writefile() if you do need to
> wait.
>
> >
> > --
> > --
> > 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.

Ok applying your advise it is sure the radfile writefile method is amazing faster in binary mode.

Then this method 2 below can be done by job_start( ?

Thank you



" add append lines
let lines2Append = [
\ expand("SDK_INCLUDE_DIR=$ProgramFiles (x86)/Windows Kits/8.1/Include")
\, expand("VS_DIR=$ProgramFiles (x86)/Microsoft Visual Studio 14.0/VC")
\, 'CPU=AMD64'
\, 'FEATURES=HUGE'
\, 'OLE=yes'
\, 'GUI=yes'
\, 'XPM=no'
\, 'NETBEANS=no'
\, 'CSCOPE=no'
\, 'MBYTE=yes'
\, 'DYNAMIC_LUA=yes'
\, 'LUA=.\\lua53'
\, 'LUA_VER=53'
\, 'DYNAMIC_PYTHON=yes'
\, 'PYTHON=C:\Python27'
\, 'PYTHON_VER=27'
\, 'DYNAMIC_PYTHON3=no'
\, 'PYTHON3='
\, 'PYTHON3_VER='
\, 'EVENT_LOOP=yes'
\, '
'
\]
" method 1 : slow to add lines but job able
let cmd = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
\"call append(0, ".string(lines2Append).")", "-c", "wq"]
" call x.add_cmd(cmd) "started as job by job_start( and handlers


" method 2 : faster but no job able ??!?
let originalFile = readfile(makefile,'b')
call writefile( lines2Append, makefile, 'b')
call writefile( originalFile, makefile, 'a')

--
--
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: Typo/mistake in insert.txt?

Ethan Hereth wrote:

> I am pretty sure there is a mistake in insert.txt at line 639 (at least
> it's there on the version I just checked on github) where it explains the
> insert mode completion commands. It says "All these (except 2) are done in
> CTRL-X mode." I think that this should say "except 13"? Or, am I
> misunderstanding something?
>
> I'm thrilled to make a pull request for this if desired; but it's a simple
> change.

With "2" is meant CTRL-N and CTRL-P. It's a bit confusing, I'll just
mention those instead of the count.

--
The word "leader" is derived from the word "lead", as in the material that
bullets are made out of. The term "leader" was popularized at about the same
time as the invention of firearms. It grew out of the observation that the
person in charge of every organization was the person whom everyone wanted to
fill with hot lead.
I don't recomment this; it's just a point of historical interest.
(Scott Adams - The Dilbert principle)

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

Re: Typo/mistake in insert.txt?

Hi!

On May 30, Ethan Hereth wrote:

> I am pretty sure there is a mistake in insert.txt at line
> 639 (at least it's there on the version I just checked on
> github) where it explains the insert mode completion
> commands. It says "All these (except 2) are done in
> CTRL-X mode." I think that this should say "except 13"?
> Or, am I misunderstanding something?

I think it means 'all except two of them,' i.e. CTRL-N and
CTRL-P. --Antony

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

Typo/mistake in insert.txt?

All,

I am pretty sure there is a mistake in insert.txt at line 639 (at least it's there on the version I just checked on github) where it explains the insert mode completion commands. It says "All these (except 2) are done in CTRL-X mode." I think that this should say "except 13"? Or, am I misunderstanding something?

I'm thrilled to make a pull request for this if desired; but it's a simple change.

I love vim; thanks for the fantastic editor!

Ethan Alan

--
--
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: Insert lines at begin of file with writefile

2017-05-30 14:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> Le mardi 30 mai 2017 13:03:38 UTC+2, ZyX a écrit :
>> 2017-05-30 11:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
>> > Hi,
>> >
>> >
>> > Is that a way to tell writefile() func to append lines at the beginning of file?
>>
>> Just read the whole file, prepend and then write the whole file. In
>> any case I do not know a way to actually prepend bytes to the file: if
>> you seek to the end of file (or open it in append mode) and start
>> writing to it you get appending. If you seek to the start and start
>> writing you will just overwrite first bytes. So programming languages
>> do not have "prepending" abstraction because it is not supported by
>> the OS and thus is going to either cost very much or have problems
>> like loosing data on crashes.
>>
>> >
>> > 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.
>
> Do you think readfile writefile would be faster than that :
>
> let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
> \"call append(0, ".string(lines2Append).")", "-c", "wq"]
> call x.add_cmd(begin) " ==>>>> Launch cmd as job

With readfile+writefile you load a file into memory and write there.
With gvim you are forking, loading gvim.exe and a big bunch of
libraries needed for GUI, loading a file into memory (though buffer
structure should be a bit more efficient then a list from `readfile()`
AFAIK), loading a big bunch of plugins (do not do such things without
`-u NONE -i NONE`), loading GUI (use `--cmd` for such things, not
`-c`). Which is faster? Actually may be your variant if you do not
need to wait for gvim to finish prepending because time would be
limited to only forking. readfile()+writefile() if you do need to
wait.

>
> --
> --
> 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: Insert lines at begin of file with writefile

Le mardi 30 mai 2017 13:03:38 UTC+2, ZyX a écrit :
> 2017-05-30 11:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > Hi,
> >
> >
> > Is that a way to tell writefile() func to append lines at the beginning of file?
>
> Just read the whole file, prepend and then write the whole file. In
> any case I do not know a way to actually prepend bytes to the file: if
> you seek to the end of file (or open it in append mode) and start
> writing to it you get appending. If you seek to the start and start
> writing you will just overwrite first bytes. So programming languages
> do not have "prepending" abstraction because it is not supported by
> the OS and thus is going to either cost very much or have problems
> like loosing data on crashes.
>
> >
> > 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.

Do you think readfile writefile would be faster than that :

let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
\"call append(0, ".string(lines2Append).")", "-c", "wq"]
call x.add_cmd(begin) " ==>>>> Launch cmd as job

--
--
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: Insert lines at begin of file with writefile

2017-05-30 11:21 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> Hi,
>
>
> Is that a way to tell writefile() func to append lines at the beginning of file?

Just read the whole file, prepend and then write the whole file. In
any case I do not know a way to actually prepend bytes to the file: if
you seek to the end of file (or open it in append mode) and start
writing to it you get appending. If you seek to the start and start
writing you will just overwrite first bytes. So programming languages
do not have "prepending" abstraction because it is not supported by
the OS and thus is going to either cost very much or have problems
like loosing data on crashes.

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

Re: Fastest way to edit file by command gvim launched

Le lundi 29 mai 2017 18:02:47 UTC+2, tu...@posteo.de a écrit :
> 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.

I mean to insert lines at begin. This is the short I found for instant.

let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
\"call append(0, ".string(lines2Append).")"]

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

Insert lines at begin of file with writefile

Hi,


Is that a way to tell writefile() func to append lines at the beginning of file?

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: Bug/non-determinism in output of maparg() and map commands

On Mon, May 29, 2017 at 3:31 PM, Nikolay Aleksandrovich Pavlov
<zyx.vim@gmail.com> wrote:
> 2017-05-29 22:17 GMT+03:00 Brett Stahlman <brettstahlman@gmail.com>:
>> On Mon, May 29, 2017 at 3:19 AM, Nikolay Aleksandrovich Pavlov
>> <zyx.vim@gmail.com> wrote:
>> [...]
>>>>>
>>>>> 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.
>>
>> Depends on what is meant by "ambiguous" and "conflicting", I
>> suppose... If you define these terms by "shared prefix" only (the way
>> mapcheck() works today), then...
>>
>> :nmap <buffer><nowait> foo foo
>>
>> ...would conflict with the following, previously defined global map
>> (though in fact, there is really no conflict at all):
>>
>> :nmap foobar foobar
>>
>> I guess I was envisioning a smarter detection logic, which would
>> consider modifiers like <buffer> and <nowait>, as well as current
>> enabled/disabled status, with the goal of answering the following
>> questions: If I were to create the following map (defined by lhs,
>> mode(s), scope (buffer/global), <nowait>, etc.), would there be
>> ambiguity/conflict with any existing maps? And if so, which ones? In
>> your approach, "disable" is simply "remove/clear", so that check
>> becomes unnecessary. So you're probably thinking that Vim's map
>> scoping/shadowing logic is sufficiently simple that the plugin
>> developer could easily include the applicable checks in his map filter
>> expression. As things stand now, you may be right, though the idea of
>> requiring each plugin developer who needs this check to implement the
>> logic independently still suggests a missing primitive to me. I
>> concur, however, that the plugin developer would have all the
>> information he needs to do it himself, provided that the map filter
>> expression has access to a sufficiently canonicalized lhs: i.e., one
>> that uniquely represents both multi-byte characters (:help
>> map-multibyte for special considerations) and special keys (:help
>> map-special-keys), even across changes to 'encoding' and 'cpo'...
>
> Still can be put into runtime file if properly implemented. Also from
> what I have read all you need to do is find mappings falling into one
> of the following conditions:
>
> 1. Same mode as your mappings, and exactly the same lhs, and <buffer>.
> 2. Same mode as your mappings, and lhs which is non-full prefix of
> your lhs, and <nowait>.
>
> : basically keeping as much user mappings as you can, but finding
> those which may prevent user from accessing your mappings in your
> "transient" mode.
>
> While this is more efficient to implement in C, this looks like
> something extremely local and not making much sense to actually do
> implement it in C in a way other then "find mappings which conflict
> with given mapping***s***". Singular would mean iterating and thus not
> much gained performance compared to `filter()`-based variant,
> "extremely local" means "I do not think other plugin authors would
> actually need this to bother with maintaining the solution, be it in C
> or VimL":

I don't know about "extremely local", but given that the tests *can*
be done by the plugin developer, the increased control over map
detection/execution discussed earlier (e.g., map callbacks, in
conjunction with enhanced control over the typeahead buffer) strikes
me as more "game-changing" for plugin developers. Thus, I would tend
to prioritize it above enhanced conflict/ambiguity detection...

>
> I have seen plugins which have their pseudo-mode and even wrote one
> myself, and normally they either not bother sparing user mappings due
> to this making not much sense due to the nature of pseudo-mode (e.g.
> you don't need user mappings if you are doing fuzzy matching the
> buffers or files to open: most of them make no sense and if user needs
> mappings to input text specifically into your prompt then you have
> dramatically failed as a fuzzy finder), or are actually using
> single-character mappings (e.g. like my translit3) which makes 2. not
> needed (no "non-full prefix" possible), though I still need at least
> maparg() and mappings_load(), latter in my code is just using
> `:execute` for mappings_load() absense.
>
> //
>
> BTW, for :h map-multibyte: discard that. Sane people are not changing
> &encoding in the runtime (after vimrc was loaded, *before* vimrc
> defines any mappings or uses other non-ASCII string) because it makes
> any non-ASCII text present in memory invalid which is going to provoke
> bugs, Neovim has even disabled the ability to change &encoding at all,
> forcing it be utf-8 always. Do not remember any complains from users
> about this move.

I guess Bram would need to decide whether such a deprecation would
have unacceptable backwards compatibility implications. I agree that
it's probably not something done very often, doing it could be
problematic, and the logic needed to support it probably complicates
the implementation for an uncommon use case...

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.

Re: Bug/non-determinism in output of maparg() and map commands

2017-05-29 22:17 GMT+03:00 Brett Stahlman <brettstahlman@gmail.com>:
> On Mon, May 29, 2017 at 3:19 AM, Nikolay Aleksandrovich Pavlov
> <zyx.vim@gmail.com> wrote:
> [...]
>>>>
>>>> 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.
>
> Depends on what is meant by "ambiguous" and "conflicting", I
> suppose... If you define these terms by "shared prefix" only (the way
> mapcheck() works today), then...
>
> :nmap <buffer><nowait> foo foo
>
> ...would conflict with the following, previously defined global map
> (though in fact, there is really no conflict at all):
>
> :nmap foobar foobar
>
> I guess I was envisioning a smarter detection logic, which would
> consider modifiers like <buffer> and <nowait>, as well as current
> enabled/disabled status, with the goal of answering the following
> questions: If I were to create the following map (defined by lhs,
> mode(s), scope (buffer/global), <nowait>, etc.), would there be
> ambiguity/conflict with any existing maps? And if so, which ones? In
> your approach, "disable" is simply "remove/clear", so that check
> becomes unnecessary. So you're probably thinking that Vim's map
> scoping/shadowing logic is sufficiently simple that the plugin
> developer could easily include the applicable checks in his map filter
> expression. As things stand now, you may be right, though the idea of
> requiring each plugin developer who needs this check to implement the
> logic independently still suggests a missing primitive to me. I
> concur, however, that the plugin developer would have all the
> information he needs to do it himself, provided that the map filter
> expression has access to a sufficiently canonicalized lhs: i.e., one
> that uniquely represents both multi-byte characters (:help
> map-multibyte for special considerations) and special keys (:help
> map-special-keys), even across changes to 'encoding' and 'cpo'...

Still can be put into runtime file if properly implemented. Also from
what I have read all you need to do is find mappings falling into one
of the following conditions:

1. Same mode as your mappings, and exactly the same lhs, and <buffer>.
2. Same mode as your mappings, and lhs which is non-full prefix of
your lhs, and <nowait>.

: basically keeping as much user mappings as you can, but finding
those which may prevent user from accessing your mappings in your
"transient" mode.

While this is more efficient to implement in C, this looks like
something extremely local and not making much sense to actually do
implement it in C in a way other then "find mappings which conflict
with given mapping***s***". Singular would mean iterating and thus not
much gained performance compared to `filter()`-based variant,
"extremely local" means "I do not think other plugin authors would
actually need this to bother with maintaining the solution, be it in C
or VimL":

I have seen plugins which have their pseudo-mode and even wrote one
myself, and normally they either not bother sparing user mappings due
to this making not much sense due to the nature of pseudo-mode (e.g.
you don't need user mappings if you are doing fuzzy matching the
buffers or files to open: most of them make no sense and if user needs
mappings to input text specifically into your prompt then you have
dramatically failed as a fuzzy finder), or are actually using
single-character mappings (e.g. like my translit3) which makes 2. not
needed (no "non-full prefix" possible), though I still need at least
maparg() and mappings_load(), latter in my code is just using
`:execute` for mappings_load() absense.

//

BTW, for :h map-multibyte: discard that. Sane people are not changing
&encoding in the runtime (after vimrc was loaded, *before* vimrc
defines any mappings or uses other non-ASCII string) because it makes
any non-ASCII text present in memory invalid which is going to provoke
bugs, Neovim has even disabled the ability to change &encoding at all,
forcing it be utf-8 always. Do not remember any complains from users
about this move.

>
> Sincerely,
> Brett Stahlman
>
>>
>>>
>>> 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.

Re: Bug/non-determinism in output of maparg() and map commands

On Mon, May 29, 2017 at 3:19 AM, Nikolay Aleksandrovich Pavlov
<zyx.vim@gmail.com> wrote:
[...]
>>>
>>> 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.

Depends on what is meant by "ambiguous" and "conflicting", I
suppose... If you define these terms by "shared prefix" only (the way
mapcheck() works today), then...

:nmap <buffer><nowait> foo foo

...would conflict with the following, previously defined global map
(though in fact, there is really no conflict at all):

:nmap foobar foobar

I guess I was envisioning a smarter detection logic, which would
consider modifiers like <buffer> and <nowait>, as well as current
enabled/disabled status, with the goal of answering the following
questions: If I were to create the following map (defined by lhs,
mode(s), scope (buffer/global), <nowait>, etc.), would there be
ambiguity/conflict with any existing maps? And if so, which ones? In
your approach, "disable" is simply "remove/clear", so that check
becomes unnecessary. So you're probably thinking that Vim's map
scoping/shadowing logic is sufficiently simple that the plugin
developer could easily include the applicable checks in his map filter
expression. As things stand now, you may be right, though the idea of
requiring each plugin developer who needs this check to implement the
logic independently still suggests a missing primitive to me. I
concur, however, that the plugin developer would have all the
information he needs to do it himself, provided that the map filter
expression has access to a sufficiently canonicalized lhs: i.e., one
that uniquely represents both multi-byte characters (:help
map-multibyte for special considerations) and special keys (:help
map-special-keys), even across changes to 'encoding' and 'cpo'...

Sincerely,
Brett Stahlman

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

Re: Fastest way to edit file by command gvim launched

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.

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.

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.

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.

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.

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.

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.