Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Good tips. Thank you! I indeed use older versions of Vim without `getwininfo()` on disparate machines. So, keeping this function is necessary at the moment. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-24 0:53 GMT+03:00 Jason Franklin : > The first instance makes sense. After all, no one would want to change the > file name in the command line window. > > The second instance means that I can't run :file in the ftplugin for the "qf" > file type. I was

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

The first instance makes sense. After all, no one would want to change the file name in the command line window. The second instance means that I can't run :file in the ftplugin for the "qf" file type. I was previously doing this in my own "ftplugin/qf.vim" script to get the type of list I was

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

2018-05-24 0:33 GMT+03:00 Bram Moolenaar : > > Jason Franklin wrote: > >> To replicate with the cmdline window: >> >> vim -u NONE >> q: >> :file > > Well, what do you expect to happen? I would expect it to have same output as ``, though… > >> To replicate with the

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Jason Franklin wrote: > To replicate with the cmdline window: > > vim -u NONE > q: > :file Well, what do you expect to happen? > To replicate with the quickfix window: > > vim -u NONE > :autocmd FileType qf file > :copen What's the use of :file here? > In both of these cases,

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

To replicate with the cmdline window: vim -u NONE q: :file To replicate with the quickfix window: vim -u NONE :autocmd FileType qf file :copen In both of these cases, ":file" fails. This is more what I was talking about. -- -- You received this message from the "vim_dev"

Patch 8.1.0022

Patch 8.1.0022 Problem:Repeating put from expression register fails. Solution: Re-evaluate the expression register. (Andy Massimino, closes #2945) Files: src/getchar.c, src/testdir/test_put.vim *** ../vim-8.1.0021/src/getchar.c 2018-05-22 20:35:13.554009274 +0200

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Jason Franklin wrote: > Just a follow up on what I've learned here. > > I don't think that the ":file" command makes much sense in the cmdline window. > However, I don't think it should be disallowed when curbuf_lock is set. Since > these restrictions go together, not much can be done. > >

Re: Trying to build with MinGW

Ken Takata wrote: > 2018/5/21 Mon 1:30:53 UTC+9 Bram Moolenaar wrote: > > I want to try debugging on MS-Windows with gdb. I normally build with > > MSVC, but I don't see a way to use that executable with gdb (perhaps > > it's possible with some compiler flag?). > > > > So I'll use MinGW for

Re: [vim/vim] Resolve warning about undefined behavior (#2946)

Michael Jarvis wrote: > Disclaimer: I'm sure there's a more elegant way to achieve the same > result. :-) Using a variable will avoid duplicating the code. -- I have read and understood the above. X /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\

Patch 8.1.0021

Patch 8.1.0021 Problem:Clang warns for undefined behavior. Solution: Move #ifdef outside of sprintf() call.(suggestion by Michael Jarvis, closes #2956) Files: src/term.c *** ../vim-8.1.0020/src/term.c 2018-05-10 14:39:42.0 +0200 --- src/term.c 2018-05-23

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Just a follow up on what I've learned here. I don't think that the ":file" command makes much sense in the cmdline window. However, I don't think it should be disallowed when curbuf_lock is set. Since these restrictions go together, not much can be done. Still, this is more of a decision about

Re: Question: Any reason why ":file" is disallowed in the cmdline window?

Just a follow up on what I've learned here. I don't think that the ":file" command makes much sense in the cmdline window. However, I don't think it should be disallowed when curbuf_lock is set. Since these restrictions go together, not much can be done. Still, this is more of a decision

Re: [PATCH] Add code and tests to fix the sentence text object

Hey Bram, and anyone else interested. Just a friendly ping concerning this issue. Like Andy, I feel pretty strongly that this patch is worth merging. I noted in my original post that the code for sentence text objects could use a more general refactoring later down the line. However, I think

Re: Trying to build with MinGW

Hi Bram, 2018/5/21 Mon 1:30:53 UTC+9 Bram Moolenaar wrote: > I want to try debugging on MS-Windows with gdb. I normally build with > MSVC, but I don't see a way to use that executable with gdb (perhaps > it's possible with some compiler flag?). > > So I'll use MinGW for compiling. MinGW

Re: feature to differentiate 32 from 64 bits build version

Le mercredi 23 mai 2018 15:14:51 UTC+2, Ken Takata a écrit : > Hi, > > 2018/5/23 Wed 21:29:43 UTC+9 Ni Va wrote: > > I build both 32 and 64 bits version of gvim but always 1 is returned when > > from 32bits or 64bits I do : > > > > echo has('num64') > > echo has('win32') > > echo has('win64') >

Re: feature to differentiate 32 from 64 bits build version

On Wed, May 23, 2018 at 3:14 PM, Ken Takata wrote: > Hi, > > 2018/5/23 Wed 21:29:43 UTC+9 Ni Va wrote: >> I build both 32 and 64 bits version of gvim but always 1 is returned when >> from 32bits or 64bits I do : >> >> echo has('num64') >> echo has('win32') >> echo

Re: feature to differentiate 32 from 64 bits build version

Hi, 2018/5/23 Wed 21:29:43 UTC+9 Ni Va wrote: > I build both 32 and 64 bits version of gvim but always 1 is returned when > from 32bits or 64bits I do : > > echo has('num64') > echo has('win32') > echo has('win64') > > What the feature to differentiate the two built 32/64bits You must have

Re: Patch 8.1.0020

Hirohito Higashi wrote: > 2018-5-23(Wed) 16:41:25 UTC+9 Christ van Willegen: > > Hi, > > > > On Tue, May 22, 2018 at 8:35 PM, Bram Moolenaar wrote: > > > > > > Patch 8.1.0020 > > > Problem:Cannot tell whether a register is being used for executing or > > >

Re: feature to differentiate 32 from 64 bits build version

Le mercredi 23 mai 2018 14:29:43 UTC+2, Ni Va a écrit : > Hi, > > > I build both 32 and 64 bits version of gvim but always 1 is returned when > from 32bits or 64bits I do : > > echo has('num64') > echo has('win32') > echo has('win64') > > What the feature to differentiate the two built

Re: feature to differentiate 32 from 64 bits build version

On Wed, May 23, 2018 at 2:29 PM, Ni Va wrote: > Hi, > > > I build both 32 and 64 bits version of gvim but always 1 is returned when > from 32bits or 64bits I do : > > echo has('num64') > echo has('win32') > echo has('win64') > > What the feature to differentiate the two

feature to differentiate 32 from 64 bits build version

Hi, I build both 32 and 64 bits version of gvim but always 1 is returned when from 32bits or 64bits I do : echo has('num64') echo has('win32') echo has('win64') What the feature to differentiate the two built 32/64bits Thank you NiVa -- -- You received this message from the "vim_dev"

Re: Patch 8.1.0020

Hi Hirohito Higashi, On Wed, May 23, 2018 at 12:05 PM, h_east wrote: > Hi Christ, > > Oh, It's my mistake. > Attached patch fixes this. > > Thanks for reporting! You're welcome! Christ van Willegen -- -- You received this message from the "vim_dev" maillist. Do not

Lua 5.4 32bits support

Hi, On Windows 10, 1. After download and build lua 5.4 current work I got a the lua.5.4.0.dll 32 bits and rename it to lua54.dll guidelines : https://blog.spreendigital.de/2015/01/16/how-to-compile-lua-5-3-0-for-windows/ 2. From gvim 32 bits 8.1.020 lua print('hell') says E448: Could not

Re: Patch 8.1.0020

Hi, On Tue, May 22, 2018 at 8:35 PM, Bram Moolenaar wrote: > > Patch 8.1.0020 > Problem:Cannot tell whether a register is being used for executing or > recording. > Solution: Add reg_executing() and reg_recording(). (Hirohito Higashi, > closes