Re: Absolute path on Windows changes working dir

[Ben Fritz]

On Tuesday, September 5, 2023 at 2:55:19 AM UTC-5 3nan@gmail.com wrote:
> 
> On Mon, 4 Sep 2023 20:16:09 -0700 (PDT)
> Ben Fritz  wrote:
> > This bit me while getting my TOhtml tests working on Windows with a 
Visual
> > Studio build environment. I'm not sure if it's a bug or not, but I can't
> > find any description of it in the help and it isn't acting as I'd 
expect.
> > Vim seems to change path to the directory containing a file, if it is
> > passed the absolute path WITH DRIVE LETTER to a file. I expect Vim to 
keep
> > its working directory the same as the directory it was launched from,
> > unless 'autochdir' is set or the directory is changed manually or with 
an
> > autocmd. I expect that using "-u NONE" should avoid any automatic 
methods.
> >
> > C:\Users\me\path\to\vim-src> .\vim.exe -u NONE rel\path\to\file.txt
> > :pwd
> > C:\Users\me\path\to\vim-src
> >
> > C:\Users\me\path\to\vim-src> .\vim.exe -u NONE
> > C:\Users\me\path\to\vim-src\rel\path\to\file.txt
> > :pwd
> > C:\Users\me\path\to\vim-src\path\to
> 
> I assume "C:\path\to\file.txt" was a commandline argument to Vim. If
> true, then that is a weird but documented behaviour.
> 
> See ":h win32-curdir":
> > If Vim is started with a single file name argument, and it has a full 
path
> > (starts with "x:\"), Vim assumes it was started from the file explorer 
and
> > will set the current directory to where that file is. To avoid this when
> > typing a command to start Vim, use a forward slash instead of a 
backslash.
> > Example:
> >
> > vim c:\text\files\foo.txt
> >
> > Will change to the "C:\text\files" directory.
> >
> > vim c:/text\files\foo.txt
> >
> > Will use the current directory.
> 

Perfect, thanks! I was poring over :help startup and :help vim-arguments
without finding anything at all. I think I might do some experimenting
to find where in the startup sequence that path is set, it might be
relevant for some plugins or autocmd debugging. Probably it's worth a
mention or a link in one of those two places!

I figured it has been around long enough it was probably intentional but
was confused not to find any mention of it.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/bb824e12-bea4-4f26-8c0a-de1624f229cdn%40googlegroups.com.

Absolute path on Windows changes working dir

[Ben Fritz]

This bit me while getting my TOhtml tests working on Windows with a Visual 
Studio build environment. I'm not sure if it's a bug or not, but I can't 
find any description of it in the help and it isn't acting as I'd expect. 
Vim seems to change path to the directory containing a file, if it is 
passed the absolute path WITH DRIVE LETTER to a file. I expect Vim to keep 
its working directory the same as the directory it was launched from, 
unless 'autochdir' is set or the directory is changed manually or with an 
autocmd. I expect that using "-u NONE" should avoid any automatic methods.

C:\Users\me\path\to\vim-src> .\vim.exe -u NONE rel\path\to\file.txt
:pwd
C:\Users\me\path\to\vim-src

C:\Users\me\path\to\vim-src> .\vim.exe -u NONE 
C:\Users\me\path\to\vim-src\rel\path\to\file.txt
:pwd
C:\Users\me\path\to\vim-src\path\to

Interestingly:
C:\Users\me\path\to\vim-src> .\vim.exe -u NONE 
\Users\me\path\to\vim-src\rel\path\to\file.txt
:pwd
C:\Users\me\path\to\vim-src

Right now, I can't easily compile any Windows Vim version prior to the 
introduction of Visual Studio 2022 support in v9.0.0528. The same behavior 
occurs in that version.

I downloaded zip file releases from 
https://github.com/vim/vim-win32-installer/ for the following older 
versions which also exhibit the same behavior, so it has been around for a 
long time:

 - 8.0.0003
 - 7.4.1185 (the oldest tag available which has prebuilt binaries)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7930f658-af38-4fa4-93fa-30a0146d7ef1n%40googlegroups.com.

Re: The future of the Vim project

[Ben Fritz]

On Wed, Aug 9, 2023 at 5:12 AM Christian Brabandt  wrote:
>
> Hi,
> I started making a few changes to continue with Vim. This is the current
> status:
>
> - Access to the github organization is possible and Ken and me have been
>   granted admin rights by Brams family, so we can continue with Github.
>   (Thanks @Fokke!)
>
> - I invited a few more members to join the Vim organization: Yegappan
>   Lakshmanan, Dominique Pellé, @mattn and @zeertzjq who have been
>   contributed to Vim in the past. Congratulations and welcome guys! ;)
>
> - People from the github organization should also have access to
>   huntr.dev (https://huntr.dev/repos/vim/vim/) where security problems
>   are being reported. We'll need to take a look there.
>
> - I merged the first 2 commits. As mentioned elsewhere, for now I will
>   try to merge only bug fixes, security related fixes, documentation
>   updates and other clear improvements. For the main source of Vim I'll
>   therefore like to have approval from the other project members before
>   merging anything yet. Please expect some bumps here, we need a bit of
>   time until we know how to properly handle all of this (and it may be
>   subject to change, when we all agree of a better method).
>
> - After we have gone through the current backlog, I'd like to get a Vim
>   9.1 maintenance release ready, until then we should continue with
>   incrementing the minor patch version. After the release, I am thinking
>   about moving to a more modern approach, similar to how Neovim is doing
>   it. But as discussed elsewhere, this may have some consequences for
>   the various subprojects: vim-win32-installer, vim-appimage, macVim, so
>   not sure what will be the best way.
>
> - I have access to the OSDN.net project page and am able to edit the
>   vim.org homepage. However for various reasons, we may have to move the
>   Vim homepage elsewhere. More on that further down.
>
> - Bram was owner of the all of the mailing lists. I don't know yet how
>   he managed this and how to request access specifically for
>   vim-announce and vim-mac (is this actually still used?) Does anybody
>   have a contact to the googlegroups admins?
>
> - The mailing lists vim-dev and vim-use are currently managed by myself,
>   Tony Mechelynk, John Beckett, Ben Schmidt and Ben Fritz (of whom I
>   think the last two are no longer active at least for the Vim project,
>   CC'ing them to see if they are still interested in managing this)
>
> [snip]
>
> - I am reaching out to all maintainers of the runtime files, to find out
>   if they have sent anything directly to Bram, which may otherwise be
>   lost. (to be done).
>
> [snip]
>
> That should be it for now, i hope I did not forget anything noteworthy.
>
> Let me know what you think.
>

Thanks for the CC and I'm certainly very sad to have seen the news about 
Bram.

And thank you Christian for taking on this leadership role. Yegappan,
Dominique, mattn, and zeertzjq: thanks to you guys too. It's comforting
to see Vim remains in good hands.

You're right, I have gone mostly inactive on the project and it probably
makes sense to take me off the mailing list managers group. You don't
*need* to take me off it, but I will probably not become active enough
to be an effective moderator/list manager in the near-term. In the
longer term, if I do end up finding time to become more active, I work
in InfoSec so I might be able to contribute to the huntr.dev project. I
wasn't aware that existed! I'll reach out on that at some other time.

Something I don't see mentioned in this email is the scan.coverity.com
project for Vim at https://scan.coverity.com/projects/vim. It looks like
you and Dominique are currently the project admins there, do we need to
add a few more (probably everyone in the GitHub organization)? I wonder
if it is possible to set the organization as admin over there, since
there is a "login with GitHub" feature.

I am still interested in maintaining the TOhtml plugin for which I am
the official maintainer, if Vim's development model continues to have
separate maintainers for the distributed plugins. However I will
understand if it is given over to someone more active (or if project
leadership wants a co-maintainer) as I have not been able to contribute
more than a couple bugfixes for the last few years. I have not sent any
unreleased updates to Bram.

If Vim development moves away from separate maintainers for the various
plugins, or if someone ends up taking over, I have been maintaining
TOhtml over at SourceForge where there is still free Mercurial hosting.
This project contains some automated testing (using Vim's own test
framework) which I have been slowly building with each feature addition
and bugfix, and should be part of however the script is maintained in
the futu

Problem with vim.org mailing list aliases?

[Ben Fritz]

Hello everyone!

Christian helpfully CC'd me on his email thread to the list about "The
future of the Vim project". I replied by email a few hours ago with a
lengthy post, but it still hasn't appeared on the web interface despite
me being subscribed to the list for many years. Is there some problem
that has developed with the vim-...@vim.org mailing list alias or other
@vim.org addresses in the last few days? I notice further emails in that
thread all use vim_dev@googlegroups.com instead. I don't want to cause a
double-post by trying again, if I just need to wait another day or so...

-- 
Ben

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/47168776-c1ce-4d86-8254-fb7e4c27303fn%40googlegroups.com.

More vim9 script developements

[Ben Fritz]

> a restriction will be that script-local items
are defined once and not deleted.  That makes it possible to find them
> by index, which is much faster than a dictionary lookup.

Does this mean "unlet" will no longer work for local variables if namespaces 
are used? How about exists(), does this add special cases?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/74d9eca6-12c7-4764-b29e-48add561e84a%40googlegroups.com.

Re: [vim/vim] patch 8.1.0956: using context:0 in 'diffopt' does not work well (b9ddda6)

[Ben Fritz]

On Wednesday, February 20, 2019 at 4:18:33 PM UTC-6, Bram Moolenaar wrote:
> 
> As mentioned, the fold code currently can't handle two folds without a
> 
> line in between.  Perhaps it can be made to work to consider a filler
> 
> line something in between folds.  No idea how difficult that is.
> 
> 

I played around with this last night and got two folds to show up with a pretty 
simple addition in fold.c to use the "start" field in the fold line struct for 
diff folding. I need to try to get the filler line to show up tonight or 
tomorrow. It looks like I'll need to copy some of the logic from win_line into 
fold_line in screen.c. That looks fairly complicated so I'm not entirely sure 
it will work but I *think* I figured out what's needed before I went to bed.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Does mingw build still work?

[Ben Fritz]

On Wednesday, February 13, 2019 at 1:03:10 PM UTC-6, John Marriott wrote:
> On 14-Feb-2019 03:51, Ben Fritz wrote:
> > I was trying to set up for building Vim on a Windows 10 installation where 
> > I haven't done that before.
> >
> > I tried the Msys distribution of mingw-64 first, and after I installed make 
> > and gcc using the package manager, I got compiler errors all over the 
> > place. Most errors to start with were for pretty basic things like 
> > _MAX_PATH not being defined (MAX_PATH is defined instead). I modified the 
> > code for simple macro replacements like that, and a few #ifdefs that were 
> > taking the wrong branch, but then I got to code in os_win32 that tried to 
> > use _putenv and _wputenv functions, which are not defined, and gave up that 
> > approach after a long time searching for a definition.
> >
> > Next I tried the MingW-W64-builds package. That doesn't include make 
> > either, but it has mingw32-make so I tried that, and got errors reading the 
> > makefile. Not seeing any documentation for this package, I moved on...
> >
> > ...to the normal, older 32-bit Mingw, which I have used in the past. I 
> > installed the gcc tools and Msys, tried to build Vim, and immediately got 
> > errors for a missing struct definition for 64-bit file types. Searching on 
> > the error led to suggestions to use Mingw-64.
> >
> > What am I doing wrong? Surely, somebody out there is still compiling Vim 
> > using Mingw? The makefiles are still there, I assume they work for someone.
> >
> > If you're that someone, what Mingw distribution are you using? Did you need 
> > to do any extra setup/installation beyond installing gcc and make?
> >
> Hi Ben,
> 
> I am building vim and gvim using mingw64 on Win8.1 and Win7. I've not 
> tried Win10 but I don't imagine it would be much different.
> 
> Firstly, I use the mingw64 build from here: 
> https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
> Try the 8.1 package. It includes make, but it is called 
> "mingw32-make.exe", so I copy it to "make.exe". Make sure that the 
> mingw64/bin folder within the package is in the path.
> 
> I put the vim source in the folder /vim. I make no 
> modifications to the code (except for a few changes in feature.h).
> In the  folder I put this batch file which I call 
> "make_it.cmd":
> 
> @echo off
> 
> setlocal
> set SRC_DIR=vim\src
> set /a NR_JOBS=%NUMBER_OF_PROCESSORS% + 1
> set COMMON_VARS=OPTIMIZE=MAXSPEED ARCH=native ICONV= GETTEXT= IME=no 
> DYNAMIC_IME=no POSTSCRIPT=no OLE=no WINVER=0x0603 CSCOPE=no NETBEANS=no 
> XPM=no DIRECTX=no FEATURES=NORMAL CHANNEL=no
> set GUI_VARS=%COMMON_VARS% LFLAGS="-Wl,-nxcompat,-dynamicbase -mwindows"
> set NOGUI_VARS=%COMMON_VARS% LFLAGS="-Wl,-nxcompat,-dynamicbase"
> set MAKEFILE=Make_ming.mak
> 
> title Building gvim...
> 
> make --directory=%SRC_DIR% GUI=yes %GUI_VARS% --environment-overrides 
> --jobs=%NR_JOBS% --makefile=%MAKEFILE% gvim.exe
> 
> title Building vim...
> 
> make --directory=%SRC_DIR% GUI=no %NOGUI_VARS% --environment-overrides 
> --jobs=%NR_JOBS% --makefile=%MAKEFILE% all
> 
> title Complete
> 
> exit /b 0
> 
> 
>  From the  folder I run the batch file. Note that 
> the make file is "Make_ming.mak", I am on Win8.1 hence the WINVER of 603 
> and the settings are for my specific build.
> 
> I hope this helps!
> Cheers
> John

Thanks for the help! I had tried using that mingw download and had trouble, but 
it turns out my trouble was because the automatic ARCH detection fails (sed 
commands don't seem designed for running a cmd.exe shell, even after manually 
downloading a sed binary for Windows).

If I manually specify:

mingw32-make -f Make_ming.mak ARCH=x86-64

...then the build succeeds!

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Does mingw build still work?

[Ben Fritz]

I was trying to set up for building Vim on a Windows 10 installation where I 
haven't done that before.

I tried the Msys distribution of mingw-64 first, and after I installed make and 
gcc using the package manager, I got compiler errors all over the place. Most 
errors to start with were for pretty basic things like _MAX_PATH not being 
defined (MAX_PATH is defined instead). I modified the code for simple macro 
replacements like that, and a few #ifdefs that were taking the wrong branch, 
but then I got to code in os_win32 that tried to use _putenv and _wputenv 
functions, which are not defined, and gave up that approach after a long time 
searching for a definition.

Next I tried the MingW-W64-builds package. That doesn't include make either, 
but it has mingw32-make so I tried that, and got errors reading the makefile. 
Not seeing any documentation for this package, I moved on...

...to the normal, older 32-bit Mingw, which I have used in the past. I 
installed the gcc tools and Msys, tried to build Vim, and immediately got 
errors for a missing struct definition for 64-bit file types. Searching on the 
error led to suggestions to use Mingw-64.

What am I doing wrong? Surely, somebody out there is still compiling Vim using 
Mingw? The makefiles are still there, I assume they work for someone.

If you're that someone, what Mingw distribution are you using? Did you need to 
do any extra setup/installation beyond installing gcc and make?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

how to report security bugs in vim

[Ben Fritz]

I suggest sending it to Bram directly.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tabs are not correctly expanded with 2html

[Ben Fritz]

Good to hear! I am still working on a couple other fixes before sending out a 
new version to put in the runtime files. Hopefully I'll finish this week. I'll 
try to remember to update this thread when done. :-)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] New search is horrible and difficult to disable (MINT19) (#3663)

[Ben Fritz]

On Wednesday, December 5, 2018 at 9:44:30 AM UTC-6, jonshouse1 wrote:
> Unfortunately people are still unhappy, partly because it seems there are 
> many people who do not use a user specific vimrc file and simply used the 
> system wide vimrc config file (I had a similar discussion with several Debian 
> users) which will get overwritten by defaults.vim as you found out.
> 
> 
> I read this as "I've had similar discussions with people who expect vim 
> configuration to act in a sane way" 
> 
> At very least  /etc/vim/vimrc should be parsed 2nd from last, $HOME/vimrc 
> last of all  ?  The USER should always win over the "default" yes ?
> 
> 

The USER does win. /etc/vim/vimrc is not for USER settings. Those are default 
settings that your distribution's packagers decided were best on their distro. 
For whatever reason, they decided that sourcing Vim's own default.vim was a 
good default setting for their distribution. They could easily have decided to 
source it and override some settings, or prevent it sourcing entirely, but they 
did not. Many distributions already change default Vim settingts: disabling 
modelines is one I've seen a few times. Enabling the syntax highlighting you 
apparently enjoy is another common one.

Your distribution decided the default settings would include those in 
defaults.vim. If you don't like the defaults for your distribution, then change 
them in your user settings. Or build and install your own Vim package with your 
own preferred default system settings.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tabs are not correctly expanded with 2html

[Ben Fritz]

On Wednesday, November 28, 2018 at 5:11:35 AM UTC-6, Axel Bender wrote:
> Using GVim 8.1. (Windows 10 64-bit), after applying a syntax scheme, 
> 2html.vim fails to correcly expand the tabs contained in the base document.
> 
> Sample files:
> 
> - sample.lang# The source file
> - lang.vim   # The syntax file
> - [sample.htm]   # Resulting output file

Please try this fix:

https://bitbucket.org/fritzophrenic/vim-tohtml/commits/07ce1eaa0a3f

I'll submit to Bram with a couple other bugfixes on my list later this weekend.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tabs are not correctly expanded with 2html

[Ben Fritz]

On Wednesday, November 28, 2018 at 5:11:35 AM UTC-6, Axel Bender wrote:
> Using GVim 8.1. (Windows 10 64-bit), after applying a syntax scheme, 
> 2html.vim fails to correcly expand the tabs contained in the base document.
> 
> Sample files:
> 
> - sample.lang# The source file
> - lang.vim   # The syntax file
> - [sample.htm]   # Resulting output file

Thanks for reporting, and for the clear reproducible example. I see slightly 
different behavior, but still wrong, on my end, probably due to differing 
settings.

I guess I know what I'm doing this weekend. :-(

I entered an issue in my tracker: 
https://bitbucket.org/fritzophrenic/vim-tohtml/issues/19/expand-tabs-broken-for-long-tabstops

If this is a show-stopper for you you can try downloading an older copy of the 
scripts. I assume those worked for you.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How about a release?

[Ben Fritz]

I also find myself wanting the vartabs feature any time I am working with 
columned format or taking notes in tabular form. I haven't bothered myself to 
go find and apply the patch because I need it so infrequently and for some use 
cases can just go open up a spreadsheet in a different program.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Do you have features to color the code embedded in markdown file? (#2678)

[Ben Fritz]

On Monday, February 26, 2018 at 6:55:04 PM UTC-6, CoinCheung wrote:
> For markdown files, there can be other programming language coded embedded 
> between the ``` ``` pair. however, in vim these code blocks does not have 
> highlighted syntax. Did I have the wrong configuration to turn this feature 
> off, or does vim have no such features?
> 
> 

>From looking at the syntax file it looks this is supported through the 
>"g:markdown_fenced_languages" variable. I can't find any documentation for 
>this, however. I think you need to set it to a list of syntax names (e.g. cpp, 
>dosini, bat, c, python, perl) to use for highlighting.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Certain configs in /etc/vimrc are ignored if ~/.vimrc does not exist (#2042)

[Ben Fritz]

On Wednesday, November 8, 2017 at 5:18:12 PM UTC-6, Wouter Verhelst wrote:
> Unluckily the defaults also set some things that I do think make sense, and 
> so if I just want to switch off the IMHO broken mouse behavior I first have 
> to copy most of defaults.vim to my own config file. That makes no sense.
> 

Instead of copying you can just source defaults.vim in your .vimrc, prior to 
turning off any options you don't like.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Buffer tab-completion doesn't work when buffer name contains backslash (#2201)

[Ben Fritz]

On Wednesday, October 11, 2017 at 2:39:38 PM UTC-5, xtal8 wrote:
> Vim: v8.0.1184 x64
> 
> Os: Windows 10 x64
> 
> Steps to reproduce
> 
> mkdir test
> vim --clean
> :e test\foobar
> :b test\fo
> completions are not provided
> 
> 
> If backslash is replaced with forward slash, completions also don't show up. 
> On linux completions are always provided when forward slash in present inside 
> buffer name.
> 
> 

I can reproduce in 8.0.495.

Oddly enough completion works if I type ":b test\" but not if I type 
further characters after the '\'.

As a workaround you can set the 'shellslash' option and then completion after 
forward-slash works.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] use strikethrough for diff filetype

[Ben Fritz]

On Saturday, October 7, 2017 at 2:30:32 AM UTC-5, Christian Brabandt wrote:
> On Fr, 06 Okt 2017, Ben Fritz wrote:
> 
> > https://bitbucket.org/fritzophrenic/vim-tohtml/issues/14/add-support-for-strikethrough
> > 
> > I am starting to get a backlog...I will try to get out a new version
> > with this and some bugfixes soon.
> 
> Would it be helpful to provide patches? I could have a look.
> 
> 

Sure, it might actually get me to stop putting off the work if I have a couple 
people waiting for their pull requests/patches to get included. :-)

I eventually need to get a real test suite made too but that's a separate 
issue. My old method of just running with every combination of options did 
*not* scale well as the number of options grew.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] use strikethrough for diff filetype

[Ben Fritz]

On Thursday, October 5, 2017 at 1:03:04 AM UTC-5, Christian Brabandt wrote:
> On Di, 03 Okt 2017, Ben Fritz wrote:
> 
> > I for one will definitely use it, I didn't remember that strikethrough
> > had been added! Thanks for the example, if nothing else!
> 
> There might also be changes for the 2html plugin needed.
> 

Thanks, I meant to create an issue yesterday and forgot. Here's one:

https://bitbucket.org/fritzophrenic/vim-tohtml/issues/14/add-support-for-strikethrough

I am starting to get a backlog...I will try to get out a new version with this 
and some bugfixes soon.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] gvim (windows) freezes when opening a file already openend in another Vim (with "simalt ~x" in GUIEnter) (#2192)

[Ben Fritz]

On Friday, October 6, 2017 at 9:57:28 AM UTC-5, daRAMA wrote:
> This was introduced somewhere between the first binary release of 8.0 and the 
> second one with patches 1-586 included and can still be reproduced in the 
> latest nighlty. Last tested with 1159.
> 
> To reproduce:
> 
> use a blank _vimrc with just "au GUIEnter * simalt ~x"
> gvim test.txt
> :w
> leave the instance open and start another vim: gvim test.txt
> 
> -> The second instance is opened and freezes (uses CPU and does not respond 
> to keyboard or mouse input)
> 
> 
> Use case for using two instances of vim on the same file: Do some coding in a 
> source file in the first instance and view the local changes in a source 
> control system (which launches a gvim -d file_in_working_copy 
> pristine_copy_of_file)
> 
> 

I'd guess it's waiting for your answer to a "swap exists" message. Does the 
second instance have anything else wrong with it (blank display, etc.)? What 
happens if you just press ENTER or type one of the swap exists answers 
(o/e/r/d/q/a)? 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] use strikethrough for diff filetype

[Ben Fritz]

On Tuesday, October 3, 2017 at 10:55:54 PM UTC-5, Manuel Ortega wrote:
> 
> 
> Am I the only one who looked at the screenshot and found it harder to read 
> than the non-strikethough version of diff highlighting?  Seriously, the 
> *color* is what tells the reader which text is the old text. 

Which is not as useful as you'd think, if you're colorblind. :-)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugins security issue

[Ben Fritz]

On Wednesday, September 27, 2017 at 8:59:18 AM UTC-5, dor.azo...@safebreach.com 
wrote:
> I would like to report a possible abuse one can perform on Vim's 
> extensibility mechanism, that may lead to privilege escalation.
> 
> In short, a malicious actor that can execute code as one of the sudoers (in 
> non-elevated mode), can write a plugin file to the plugins directory. Then he 
> needs to wait for that user to invoke the editor in elevated mode - and the 
> plugin that was written before, will be loaded with the root permissions.
> 
> The root cause that enables this abuse is basically incomplete separation 
> between regular and elevated execution modes of the editor (using "sudo"). I 
> can suggest possible solutions to this issue, e.g.: applying better 
> permissions to the plugins directories.
> 
> Reproduction steps:
> ===
> (This example shows how one can execute an external py script, though any 
> other pure vim script can prove the same)
> === 
> The following steps can be performed in a non-elevated mode:
> 1)  Write a py script to the plugins directory. Attached is a sample script 
> that tries to write a stub file to a root protected dir.
> 2)  Place it in ~/.vim/plugin/
> If a directory is missing, create it along the directory tree
> 3)  Create a vim script in the same folder (see attached script for example)
> 
> Now, each time you open vim, the python script will be executed. If you run 
> it elevated using sudo, the stub file will be created with root as owner.
> 
> I will be happy to provide more information as needed,
> Dor Azouri

This is exactly one of the reasons why one should use "sudoedit" and not "sudo 
vim" to change system files.

Using "sudoedit" instead of "sudo vim" lets you run Vim as a non-elevated user 
to write a temp file, and when Vim exits the temp file will be written over the 
file you were editing.

To use you need to set the EDITOR environment variable appropriately. I'm not 
sure whether VISUAL will also work.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] use strikethrough for diff filetype

[Ben Fritz]

On Monday, October 2, 2017 at 1:05:03 PM UTC-5, Bram Moolenaar wrote:
> Christian wrote:
> 
> > Bram,
> > since Vim can now display strikethrough attributes (in the gui), let's 
> > make a bit more use of it.
> > 
> > This patch adds the strikethrough attribute to the diff syntax file for 
> > deleted lines. Since this impacts readability, put the change behind a 
> > switch and document is properly.
> > 
> > For an example see the attached screenshot.
> 
> I can't say I like it, I would not use it.  But perhaps someone does.
> 
> Is setting a variable simpler than letting the user define his own
> highlight?  Well, I suppose that might not work well when switching
> colorschemes.  And your trick to copy the attributes from "Special"
> isn't something I would advertise...
>  

I for one will definitely use it, I didn't remember that strikethrough had been 
added! Thanks for the example, if nothing else!

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Ctrl-F mapping in mswin.vim (#1457)

[Ben Fritz]

On Friday, September 15, 2017 at 4:05:20 AM UTC-5, plbowers wrote:
> I couldn't get the au to work, but I just put unmap/iunmap/cunmap on separate 
> lines in my Prog.../Vim/_vimrc after the mswin.vim and it solved the problem. 
> Thanks for your help!
> 
> I see this as a workaround - I really think that redefining ctrl-F by default 
> for all Windows vim users is not a good idea.
> 

And I really think that sourcing mswin.vim in general is a bad idea. You can 
choose not to include "mappings for standard Windows shortcuts" or whatever the 
option is when you install Vim...

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] C: Improper indent of structs in return (#2090)

[Ben Fritz]

On Friday, September 15, 2017 at 12:37:29 PM UTC-5, Ben Fritz wrote:
> On Friday, September 15, 2017 at 10:31:10 AM UTC-5, Sam Pagenkopf wrote:
> > It seems to be consistent across indentation methods.
> > 
> > 
> 
> That doesn't make any sense, can you explain what options you actually tried?
> 
> 'autoindent' obviously won't do that, 'smartindent' is somewhat deprecated 
> and does stupid stuff like that all the time, and 'indentexpr' could do 
> anything at all depending on what plugin you have or function you've assigned 
> to it manually. So is it using 'cindent' or not?

I decided to check myself: yes, that's the behavior of 'cindent', with my 
'cinoptions' set to "(0,W2s".

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] C: Improper indent of structs in return (#2090)

[Ben Fritz]

On Friday, September 15, 2017 at 10:31:10 AM UTC-5, Sam Pagenkopf wrote:
> It seems to be consistent across indentation methods.
> 
> 

That doesn't make any sense, can you explain what options you actually tried?

'autoindent' obviously won't do that, 'smartindent' is somewhat deprecated and 
does stupid stuff like that all the time, and 'indentexpr' could do anything at 
all depending on what plugin you have or function you've assigned to it 
manually. So is it using 'cindent' or not?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Ctrl-F mapping in mswin.vim (#1457)

[Ben Fritz]

On Sunday, September 10, 2017 at 5:17:02 PM UTC-5, Christian Brabandt wrote:
> What is the preferred way of getting rid of this? Do I have to go in and edit 
> my mswin.vim file directly? Isn't that something you don't want people to do 
> so as to keep updates easy? Suggestions how I can dump these 2 new keymaps?
> 
> 

You could make a copy of mswin.vim and modify that. This will work if you use 
your own vimrc instead of the default one installed alongside Vim, because you 
can then change the command that sources it to source your own copy instead.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim8: ctrl-F goes into a search dialog instead of scrolling

[Ben Fritz]

On Monday, August 28, 2017 at 10:52:31 PM UTC-5, Ken Takata wrote:
> If you don't like it, you should create your own .vimrc (or _vimrc) in
> your home directory (normally C:\Users\\).
> 

Even better (if you use plugins and the like) is to create 
"C:\Users\\vimfiles\vimrc" so that everything is in one 
self-contained directory.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] wildignore disables `:args /path/to/ignored` (#1503)

[Ben Fritz]

Off-topic: for some reason my (fritzophrenic's) latest comment on Github was 
attributed to "Nikolai Alexsandrovich Pavlov" on the mailing list. Bug in a 
script somewhere?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim 7.4version source ~/.vimrc failed

[Ben Fritz]

On Tuesday, August 8, 2017 at 5:06:25 AM UTC-5, zhao-lei Xiong wrote:
> when I execute command:
> source ~/.vimrc
> 
> and it comes error like below:
> 
> /Users/jdcrew/.vimrc:14: command not found: syntax
> /Users/jdcrew/.vimrc:15: command not found: syntax
> /Users/jdcrew/.vimrc:34: bad pattern: ( 
> 
> and auto substitute of '(' '{' '[' to '()' '{}' '[]' also failed :(
> 
> 
> vim version:7.4
> os:macOS sierra

When you do command ":version", what are the first few lines? In particular, 
the feature set (HUGE, NORMAL, TINY, etc.).

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Vim is...not

[Ben Fritz]

:help design-not needs an update considering the recent work on running a 
terminal in Vim (even recursive vim in vim apparently):

> VIM IS... NOT *design-not*
> 
> - Vim is not a shell or an Operating System.  You will not be able to run a
> shell inside Vim or use it to control a debugger.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Seeking Help - Plugin Conflict with Hexmode (#1841)

[Ben Fritz]

On Monday, July 17, 2017 at 8:34:39 AM UTC-5, Tyler Akins wrote:
> /quote Is your Hexmode command defined to allow a | to separate it from 
> another command? I.e. did you use "command -bar Hexmode ..." to define it?
> 
> That's very interesting, and I'm glad that I asked. Yes, the command was 
> already defined like how you suggest. 
> https://github.com/fidian/hexmode/blob/master/plugin/hexmode.vim#L21
> command -bar Hexmode call ToggleHex()
> 
> 
> Do you have any other suggestions for why this could be misbehaving?
> 

It looks like $VIMRUNTIME/plugin/gzip.vim sets 'binary' *before* reading files 
with extension .gz, .bz2, etc. Then a BufReadPost autocmd calls gzip#read().

I assume the code in gzip#read() was written assuming binary is still set, in 
fact it *may* depend on that fact (speculation).

Either way, your code will turn *off* the 'binary' option to skip HexMode. It 
will still be off when the gzip plugin goes to read the file.

I suggest modifying your code to not process the files processed by gzip at 
all. Don't change the 'binary' option for these files but also don't call 
HexMode. Perhaps add another autocmd to set a flag for the gzip file extension 
list, or based on the previous value of 'binary'.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Patch v8.0.0677 breaks wincmd usage in FileType autocommands (#1839)

[Ben Fritz]

On Sunday, July 16, 2017 at 1:53:54 PM UTC-5, Bram Moolenaar wrote:
> Ben Fritz wrote:
> > 
> > I build version 8.0.724 and the behavior of "wincmd _" is now fixed, but
> > I don't see any patch description that seems to apply between 692 and
> > 724. Any ideas which patch actually fixed it? I'm trying to decide
> > whether I'm curious enough to try a bisect.
> 
> I do think that 8.0.0688 fixed this.  Perhaps the change didn't get
> picked up when rebuilding?  ex_cmds.h is included in ex_docmd.c, the
> dependency is in Make_cyg_ming.mak and Make_mvc.mak.
> 

It's not just me, this person saw it in patch 702: 
https://groups.google.com/d/msg/vim_dev/YBIjU974Zw0/TJd3t-moBgAJ

I'm doing something *very* similar (same function name, even).

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Patch v8.0.0677 breaks wincmd usage in FileType autocommands (#1839)

[Ben Fritz]

On Saturday, July 15, 2017 at 1:59:52 PM UTC-5, Christian Brabandt wrote:
> On Sa, 15 Jul 2017, Ben Fritz wrote:
> 
> > For determining whether a quickfix window is a location list or a
> > quickfix list, is there a different way to do that besides attempting
> > a ":copen" command? I get the same error for that command, even if I'm
> 
> you can use getwininfo(win_getid()) and check the 'quickfix' and 
> 'loclist' items.
> 

Thanks, I knew there would be a way with all the quickfix additions recently!

I now have a solution that works, although it's definitely annoying the 
":wincmd _" doesn't work.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Patch v8.0.0677 breaks wincmd usage in FileType autocommands (#1839)

[Ben Fritz]

On Saturday, July 15, 2017 at 6:27:27 AM UTC-5, Bram Moolenaar wrote:
> Ben Fritz wrote:
> 
> > On Friday, July 14, 2017 at 12:09:42 PM UTC-5, Bram Moolenaar wrote:
> > > Daniel Hahler wrote:
> > > 
> > > 
> > > 
> > > > Horsefly I can use another auto command then.
> > > 
> > > 
> > > 
> > > It might work to use the QuickFixCmdPost event and check if  ==
> > > 
> > > 'qf'
> > > 
> > 
> > Not if you're trying to respond to a ":copen" command.
> > 
> > I have autocmds using window-related commands in a "au Filetype qf" to:
> > 
> > 1. detect if it's a location list or a quickfix list (by using :copen and 
> > checking if the window changed)
> > 2. resize the quickfix window based on the number of entries
> > 
> > These are currently failing because of this change and I don't think there 
> > is a good way to accomplish these things anymore.
> 
> The resizing should work since 8.0.0688.
> 
> If you have remaining problems, please give a reproducible example.
> 

For resizing, if I use "exe 'resize' sizevar", it works.

If I use "exe sizevar 'wincmd _'" instead, it does not work, I get "E788: Not 
allowed to edit another buffer now"

For determining whether a quickfix window is a location list or a quickfix 
list, is there a different way to do that besides attempting a ":copen" 
command? I get the same error for that command, even if I'm already in the 
quickfix list and therefore it doesn't even need to switch buffers.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Patch v8.0.0677 breaks wincmd usage in FileType autocommands (#1839)

[Ben Fritz]

On Friday, July 14, 2017 at 12:09:42 PM UTC-5, Bram Moolenaar wrote:
> Daniel Hahler wrote:
> 
> 
> 
> > Horsefly I can use another auto command then.
> 
> 
> 
> It might work to use the QuickFixCmdPost event and check if  ==
> 
> 'qf'
> 

Not if you're trying to respond to a ":copen" command.

I have autocmds using window-related commands in a "au Filetype qf" to:

1. detect if it's a location list or a quickfix list (by using :copen and 
checking if the window changed)
2. resize the quickfix window based on the number of entries

These are currently failing because of this change and I don't think there is a 
good way to accomplish these things anymore.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Seeking Help - Plugin Conflict with Hexmode (#1841)

[Ben Fritz]

On Friday, July 14, 2017 at 7:55:31 AM UTC-5, Tyler Akins wrote:
> First off, I apologize for my lack of VimScript knowledge. I have adopted a 
> plugin that will allow users to edit files in hex when using vim -b and it 
> has the possibility of automatically editing files based on extensions or by 
> detecting high characters in a file. Editing the hex and saving the file will 
> automatically convert the hex back into binary. Pretty useful for data files 
> of various types.
> 
> The goal of this issue is to gain further understanding of VimScript and why 
> the plugin is conflicting with gzip. Hopefully people here are smarter than 
> me and can educate me in what I did wrong and how to avoid the issue.
> 
> A user of this plugin reported [a 
> problem](https://github.com/fidian/hexmode/issues/27] when loading a 
> compressed help file. These compressed help files are automatically excluded 
> from being edited by a check against the filename in my s:IsBinary function, 
> which is called on BufReadPost.
> au BufReadPost *
> \ let :binary = s:IsBinary() |
> \ if :binary |
> \   Hexmode |
> \ endif
> 
> 
> When editing a compressed help file, the following is displayed in vim:
> Error detected while processing function gzip#read:
> line 44:
> Error: Could not read uncompressed file
> E434: Can't find tag pattern
> 
> 
> I can even change s:IsBinary to simply do nothing and return 0 and the 
> problem is still triggered. Commenting out the BufReadPost commands allow the 
> file to be loaded and viewed (as text) correctly.
> 
> So, my question is revolving around my inability to understand why those 
> commands are triggering problems in the gzip plugin. Can anyone shed some 
> light on my plight?
> 
> 

Is your Hexmode command defined to allow a | to separate it from another 
command? I.e. did you use "command -bar Hexmode ..." to define it?

If you did not specify the "-bar" option, then the "| endif" is seen as an 
argument to the Hexmode command, and your "if" in unclosed. That could in 
theory prevent other BufReadPost autocmds from doing anything.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Vim vs swp files on Windows -- timing / time stamp issue? (#1741)

[Ben Fritz]

On Wednesday, June 7, 2017 at 1:55:14 PM UTC-5, kwizzz wrote:
> 
> As this is a corporate laptop...in the end I cannot deinstall my virus scanner
> 

I suggest asking IT if there is a whitelist folder pre-configured for the virus 
scanner. If you're a software shop at least, it's useful to have a place the 
developers can run the programs they themselves create. :-) Plus AV often 
interferes with version control.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Vim vs swp files on Windows -- timing / time stamp issue? (#1741)

[Ben Fritz]

On Friday, June 2, 2017 at 3:36:40 PM UTC-5, kwizzz wrote:
> I am having troubles with vim (8.0.586 and 7.4 downloaded from www.vim.org) 
> on Windows 7.
> 
> There seems to be a time stamp issue with swap files where swap files will not
> 
> get removed after closing vim with swap files being 1 second newer than saved
> 
> file; when trying to edit the file later, vim will complain with swap exists.
> 
> Steps to reproduce behaviour:
> 
> open a file (it does not matter if it exists or not) => vim will create
> 
> corresponding swp file
> do a short editing session (only a few (~4) seconds, not too long) and
> 
> immediately save and close it => swp file stays in file system in about 10%
> 
> (with a higher chance if hidden is set)
> 
> 
> Behaviour can be reproduced with a higher probability, if you open vim with a
> 
> file, do a :vimgrep/./* over about 20 or more text files in the folder,
> 
> randomly navigate through the findings (:cn & co) and close vim => some
> 
> opened (sometimes even simply grepped) files leave swap files.
> 
> Tried vim -u NONE with same behaviour.
> 
> Please let me know what to do to provide more information to you, as I am
> 
> somewhat lost here...
> 

It could be a virus scanner preventing Vim from deleting the file if it has it 
open for scanning.

It also could be a problem with a network share (you didn't say if any 
particular location is affected).

You could try experimenting with the 'directory' option to place all your swap 
files in a different local folder, especially if you can put that folder in a 
virus scanner whitelist.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: vim fail to execute some commands because of ordering in the script

[Ben Fritz]

On Sunday, May 28, 2017 at 3:10:42 AM UTC-5, Yubin Ruan wrote:
> empty lines are not deleted by "g/^\s*$/d".

It's because you used an unescaped '\' inside double quotes ('"'). Try either 
of the following:

exec "g/^\\s*$/d"
g/^\s*$/d

Note that the 'g' by itself starts an ex command, there is no reason to use 
exec here to transform a string into an ex command.

I'm not sure why the first version of the function works, to be honest.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Filetype detection sometimes fails in recent vim

[Ben Fritz]

On Wednesday, May 24, 2017 at 9:00:23 AM UTC-5, Marius Gedminas wrote:
> I'm on vim 8.0.597.  I've recently noticed that sometimes when I open a
> file from the quickfix list I get it without syntax highlighting.  The
>  is blank, and :verbose set filetype? doesn't show it being set
> by any script.  Re-opening the file with :e triggers filetype detection
> to run correctly.
> 
> I haven't been able to figure out how to reproduce the issue.
> 
> Has anyone else noticed this?
> 

I've also noticed it but I assumed the problem was due to my configuration and 
never spent time investigating which part. It's not readily reproduceable for 
me either.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [New Feature] reread (:edit) current line only

[Ben Fritz]

On Friday, May 19, 2017 at 9:11:16 AM UTC-5, Patrick Eigensatz wrote:
> Hi everybody!
> 
> 
> I use vim on a daily basis at work but also at home and I think as I write 
> this e-mail anyway, it would be a good place to thank you for all the effort 
> you put in it all the time! Thanks!
> 
> 
> 
> Now, as I stated, I use vim quite often but I wouldn't call me a vim 
> professional. I found myself a few times in the following situation:
> 
> I started hacking around on a configuration file when suddenly I noticed I 
> really messed up a section inside the file. Now either I invoke the ":edit" 
> command
> 
> where I lose all the "useful work" around the section, or I try to :u-ndo 
> until the few lines are in an original state again, losing all the "good 
> work" that I had done
> 
> after messing up the section. I usually end up opening a second editor 
> copying the original lines into the editor again, deleting my modification on 
> those lines.
> 
> I probably don't have to mention how tedious this is, especially if you're 
> inside an ssh connection... 
> 
> 
> 
> My questions: Is there a command I missed to reload only a single / a few 
> lines from the disk again? Would you consider such a feature useful for 
> yourself?
> 
> And what would you be an appropriate command for this function?
> 
> 
> I'm looking forward hearing your ideas and comments on this!
> 
> 

I would probably not use this feature, because the :DiffOrig command 
distributed in defaults.vim file meets all my needs in this area.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] setglobal for buffer-local options doesn't apply to buffers opened for file arguments? (#1712)

[Ben Fritz]

On Thursday, May 18, 2017 at 11:54:11 AM UTC-5, Jack Nagel wrote:
> I ran into what seems like a bug when setting the global value of a 
> buffer-local option from my .vimrc.
> 
> If I invoke vim this way.
> vim -N -i NONE -u NONE -c "setglobal autoindent" -- file
> 
> 
> I would expect the buffer for file to have autoindent set, but :set 
> autoindent? returns noautoindent.
> 
> However, if I invoke vim without a file argument,
> vim -N -i NONE -u NONE -c "setglobal autoindent"
> 
> 
> and instead open it using :e file, then :set autoindent? returns autoindent, 
> as expected.
> 

Per the help, "-c" runs a command "after the first file has been read (and 
after autocommands and modelines for that file have been processed)." So you 
cannot affect the first file using -c.

However, Vim also provides the "--cmd" argument, which "will be executed before 
processing any vimrc file." Try using that instead, it seems to work for me.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fold closes when pasting

[Ben Fritz]

On Wednesday, May 17, 2017 at 5:42:19 PM UTC-5, David Larson wrote:
> On Thursday, May 11, 2017 at 2:36:43 PM UTC-7, David Larson wrote:
> > When pasting a line at the beginning of an open fold, the fold closes. To 
> > reproduce:
> > 
> > % vim -N --noplugin -u NONE -U NONE -c "set sw=2 fdm=indent"
> > 
> > Then type:
> > One
> >   Two
> >   Three
> > 
> > (there are two spaces in front of “Two” and “Three”). Then within vim:
> > 
> > :2normal YP
> > 
> > The fold is now closed and the pasted line is hidden in the fold.
> > 
> > I can reproduce this with vim 8.0 patch 402
> 
> Bump.

Confirmed in 64-bit 8.0.586 on Windows 7.

It happens whenever a new indented line is pasted below the unindented line.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: sha256 key data is not zeroed

[Ben Fritz]

On Thursday, May 11, 2017 at 1:47:35 PM UTC-5, Bram Moolenaar wrote:
> 
> The missing piece of information is how this is useful.  Keep in mind
> that the actual key is also in memory (so that it can be used when
> writing the file).  Not sure how clearing a derevative of it helps.
> 

I think it would be useful to clear any of the crypto information when it is no 
longer needed. Not just derivations of the key but the key itself should be 
cleared when no longer needed. The longer that sensitive information hangs 
around in memory, the more changes it gets written out to swap space. If 
someone has opened an encrypted file, then closed it after 10 seconds, it's 
still quite likely their sensitive data has not been written to swap. But if 
the data still hangs around in freed application memory that has not yet been 
re-used, when that same Vim session is still open 3 days from now then the 
sensitive data is almost certainly stored in swap space now.

As a side note, if Vim is not attempting to prevent in-use key data from 
getting swapped out, it probably should be.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] setfiletype does not work in packages (#1679)

[Ben Fritz]

On Thursday, May 4, 2017 at 10:56:21 AM UTC-5, Andy Stewart wrote:
> 
> I believe this is because vim's filetype detection uses:
> 
> runtime! ftdetect/*.vim
> 
> I think that when that line is executed, the plugins in 
> ~/.vim/pack/stuff/start/ are not on the runtimepath.  So Vim falls back to 
> its generic configuration file.
> 
> When I change that line to:
> 
> runtime! ALL ftdetect/*.vim
> 
> – the filetype is set as expected.
> 
> Vim 8.0.586.
> 


Hmm, that will also search in "opt" packages. I don't think that's wanted 
unless the user has used packadd already in which case it will be in the 
runtimepath. Probably it should just search the "start" packages and then the 
runtime. How is this done? Does it need two runtime commands, first "runtime! 
START ftdetect/*.vim" followed by "runtime! ftdetect/*.vim" to pick up the 
runtimepath files?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Introduce 'uselast' option for 'switchbuf'. (#1652)

[Ben Fritz]

On Sunday, April 23, 2017 at 11:38:46 AM UTC-5, yegapp...@gmail.com wrote:
> Hi,
> 
> On Sun, Apr 23, 2017 at 7:03 AM, LemonBoy  wrote:
> >
> > This behavior is more intuitive IMO, full backward compatibility is
> > achieved by introducing a new option, a test is provided but makes no sense,
> > gotta adjust it if you like the patch.
> >
> 
> If I understand correctly, when jumping to a quickfix entry, you want to use
> the previous window instead of the window just above the quickfix window.
> Is that correct?

Isn't that what already happens without this option?

I have a quickfix list open right now. When I open a new window then do 
CTRL-W_b to go to the quickfix window, pressing enter on any item jumps to the 
result in the previous (top) window, not one of the two windows directly above 
the quickfix window.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Netrw doesn't enter the directory symbolic link (#445)

[Ben Fritz]

On Monday, April 17, 2017 at 9:02:30 PM UTC-5, Tallys Martins wrote:
> Up
> 
> 

Did you try going to Dr. Chip's website at 
http://www.drchip.org/astronaut/vim/index.html#NETRW to download his latest 
changes to netrw? If so, what was the result? If that version is still broken, 
how about the other information he asked for to help debug? Dr. Chip stated he 
was unable to reproduce, and asked:

* what netrw options, if any, are you using?
* what options are you using other than netrw ones?  acd, in particular,
can sometimes cause difficulties 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: modeline documentation is misleading

[Ben Fritz]

On Tuesday, April 11, 2017 at 10:31:52 AM UTC-5, Bruno Bronosky wrote:
> https://github.com/vim/vim/blame/e0720cbf63eb3045be8d965e3182c0c392c7b5e9/runtime/doc/options.txt#L505
> 
> 
> 
> 
> The second form (this is compatible with some versions of Vi):
> 
> 
> 
> 
> https://github.com/vim/vim/blame/e0720cbf63eb3045be8d965e3182c0c392c7b5e9/runtime/doc/options.txt#L513-L514
> 
> 
> 
> 
> se[t] the string "set " or "se " (note the space); When
>   "Vim" is used it must be "set".
> 
> 
> 
> 
> The first line came in with v7. The last line was added many (7+?) years 
> later. I'd like to change the first line to say...
> 
> 
> https://github.com/RichardBronosky/vim/commit/9e96fc0a79b5a1d2563cf0462a7f81db397b10ef
> 
> 
> 
> 
> The second form (this is compatible with some pre-7.0 versions of Vi):
> 
> 

Vi is not the same as Vim. The second form works in all versions of Vim.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unnamed register only contains the last deleted text when appending deleted text to a register

[Ben Fritz]

On Monday, April 10, 2017 at 3:40:21 PM UTC-5, Wolfgang Jeltsch wrote:
> Am Montag, den 10.04.2017, 08:32 -0700 schrieb Ben Fritz:
> > My mistake. I CAN reproduce the issue, I tested the wrong thing. Sorry
> > about that! I also see that pasting from the unnamed register, after a
> > series of deletes into an UPPERCASE named register, pastes only the
> > last delete instead of the entire named register.
> > 
> > I agree it looks like a bug, and it looks like it's been around for a
> > while now!
> > 
> > At least, the help text doesn't match the actual behavior. I think the
> > behavior described in the help text would be more useful than the
> > actual behavior.
> 
> I also think that the behavior described in the help text would be more
> useful.
> 
> Should I file a bug report somewhere?
> 

Posting to this list should be enough.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unnamed register only contains the last deleted text when appending deleted text to a register

[Ben Fritz]

On Monday, April 10, 2017 at 10:26:27 AM UTC-5, Wolfgang Jeltsch wrote:
> >
> > I can't reproduce this in 8.0.427 64-bit gvim on Windows. What version
> > of Vim are you using? Does it do the same thing without your
> > configuration loaded, e.g. when launching with "gvim -N -u NONE -i
> > NONE"?
> 
> Yes, the behavior is the same with “gvim -N -u NONE -i NONE”. I use
> Vim 7.4 including patches 1–1689 on Ubuntu 16.04 LTS.
> 

My mistake. I CAN reproduce the issue, I tested the wrong thing. Sorry about 
that! I also see that pasting from the unnamed register, after a series of 
deletes into an UPPERCASE named register, pastes only the last delete instead 
of the entire named register.

I agree it looks like a bug, and it looks like it's been around for a while now!

At least, the help text doesn't match the actual behavior. I think the behavior 
described in the help text would be more useful than the actual behavior.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unnamed register only contains the last deleted text when appending deleted text to a register

[Ben Fritz]

On Monday, April 10, 2017 at 9:39:20 AM UTC-5, Wolfgang Jeltsch wrote:
> Hi!
> 
> The Vim documentation says the following under “quote_quote” about the
> unnamed register ("):
> 
> > 
> > Vim fills this register with text deleted with the “d”, “c”, “s”, “x”
> > commands or copied with the yank “y” command, regardless of whether
> > or not a specific register was used (e.g. "xdd). This is like the
> > unnamed register is pointing to the last used register. Thus when
> > appending using an uppercase register name, the unnamed register
> > contains the same text as the named register.
> However, the part with uppercase register names does not work for me
> when deleting. I only get the last deleted text into the unnamed
> register. For example, when I enter "add and then "Add, register a
> contains both deleted lines, but the unnamed register only contains the
> last one, although it should contain the same text as register a.
> However, things work as expected with the yank (y) command.
> 
> I asked on StackExchange why this is and several people told me that
> this seemed like a bug to them. So is this a bug? If not, why is Vim
> behaving like this?
> 
> All the best,
> Wolfgang

I can't reproduce this in 8.0.427 64-bit gvim on Windows. What version of Vim 
are you using? Does it do the same thing without your configuration loaded, 
e.g. when launching with "gvim -N -u NONE -i NONE"?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] `ygn` doesn't behave like `dgn` (#1587)

[Ben Fritz]

On Thursday, March 23, 2017 at 12:00:55 PM UTC-5, rafaeln wrote:
> . only repeats a yank if you have se cpo+=y in your .vimrc.
> 
> 

I didn't know that, thanks!

However, "ygn" is still working as I would expect. The "gn" operator operates 
on the match *under the cursor*, or the next match. Since ygn leaves the cursor 
on the match I'd expect the next ygn (or .) to yank the same match. Delete 
works because the match is no longer there so the gn must apply to the next 
match instead. You could move the cursor between yanks to do what you want, of 
course.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] `ygn` doesn't behave like `dgn` (#1587)

[Ben Fritz]

On Wednesday, March 22, 2017 at 2:56:26 PM UTC-5, rafaeln wrote:
> In operator mode, gn becomes very useful far batch operations. For instance, 
> dgn can be repeated with . to delete multiple instances of a match. However, 
> ygn can't be repeated with . to yank multiple instances of a match. That by 
> itself would be useless, of course, since it only amount to overwrite the " 
> register with the last match. In conjunction with an uppercased register, 
> however, the command would allow one to collect all the matches into the same 
> register. Say, you first clean a register—for concreteness, register "a—with 
> qaq, then you execute "Aygn to copy the first instance of a match into the 
> register and would like to be able to repeat the command with . to keep 
> collecting all matches into the same register. That doesn't work, though. 
> Even though . repeats the command, the cursor never jumps to the next match, 
> and all you end up doing is copying the same instance of a match over and 
> over into the same register. I started vim with vim --cmd 'set 
> rtp=$VIMRUNTIME' --cmd 'se nocp cpo+=y' -u NONE
> 
> 

Are you sure it repeats the command? I don't expect '.' to repeat a yank 
command, ever. I would consider it a bug if it did!

I did just test and for me the '.' command does *not* repeat a yank. For 
example with the following text, search for /abc\+d and use ygn followed by p 
followed by ygn and then move the cursor to another match and press '.'. The 
paste is repeated as expected, not the yank:

abcd abd abccd abd abcccd

You can do exactly what you want by recording a macro, however.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

[Ben Fritz]

On Monday, March 13, 2017 at 3:11:04 PM UTC-5, Ben Fritz wrote:
> On Monday, March 13, 2017 at 3:04:51 PM UTC-5, Andy Wokula wrote:
> > 
> > I'd vote for  [count]^  going to the [count]th character in the line.
> > (We can easily go to the [count]th screen column and to the [count]th
> > byte, but not yet to the [count]th character, unless I'm missing
> > something).
> > 
> 
> While useful, "[count]th character" doesn't seem to fit well with "1st 
> non-blank character" to me. Maybe "[count]th non-blank character" would make 
> more sense but I'm not sure how useful that would be.

...actually on further thought, "[count]th non-blank" could be useful for 
editing text in comments where ^ by itself is less useful. Consider:

//this is
//a multiline comment
//which has been indented

One could then use 3^ to jump to the beginning of the comment text.

Of course right now one can simply ^W to accomplish the same thing. But 
although the same number of keystrokes, it's 2 commands instead of just one. 
This could make a difference in operator-pending mode, for example.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

[Ben Fritz]

On Monday, March 13, 2017 at 3:04:51 PM UTC-5, Andy Wokula wrote:
> 
> I'd vote for  [count]^  going to the [count]th character in the line.
> (We can easily go to the [count]th screen column and to the [count]th
> byte, but not yet to the [count]th character, unless I'm missing
> something).
> 

While useful, "[count]th character" doesn't seem to fit well with "1st 
non-blank character" to me. Maybe "[count]th non-blank character" would make 
more sense but I'm not sure how useful that would be.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

[Ben Fritz]

On Sunday, March 12, 2017 at 10:33:06 AM UTC-5, Bram Moolenaar wrote:
> Someone noticed that although $ takes a count to go down (count - 1)
> lines, the ^ does not.  Since currently the count is ignored, we could
> make it used to go (count - 1) lines up.
> 
> Would this break anything?
> 

We currently have _ and g_ that are similar to ^ and $, except that ^ doesn't 
take a count.

_ goes downward or stays on the same line. To move up, you can use -, which 
always goes up, it won't stay on the same line.

It would make more sense for me if ^ went downward rather than upward when 
given a count. This would be consistent with existing commands. But I won't be 
extremely disappointed if it goes upward instead, it would just be one more 
oddity in an editor full of such quirks. :-)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: added TextDeleted and TextYanked events

[Ben Fritz]

On Saturday, March 4, 2017 at 6:47:33 AM UTC-6, Bram Moolenaar wrote:
> Philippe Vaucher wrote:
> 
> > On Monday, February 29, 2016 at 4:13:31 PM UTC+1, Björn Linse wrote:
> > > For the record, a version of this was merged into neovim:
> > > https://github.com/neovim/neovim/pull/4304
> > 
> > Hehe, I just noticed that!
> > 
> > Thanks :-)
> > 
> > So reguarding vim, 6 years ago this was put in the TODO in the "As
> > soon as possible" section. Today this patch still sits there...
> > maybe... just maybe... is there some kind of problems with the patch
> > submission process? *wink wink*
> 
> I don't recall anyone asking for this feature in the past six years.
> If there was a discussion about how this is useful for more than one
> user, it would have been moved up in the todo list.
> 
> Including just every patch available leads to a mess.  Also,
> autocommands are a clumsy mechanism, thus I hesitate to add more of it.
> 
> I had a brief look at the comments, and it appears the functionality
> would be better done with some kind of callback.
> 

Aren't autocmds basically Vim's way of doing callbacks?

I don't personally feel the need for one, but I know many people would like a 
"yank ring" style of plugin or other sort of clipboard management which this 
patch would enable.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Compile fails with undefined macro on Solaris 9 starting at patch 8.0.0219

[Ben Fritz]

So, I know this is a very old system, but I've been self-compiling Vim on it 
successfully for some years now (I'm not an admin on the system):

$ cat /etc/release
   Solaris 9 12/03 s9s_u5wos_08b SPARC
   Copyright 2003 Sun Microsystems, Inc.  All Rights Reserved.
Use is subject to license terms.
   Assembled 21 November 2003
$ gcc --version
2.95.2



Trying to compile Vim, starting at patch 8.0.0219 (found by bisect) gives 
either an error in eval.c:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF  -I/usr/dt/include   -g -O2 
-I/usr/openwin/include   -o objects/eval.o eval.c
eval.c: In function `eval6':
eval.c:4113: `INT_MIN' undeclared (first use in this function)
eval.c:4113: (Each undeclared identifier is reported only once
eval.c:4113: for each function it appears in.)
eval.c:4115: `INT_MAX' undeclared (first use in this function)
*** Error code 1
make: Fatal error: Command failed for target `objects/eval.o'



...or this error in charset.c:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF  -I/usr/dt/include   -g -O2 
-I/usr/openwin/include   -o objects/charset.o charset.c
charset.c: In function `vim_str2nr':
charset.c:1905: `UINT_MAX' undeclared (first use in this function)
charset.c:1905: (Each undeclared identifier is reported only once
charset.c:1905: for each function it appears in.)
charset.c:1971: `INT_MAX' undeclared (first use in this function)
charset.c:1972: `INT_MIN' undeclared (first use in this function)
*** Error code 1
make: Fatal error: Command failed for target `objects/charset.o'



Editing src/structs.h to insert the following line allows me to compile, but 
possibly it needs to be wrapped in some conditional preprocesser logic:

#include 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Text object i[ behavior in todo.txt

[Ben Fritz]

I noticed today that todo.txt contains the following:

> "ci[" does not look for next [ like ci" does look for next ".
> (J.F. 2017 Jan 7)
> 

I'd like to express my support for the CURRENT behavior. I like being able to 
work with constructs like this, if needed:

abc[
func(def[123],
 ghi[123],
 jkl[123]) ] 

Or like this in Vim script:

let mylist = [
  \[1, 2, 3],
  \[4, 5, 6],
  \[7, 8, 9],
  \ ]

If the behavior of the i[ text object is changed, I won't be able to use it in 
nested [...] blocks such as these!

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Gvim spellcheck right-click change not consistently working (#1483)

[Ben Fritz]

On Thursday, February 16, 2017 at 10:34:49 AM UTC-6, Jon Crall wrote:
> I have a latex document and in it I've spelled the word "intermittently" 
> incorrectly as intermittenly.
> 
> \documentclass[10pt,twocolumn,letterpaper]{article}
> \usepackage[T1]{fontenc}
> 
> \begin{document}
> 
> \title{A minimum working example of a bug}
> 
> The bug is that intermittenly is spelled wrong, and has a yellow squiggle.
> However, if I right click and select ``Change "intermittenly" to
>   intermittently'' it usually does nothing, but sometimes it will change 
> it.
> \end{document}
> 
> Spell check correctly identifies the two instances of this with a yellow 
> squiggle underneath. However, if I right click to fix it does not always 
> work. I can't figure out the conditions to consistently reproduce the error.
> 
> Typically nothing happens when I click change. However, sometimes it works 
> and changes the word. Furthermore, if I undo the change and then right click 
> and change again it typically does nothing again.
> 
> I'm at a loss to what is causing this behavior.
> 
> I've tested this with a very minimal .vimrc
> 
> source $VIMRUNTIME/mswin.vim
> behave mswin
> 

I don't know what could be causing your right-click error, but in case you just 
need a fast solution, you can use z= on your keyboard to get spelling 
suggestions for misspelled words.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: tag priority

[Ben Fritz]

On Wednesday, February 8, 2017 at 2:27:40 PM UTC-6, DrChip wrote:
> Hello:
> 
> Maybe I was just lucky for years, but it seemed to me that the order of
> tags files (left to right in the tags option) and order of tags
> (top-to-bottom in the tags file) was important in resolving multiple
> tags with the same name.  That no longer seems to be the case, which
> makes it hard to avoid prototypes vs the actual function from being
> called up as the first tag (and system prototypes, too).
> 
> So -- was I just lucky, or is a deliberate change, or (hopefully) an
> inadvertent effect that needs fixing?
> 
> Regards,
> Chip Campbell

I think you just have been lucky. I've had this in my .vimrc for a few days shy 
of four years now, to allow me to find the definition before the declaration:

" -R   : recursive
" --extra=+f   : include file name as a tag
" --fields=+S  : include signature (e.g. parameter list)
"   K  : include kind of tag as full name
"  -k  : not kind of tag as single letter
" --totals : print on standard output total number of tags, etc.
" -B   : reverse search order for definitions
" --c-kinds=p  : only generate function prototype in C code, normal search 
order
" -a   : append to existing file
let ctags_command=ctags_exec.' -R --langmap=c:+.pro 
--extra=+f --fields=+SK-k --totals -B .'
let ctags_command=ctags_command.' & '.ctags_exec.' -R --langmap=c:+.pro 
--extra=+f --fields=+SK-k --totals --c-kinds=p -a .'

It works because the definitions use a backwards search so that it searches up 
from the bottom of the file instead of down from the top, finding the LAST 
match for the pattern in a given file.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: text-objects / (Slash)

[Ben Fritz]

On Thursday, January 12, 2017 at 2:37:12 AM UTC-6, Afanasiy Fet wrote:
> Can you add
> 
> /
> 
> to text-objects list.
> 
> :h text-objects
> :h object-select
> 
> The commands that start with "a" select "a"n object including white space, the
> commands starting with "i" select an "inner" object without white space, or
> just the white space.
> 
> The slash is used in internet URLs
> (e.g., http://en.wikipedia.org/wiki/Slash_(punctuation) )
> 
> The slash is used as the path component separator in many
> computer operating systems (e.g., Unix's /pictures/image.png)

Are you asking for implementation of a new text object which will match the 
region between two '/' characters?

I'd rather see this patch included, to match the region between two arbitrary 
"matched pairs":

https://github.com/vim/vim/pull/958

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [patch] :make doesn't support encoding conversion

[Ben Fritz]

On Tuesday, January 3, 2017 at 3:25:46 AM UTC-6, Christ van Willegen wrote:
> 
> So mixed spaces and tabs are allowed? I couldn't find anything about
> that with a quick google search (too many questions are asked aobut
> tab stops etc :-) )
> 
> Ah, I see that on lines that you've changed, there were already spaces
> and tabs. You're right.
> 

Not just allowed, but actually required by the current coding standard used in 
Vim.

Specifically, it's expected that you set:

sts=4 ts=8 noet sw=4

(or at least, if my memory serves correctly)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim 25 birthday presentation

[Ben Fritz]

On Wednesday, December 14, 2016 at 1:40:12 PM UTC-6, Bram Moolenaar wrote:
> Hello Vim users!
> 
> On November 2nd I did a presentation about Vim at Google Zurich.
> This is exactly 25 years since the first public version of Vim was
> built.
> 

Wow, a quarter of a century! Congratulations, Bram, on starting such a 
successful project!

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fold-related bug and pointer to fix

[Ben Fritz]

On Tuesday, December 13, 2016 at 6:37:54 AM UTC-6, Efraim Yawitz wrote:
> Has any fix been made for this?  I'm not subscribed to vim_dev, and there are 
> a lot of messages to look through in the archives.
> 
> Thanks,
> 
> Ephraim
> 
> 

I don't see it in the todo list nor do I see it in the recent patches.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Jump between words and stop at end of line (#1323)

[Ben Fritz]

On Tuesday, December 13, 2016 at 4:54:46 AM UTC-6, j16180339887 wrote:
> 
> In normal mode, b and w are jumping between words,
> 
> and I would like to stop at the end of line.
> 

Normally I'd say asking on vim_use would be the correct place for this question.

But then I noticed the 'whichwrap' doesn't allow changing behavior of w/b. That 
seems like it'd be a good feature addition! I'm not sure how it could be done 
and remain backwards-compatible however.

If we can assume people follow best practices and use :set whichwrap+=whatever 
instead of setting the full option value then just changing the defaults to 
include the w/b control would mostly do the trick but without that assumption 
behavior would change.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fold-related bug and pointer to fix

[Ben Fritz]

On Wednesday, November 23, 2016 at 4:39:24 AM UTC-6, Efraim Yawitz wrote:
> I had the following problem and I think it is a bug in some fold-related code:
> 
> I was trying to use the NarrowRegion plugin to do diffs between two functions 
> in the same file by creating narrowed buffers for each function and calling 
> :diffthis on them.  When I tried to do this using folds, i.e. 
> :.,+2NarrowRegion to create a buffer for a folded-up function which looked 
> like this:
> 
> int FuncName() {
> .folded
> }
> 
> I got everything but the final brace in the narrowed buffer.  Eventually I 
> discovered that this has nothing to do with NarrowRegion, but just a yank 
> such as:
> 
> :.,+2y
> 
> over a fold gives only the folded lines but not the line after the fold.
> 
> A normal command of y2j works just fine and gets the line after the fold.  

I can confirm this looks like a bug, seeing the same behavior in 64-bit Vim 
8.0.95 on Windows 7.

It gets worse actually. I tried several yanks from code that looks like this in 
Vim:

  else
  { ---3 lines folded--- }
#endif

  if ( ---2 lines folded--- )

With the cursor on the top "else" line:

:.,+2y yanks only the "else" and the folded lines beneath, when I expect to 
also get the #endif

:.,+3y yanks the exact same thing (omitting the #endif *and* the empty line)

:.,+4y finally includes the #endif (with nothing after it) but I expected it to 
yank everything from "else" to the content of the second folded section.

The :d command acts in the same way.

It appears something is wrong with handling of folded lines in the ranges 
specified for ex commands.

Forwarding to vim_dev as this appears to be a bug.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Guiding users not to put questions on GitHub Issues page

[Ben Fritz]

We are getting a lot of issues created on GitHub to ask questions instead of 
reporting an issue.

I think it is not clear enough where to get help, from the GitHub page. More 
and more people are apparently finding Vim from its GitHub page these days.

Right now when you create a new issue, a banner pops up saying only "Please 
review the guidelines for contributing to this repository." The linked 
guidelines don't really make it clear how to ask for help, they just talk about 
how to report issues.

I assume we have control over that banner's content. What about explicitly 
adding text to this banner like, "Please only put bug reports in this issue 
tracker, and use the vim_use mailing list to ask questions."

Also, where to get help should be documented in the main README.md file 
displayed on the project home page, otherwise people will just assume it's the 
issue tracker. Perhaps add it more explicitly to the contribution guidelines as 
well.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: update to todo.txt

[Ben Fritz]

On Tuesday, September 27, 2016 at 2:09:10 PM UTC-5, Christian Brabandt wrote:
> -Using ":make" blocks Vim.  Allow running one make in the background (if the
> -shell supports it), catch errors in a file and update the error list on the
> -fly.  A bit like "!make > file&" and repeating ":cf file".  ":bgmake",
> -background make.  ":bgcancel" interrupts it.

Is this removed, because of the job features added? So this depends on a 
plugin? Is there a plugin out there already that integrates with Vim's compiler 
options for generic compiler support, which should be included in or pointed to 
by Vim?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Vim cryptmethod is not authenticated (#638)

[Ben Fritz]

On Friday, August 26, 2016 at 11:15:19 AM UTC-5, Marvin Renich wrote:
> 
> > I am not suggesting there is nothing to fix. I think Vim's crypto is too
> > weak for it to be very useful for important data.
> ^
> 
> That is the salient point.  What type of data do people use Vim to
> secure, and why do they choose Vim over other cryptographic tools to do
> it?
> 

Well, here's the sort of thing I worry about the most far most users:

http://www.vim.org/scripts/script.php?script_id=5340
http://usevim.com/2013/11/27/password-manager/
https://invert.svbtle.com/using-vim-as-a-password-manager
https://stelfox.net/blog/2013/11/using-vim-as-your-password-manager/
http://vim.wikia.com/wiki/Keep_passwords_in_encrypted_file

And then of course somebody could get the bright idea of encrypting a 20GB CSV 
file of medical data to put on a flash drive or something.

I'd hope dissidents and the like use tools more designed for the task already.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] add SearchHitBoundary autocommand group (#1009)

[Ben Fritz]

> 
> 
> By the way, an easier way to ring a bell may be 'exe "norm! "', 

Formatting lost on mailing list, this should be 'exe "norm! \"'.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Vim cryptmethod is not authenticated (#638)

[Ben Fritz]

On Thursday, August 25, 2016 at 11:33:33 AM UTC-5, Aaron Toponce wrote:
> Blowfish is a 64-bit cipher. Given the recent news with the Sweet 32 Birthday 
> Attack on 64-bit ciphers, this bug really should be reconsidered. Not only 
> for authenticating the ciphertext, but also completely dropping Blowfish, and 
> using a 128-bit block cipher like AES instead.
> 
> 

Sweet32 relies on reading a LOT of data using the same key. It's processing 
HUNDREDS OF GIGABYTES of data over the course of many hours of network traffic.

If you're encrypting hundreds of gigabytes in Vim using the same key, you're 
using it wrong. Vim is not a full-disk encryption system, nor a network data 
encryption tool.

Blowfish is still useful in Vim. I agree we should add a new cipher without a 
bunch of caveats, and this specific issue regarding the weakness of the derived 
key needs fixing, but Sweet32 has nothing to do with any real-world scenario 
where Vim would be used.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 'preserveindent' mixing spaces and tabs

[Ben Fritz]

On Wednesday, August 10, 2016 at 2:26:55 AM UTC-5, Rob Foehl wrote:
> 
> Since the behavior of 'preserveindent' is already dependent on 
> 'expandtab', would you or anyone else be opposed to changing the 'noet' 
> case to avoid alternating tabs and spaces?  Oversimplifying a bit, and 
> particularly glossing over 'shiftwidth' and the actual modification point, 
> the effective behavior would be:
> 
> 'pi et': preferentially adjust spaces after tabs
> 'pi noet': preferentially adjust tabs before spaces
> 
> This looks doable, although I haven't tried anything yet...  Thoughts?
> 
> -Rob

Probably that would work OK. The devil is in the details, of course. :-)

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Add support for "match" textobjects (#958)

[Ben Fritz]

On Saturday, July 30, 2016 at 9:40:57 PM UTC-5, James McCoy wrote:
> There's a little remaining work left, but I figured I'd post the current 
> state of things for anyone interested in trying it out (again).
> 
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, .

I'll try it out again; did you manage to fix visual selection? Last time I 
touched the patch, "cimx" worked, but "vimx" did not work (it didn't extend the 
selection backward, only forward). But that said I've been using it ever since 
it was first posted, and have only noticed the visual selection issue.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 'preserveindent' mixing spaces and tabs

[Ben Fritz]

On Tuesday, July 26, 2016 at 12:47:43 AM UTC-5, Rob Foehl wrote:
> On Mon, 25 Jul 2016, Ben Fritz wrote:
> 
> > Makefiles are the only place I can think of where I use 'preserveindent' 
> > and 'copyindent'.
> >
> > This way recipes always have the syntactically required leading TAB indent, 
> > but any spaces used for indent or alignment afterward are maintained when I 
> > add/remove indent or create a new line in the recipe.
> 
> Are you sure?  Try adding indentation across lines with tabs-before-spaces 
> indentation and alignment, with 'listchars' set to some value that'll make 
> the tabs obvious.  I don't think it does what you expect, which is kinda 
> my point here... ;)
> 

Yes, I'm sure. I tested with 'expandtab' set on a makefile with a single tab 
and 4 spaces on a line, with 'shiftwidth' and 'tabstop' both set to 4.

With 'preserveindent' on, the tab character remains where it is when I use >>, 
<<, or visually select and use > or <. Only spaces get added, and only *after* 
the leading tab.

With 'preserveindent' off, the leading tab gets replaced by spaces, breaking 
the makefile.

I almost always have listchars set to see tabs differently from spaces, I only 
turn it off occasionally when I need to for some specific purpose or another.

> Here's an example from Vim's own Makefile...  If I visually select the 
> recipe for this rule and shift it once to the right:
> 
> prepare:
> >---if test -f runtime/doc/uganda.nsis.txt; then \
> >--->---rm runtime/doc/uganda.nsis.txt; fi
> >---for name in $(IN_README_DIR); do \
> >---  cp READMEdir/"$$name" .; \
> >---  done
> 
> I get this result:
> 
> prepare:
> >--->---if test -f runtime/doc/uganda.nsis.txt; then \
> >--->--->---rm runtime/doc/uganda.nsis.txt; fi
> >--->---for name in $(IN_README_DIR); do \
> >---  >-  cp READMEdir/"$$name" .; \
> >---  >-  done
> 
> That odd run of an extra copy of the spaces plus another tab is the 
> problem.  My expectation here would've been for an extra tab to be 
> inserted at the beginning of each line, and nothing more.
> 
> (For reference, this was with ':set lcs=tab:>- ci pi noet ts=8 sw=8 sts=0' 
> in Vim 7.4.1868, as currently packaged in Fedora.  The 'ci' setting 
> doesn't actually matter here, nor does the exact shift method used.)
> 

I'm not sure why spaces get inserted at all in this scenario. That seems 
strange. I see why that would be annoying.

> > Currently >> and << on these lines will keep the leading TAB. If I 
> > understand your proposal correctly, this property could be lost, breaking 
> > the makefile.
> 
> Quite the contrary, modifying only the leading indentation (tabs, in this 
> case) when shifting is exactly the behavior I want.  It's not what we get 
> from 'preserveindent' today, and it's what the 'leftindent' patch intended 
> to accomplish.  It also seems like a reasonable expectation for what 
> 'preserveindent' *should* do, hence the question...
> 

Modifying the leading indentation is only what you want, if you assume the 
leading indentation matches the 'expandtab' setting. I see 'preserveindent' 
(especially when combined with 'copyindent') as explicitly telling Vim "I know 
my indent is weird here, please don't mess with it". I think it deserves a 
separate option if you want to change what part of the indentation Vim is 
allowed to mess with, since leading indent is syntactically important sometimes.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Ben Fritz]

On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
> 
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>   

Don't common plugin managers require you to turn on filetype stuff at a very 
specific location, e.g. *after* loading the plugin manager functionality?

I.e. will this interfere with plugin managers? Or is it enough for them to 
document "filetype off...enableMe()...filetype plugin indent on" in their 
installation instructions?

I guess many Vim distributions already enable filetype stuff in the system 
vimrc, so maybe the installation instructions already account for this.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Ben Fritz]

On Monday, July 25, 2016 at 8:02:21 AM UTC-5, Tony Mechelynck wrote:
> On Mon, Jul 25, 2016 at 11:00 AM,   wrote:
> > Ideally, starting the program as 'vim' would automatically give the user 
> > the improvements promised in the name. And 'vi' would hide all those 
> > improvements.
> >
> > Here is my list of options to set when run as 'vim':
> [...]
> > set hidden
> >
> > Because 'nohidden' is too inflexible and 'hidden' would prevent new users 
> > from using tab pages as file proxies.
> [...]
> 
> I disagree.
> When I :quit a file, or otherwise |abandon| it, I want it to be quit,
> not to remain there in-memory-but-not-saved. I use 'autowriteall' to
> save it _to disk_ if possible, but I don't pretend that everyone will
> want that setting. And if I want my changes to be lost (which happens,
> but rarely) I explicitly use :q! instead of :q when quitting the file.
> 
> If _you_ want to use 'hidden', then set it in your vimrc, but don't
> force every people who don't want it to explicitly ":set nohidden" in
> _their_ vimrc. 

I agree with Tony, 'hidden' is not actually very friendly to new users.

And, I don't see how it's going to prevent anyone from using tab pages as file 
proxies.

If one were to change anything for ease-of-use for new users, it wouldn't be 
'hidden', it would be 'confirm', so that Vim becomes consistent with many other 
programs which don't just refuse to quit when you have unsaved changes, they 
instead ask you whether you want to save first.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ":" in for VimL

[Ben Fritz]

On Friday, July 15, 2016 at 5:12:23 AM UTC-5, LCD 47 wrote:
> Is there any particular reason for not including colons ":" in
>  for VimL?
> 
> The current default makes it impossible to jump to definitions of
> file-scoped functions and variables.  Common ctags implementations
> produce tags like this:
> 
> s:diff_ms autoload/peekaboo.vim   /^function! s:diff_ms(since)$/;"
> f
> s:peekabooautoload/peekaboo.vim   /^let s:peekaboo = 0$/;"v
> 
> But these tag can't be "seen" by Ctrl-t because  doesn't
> include ":".
> 

Probably because Vim supports the ternary operator similar to C/C++, and also 
it's used in substrings and literal dictionary definitions. See :help 
expression-syntax.

There may be other reasons but those are the ones I could think of quickly.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Some window APIs are missing in a new window platform

[Ben Fritz]

On Friday, July 15, 2016 at 2:52:26 AM UTC-5, 覃兆坤 wrote:
> I want to develop a new version vim in a new window platform called Nano 
> Server and prepare to contribute back to the vim. It is published by 
> Microsoft and will used as Azure Host. Compared with full window API, Nano 
> server is missing some of API that vim need. Such as 
> 
> GetNumberOfConsoleMouseButtons 
> 
> GetNearestColor
> 
> GetDlgItemTextA
> 
> 
> 
> And after just a few modify that the vim can run in that platform. My 
> question is how can I modify the source code to let the compiler do not 
> compile the missing API, an example is: 
> 
> if (mch_icon_load((HANDLE *)_hVimIcon) == FAIL || g_hVimIcon == NULL){
>   g_hVimIcon = ExtractIcon(NULL, (LPCSTR)exe_name, 0);
>   }
>   
> 
> The New platform's API only have ExtractIconW (unicode)but not ExtractIconA 
> (Ascii). The compiler give errors even I do not use that API, so what can I 
> modify?

You'd need to define a new preprocessor flag that can be used to skip sections 
of code with a #ifndef or a #ifdef. There are many examples of this in the 
code. Or were you looking for a different sort of advice?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How stable is the new regexp engine?

[Ben Fritz]

On Thursday, July 14, 2016 at 1:44:24 PM UTC-5, Tony Mechelynck wrote:
> When the new regexp engine was introduced, it had so many bugs one
> after the other that I had cold feet about using it and used ":set
> re=1" in my vimrc to "temporarily" disable it. Today I asked myself:
> “Is this still needed?” So I downloaded the ftp README and searched
> it, ":0/^Individual patches/+3,$g/regexp/" with the following result:
> 
>   2176  7.4.008  new regexp engine can't be interrupted
>   2806  7.4.021  NFA regexp: Using \ze may result in wrong end
>   3138  7.4.095  (after 7.4.093) regexp for LuaJIT version doesn't work on BSD
>   3069  7.4.100  NFA regexp doesn't handle backreference correctly
>   2643  7.4.253  crash when using external reference in syntax regexp
>   3604  7.4.289  NFA regexp with repeated backreference does not match
>  32746  7.4.330  using regexp pattern to show a position match can be slow
>   3229  7.4.437  new and old regexp engine are not consistent
> 118187  7.4.497  NFA engine is very slow with some regexp patterns
>   3709  7.4.527  still confusing regexp failure and NFA_TOO_EXPENSIVE
>   4671  7.4.668  can't use a glob pattern as a regexp pattern
>   1953  7.4.685  with illegal utf-8 chars old regexp engine may crash
>   1873  7.4.887  using uninitialized memory for regexp with back reference
>  28965  7.4.1708  new regexp engine does not work properly with EBCDIC
>   6286  7.4.1783  old regexp engine doesn't handle character classes correctly
>   1579  7.4.1785  (after 7.4.1783) regexp test fails on windows
>   5838  7.4.1967  falling back from NFA to old regexp engine has problems
> 
> Problem: No dates. So let's try in a different way, on my hg clone
> this time: "hg --config 'ui.verbose=true' log -f src/regexp_nfa.c"
> (NB: with ui.verbose=false it doesn't show commit messages).
> 
> The two lists are similar but not identical; however they seem to
> indicate that although there have been lulls of more than 6 months
> with no change, the latest one was on 28 June 2016, hardly more than a
> fortnight ago.
> 
> Conclusion: To every user his/her choice. Me, I'll let it cook a few
> more months. Then I'll re-evaluate my policy.
> 
> 
> Best regards,
> Tony.

The latest fix (patch 1967) was not a failing in the new engine, rather a 
failing in the fallback when the new engine is "too expensive". Forcing either 
engine rather than letting Vim choose automatically made the pattern work 
correctly.

The failure in question was a false match of a pattern with a lot of 
backtracking, in a very long line of text. So not even a common case.

Most of the fixes for the engine were completed prior to the release of 7.4. 
Some of the patches you list do not relate at all to the regular expression 
engine; e.g. patches 95, 668. Others are fixes for the OLD engine. Others are 
not "fixes" but rather speed improvements. Even so, compare this overcounted 
list of 17 patches to a similar list from the 7.3 patches, where I filtered 
lines matching "regex\|regular\|engine" to get 79 patches.

So, I don't think your fear of the new engine is all that warranted. I 
certainly wouldn't call it "unstable"; if I did I would basically need to call 
all of Vim's source "unstable". I avoided the new engine for several months as 
well, while it was first being developed near the end of 7.3. But I've been 
using it since around the time 7.4 came out and have only seen a handful of 
problems in weird cases, all of which have been fixed so far.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make maximum integer size accessible in vimscript?

[Ben Fritz]

On Wednesday, July 13, 2016 at 7:12:30 AM UTC-5, Ken Takata wrote:
> Hi Ben,
> 
> 2016/7/13 Wed 5:44:06 UTC+9 Ben Fritz wrote:
> > The recent updates to Vim to support 64-bit integers broke a plugin I was 
> > using that provides a vimscript implementation of a pseudorandom number 
> > generator, by sending it into a near-infinite loop.
> > 
> > The problem was that the plugin assumes 32-bit integers, so I "fixed" it 
> > with a bitwise and() in the internal logic with a 32-bit integer max value.
> > 
> > But I'd rather just update to use 64-bit integers.
> > 
> > I could hard-code maximums based on has(num64), but would it be useful in 
> > general to just make a v:max_number or something which would contain the 
> > maximum value for a Number variable? I'd rather use something built-in than 
> > hard-code it anywhere it's needed.
> 
> I wrote a patch for this:
> https://bitbucket.org/k_takata/vim-ktakata-mq/src/201d986bfabca7b759b7cbb9a4703e9996b8fc43/v_max_number.patch?fileviewer=file-view-default
> 
> BTW, the result of `1/0` cannot be used for this?
> 

I suppose "1/0" does return the maximum integer value. That's actually quite 
surprising, I would have expected an exception to be thrown in that case rather 
than a value of any kind. I suppose it's documented under :help expr-/ but even 
so it *feels* wrong. I may use it anyway :-\

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] ib and ab motions are not able to detect parentheses (#915)

[Ben Fritz]

On Tuesday, July 12, 2016 at 12:34:43 PM UTC-5, Henrik Giesel wrote:
> Given: I open vim -u NONE a.c
> 
> When: I type ifoo('bar','(','(');F,vib
> 
> Then I expect: have ('bar','(','(') selected
> 
> What actually happens: Nothing is selected
> 
> 
> I always thought this was weird. Why are those stray parentheses algorithm of 
> finding braces this much? 
> 
> 
> When I have some colors installed in vim, it is able to detect any kind of 
> strings. And given Vim can detect if any given character is part of a string 
> or not, it should also be smart enough to know, that it shouldn't match those 
> with the % or * operators, or any of  theib, ab family.
> 
> 
> 

I confirm, this looks like a bug. From the help, I would expect ib and ab to 
select an area defined by the [( and ]) motions. But [( and ]) at the same 
cursor location jump to the expected text. These motions additionally respect 
the cpo-% flag (or lack thereof).

Furthermore, if you put a linebreak after that last comma, the text object 
selects the expected text. It looks like only the special case where the 
opening and closing parenthesis are on the same line is broken.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using file name with quickfix commands

[Ben Fritz]

> > 
> > Before setting any quickfix list it takes 0.22s. After setting a
> > quickfix list with 8 entries it takes 6.5 seconds, which is
> > actually worse than how it was before the last patches (it took then
> > 3.56s).
> 
> Strange.  Oh, perhaps it's because this "mybuf" is near the start of the
> buffer list?  I reversed the search order, thinking that there is a
> higher chance of searching for a newer buffer.
> 
> You can try changing buflist_findname_stat() from:
> 
> for (buf = lastbuf; buf != NULL; buf = buf->b_prev)
> 
> To:
> 
> for (buf = firstbuf; buf != NULL; buf = buf->b_next)
> 

Is it worth the effort to try using a data structure with faster lookup times 
than a linear search of a linked list?

I imagine 80,000 buffers is not a very common case but just using a BST of some 
kind could probably improve that performance immensely, and probably won't hurt 
the more common cases noticeably. I assume there is a unique ID (like the 
buffer number?) we could use for the key.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using file name with quickfix commands

[Ben Fritz]

On Thursday, July 7, 2016 at 2:24:49 PM UTC-5, Bram Moolenaar wrote:
> - Changing directory can make the file name invalid.  We could store the
>   full path, but creating that also adds overhead.  Hmm, perhaps we
>   could store the full path the moment the directory is changed.
> 

Remember that autochdir can cause many frequent directory changes, especially 
for quickfix! So it will definitely need some sort of attention.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: generate portable version cannot addon plugin(buffer var)

[Ben Fritz]

On Tuesday, July 5, 2016 at 12:26:32 PM UTC-5, Yang Luo wrote:
> 1. I installed gVim7.4 in win7_x64, and add on some plugins, it uses good. 
> Now I want to change it to a portable version. I copied the Vim folder to 
> another folder and name it gVim74, I uninstalled Vim. The common edit is good 
> of the portable version, but the plugins not fully added. 
> There is a plugin(plugina.vim), it defined variable "b:plugina_var", when I 
> run the plugin, can not find b:plugina_var. I have source the plugina.vim in 
> _vimrc, and I already put it into vim74/plugin. I source plugina.vim manually 
> again, it works OK.
> So why the buffer variable b:plugina_var cannot define in portable version? 
> Is there some environment variables that I need notice when produce a 
> portable version of vim?

Check $VIM and $VIMRUNTIME. See :help $VIMRUNTIME.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: File format issues when using gpg

[Ben Fritz]

On Thursday, June 9, 2016 at 1:53:05 AM UTC-5, cryptoz wrote:
> 
> The script I put in _vimrc to open *.gpg,*.asc files is similar to what I
> got from http://vim.wikia.com/wiki/Encryption
> 
> I understand correctly, the steps are:
> 
> 1. set bin option before read the file.
> 2. read the file into buffer.
> 3. call gpg to decrypt the buffer. 
> 4. set nobin option.
> 

Off-topic, but it's also important to:

* turn off saving registers in the .viminfo file
* turn off the swap file
* turn off the undo file

...and maybe some other options. Otherwise you could leak unencrypted data out 
to the filesystem.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.1849

[Ben Fritz]

On Thursday, May 26, 2016 at 3:10:17 PM UTC-5, Bram Moolenaar wrote:
> Patch 7.4.1848
> Problem:Can't build with Strawberry Perl 5.24.
> Solution:   Define S_SvREFCNT_dec() if needed. (Damien, Ken Takata)
> Files:  src/if_perl.xs
> 

This patch breaks compatibility with old versions of Perl.

I build my own Vim on an old Solaris server at work, which has Perl 5.6.1. I'm 
not interested in compiling my own Perl. With this patch included, I get an 
error during compile or link about not finding SvREFCNT_inc_void_NN. If I 
revert the patch (so that I have "Included patches: 1-1847, 1849-1862"), Vim 
builds and runs fine.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [bug] Syntax file for markdown uses semi-absolute path

[Ben Fritz]

On Wednesday, May 25, 2016 at 2:24:01 PM UTC-5, Axel Bender wrote:
> @ZyX
> 
> The layout of my files is as follows:
> 
> Z:\bin\vim\syntax\html.vim
> Z:\bin\vim\syntax\markdown.vim
> 
> Still, I get the following error message when editing a MD file:
> 
> "readme.md" [unix] 136L, 5524C
> Error detected while processing z:\bin\vim\syntax\html.vim:
> line  209:
> E409: Unknown group name: 
> css.*Attr,css.*Prop,cssComment,cssLength,cssColor,cssURL,cssImportant,cssError,cssString,@htmlPreproc
> E475: Invalid argument: htmlCssDefinition matchgroup=htmlArg start='style="' 
> keepend matchgroup=htmlString end='"' 
> contains=css.*Attr,css.*Prop,cssComment,cssLength,cssColor,cssURL,cssImportant,cssError,cssString,@htmlPreproc
> "readme.md" line 37 of 136 --27%-- col 1
> 
> 
> Making said change in markdown.vim has the error disappear.

Making your suggested change in markdown.vim, would force the html ftplugin 
file, and the html indent file, potentially an html colorscheme, various 
"after" files, etc. to also get sourced.

That is NOT what you want.

I'd guess there is a problem with your runtimepath setting. Z:\bin\vim is 
certainly not in the default runtimepath, so you're doing something wrong.

Perhaps it's time to check out the new packages feature, you may find it easier 
to use.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: move tabs using mouse in gvim

[Ben Fritz]

On Thursday, May 5, 2016 at 6:17:08 AM UTC-5, kamaraju kusumanchi wrote:
> A while ago I asked about moving tabs in gvim using mouse (
> https://groups.google.com/forum/#!topic/vim_use/CfwgkVRm1jY ). In that
> thread Ken Takata mentioned that there is a patch available to do
> this.
> 
> I am wondering what is the current status of this patch? Is it
> integrated into gvim code base or is there a plan to do so in the
> future?
> 
> I ask because I do not see any pull request for this in the official github
> https://github.com/vim/vim/pulls . So may be it is integrated already?
> 

Nope, it's still in the todo list. You probably won't ever see a pull request 
for it since Bram has a patch instead.

The good news is, it still applies cleanly, if you're willing to compile your 
own Vim.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to detect i_CTRL-X submode in Vimscript?

[Ben Fritz]

On Wednesday, April 20, 2016 at 9:24:18 AM UTC-5, b...@airbladesoftware.com 
wrote:
> I've just realised I wrote CursorMovedI when I meant CursorHoldI.  Sorry 
> about that.
> 
> > Would it be sufficient to not trigger CursorMovedI when the user pressed
> > CTRL-X ?  What submode would it be in?  Or are you saying that this
> > depends on whether the completion uses a popup menu or not?
> 
> Yes, I imagine not triggering CursorHoldI when the user presses CTRL-X would 
> suffice.
> 
> Here's a demonstration of the problem:
> 
> 1. Start vim with:
> 
> vim -u NONE --cmd 'set updatetime=1000' --cmd 'set showmode' --cmd 'autocmd 
> CursorHoldI * 1'
> 
> 2. Type "i" to enter insert mode.
> 
> 3. Type CTRL-x to enter the insertion completion submode.
> 
> 4. Expected: vim stays in insertion completion submode.  Actual: after 1 
> second the mode changes back to insert mode.
> 
> The motivation for fixing this is when the user has a small updatetime of, 
> say, 100ms, they have to be very quick typists to be able to bring up the 
> insert completion popup before the CursorHoldI autocommand boots them out of 
> insertion completion mode.

I don't like the idea of not firing CursorHoldI in this mode. Users expect 
their CursorHold/CursorHoldI autocmds to fire when they pause for a bit. I've 
deliberately stopped typing before to allow this to happen (for example to 
update the current highlighted function in tagbar).

Why would a very short updatetime be useful? It seems like the better solution 
is "don't do that", unless there's a good reason for it.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFE: support POSIX standard and developing RE's

[Ben Fritz]

On Thursday, March 24, 2016 at 5:27:35 AM UTC-5, L. A. Walsh wrote:
> Posix, has 2 official RE's  already, the modern REs( like in
> grep -E, (extended RE's)
> and "obsolete RE's" as found in ed, called "basic REs".
> 
> Additionally for the past few years, more gnu utils (like grep -P)
> have started supporting a third type of RE's called
> PCRE [Perl Compatible RE's] that seem to be on their way
> to becoming a 3rd official type of RE.
> 
> Would it be possible to add the 3 RE's (w/appropriate flags)
> to invoke those standardized expressions (not as a replacement
> for any of the existing RE's), but w/different flags.
> 
> This would allow those who know the posix-compat RE's that
> are becoming more wide spread in usage, and would allow for
> easier, direct usage (cut) of the alternate RE's specifically
> to make it easer to define these expressions in shell-vars and/or
> vim-macros to allow for easier portability and usability between
> vim and other posix & gnu utils?  Note in the past few years,
> the pcreRE's have also added python-specific features to the
> syntax to allow for easier porting of python features.
> 
> Probably (or maybe) best of all, as all of these RE's are
> becoming more prevalent in posix, unix and linux environments,
> it would be a great benefit for people to be able to switch
> to alternate RE's based on familiarity and and the greater
> uniformity in these classes.
> 
> Seems this would lower the learning curve for RE usage in
> vim where it often, idiosyncratically differs from such,
> requiring much trial and error and wasted time to get
> equivalent vim-compat-RE's that are equivalent to other
> industry standard RE's.
> 
> Anyway, thought I'd mention this, since vim already has
> multiple incompatible RE's with existing standards and
> thought that providing a few "new POSIX-compat RE's" would
> only help in making vim easier to use.
> 
> Thanks for your time!
> -linda
> 
> 
> Of course,

I wonder if a different approach might help.

Vim already has :perldo, :pydo, etc. Perhaps a :perlmatch, :pymatch, etc. could 
be added for basic searching in those languages?

There is also a patch in the todo list for :bvimgrep. Maybe a :bgrep command 
could also be added. I think that would allow searching the current buffer 
using whatever tool you like.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] vim8 dvorak (#756)

[Ben Fritz]

On Wednesday, April 13, 2016 at 9:53:32 PM UTC-5, Tim Gregg wrote:
> could you please incorporate a setting in the new version of vim so it makes 
> more sense for us dvorakers to use it?
> 
> 

Well, there's a script to do some mappings for you. Previously it was in 
$VIMRUNTIME/macros/dvorak, it's been moved to a package for the next release.

But personally I don't use it and don't have any problems with Vim in Dvorak. I 
likewise don't use any language mappings for the same purpose: 
http://vim.wikia.com/wiki/Using_Vim_with_the_Dvorak_keyboard_layout

What's giving you trouble? Just muscle-memory from using Vim before learning 
Dvorak? Either of those solutions should help with that if you don't want to 
retrain on Vim. I had the advantage of learning Dvorak before I learned Vim.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim 7.5 or Vim 8?

[Ben Fritz]

On Tuesday, April 5, 2016 at 2:28:34 AM UTC-5, Dominique Pelle wrote:
> Bram Moolenaar  wrote:
> 
> > I have been wondering if the next release should be called 7.5 or 8.
> > We have quite a few new features, but not that many as with the Vim 7
> > release.  Well, that was a big release.  I think the most important
> > addition since then is persistent undo in 7.3.  Now we have more new
> > features than in 7.3 or 7.4.  7.1 and 7.2 were mostly bug fixes.
> 
> 8.0 or 7.5 is a bit arbitrary without conventions such as:
> - major version number increased when breaking backward
>compatibility (which should be rare)
> - middle version number increased when adding new features
> - minor version increased for bug fixes
> 

I actually think 8.0 makes sense, due entirely to expected plugins that will 
require the new features.

Considering any plugins that start to require the new packages feature, 
IO/jobs/channels features, etc. may not work AT ALL in older Vims (instead of 
just degraded performance) I think it makes sense to let them say "requires Vim 
8.0 and up".

Although Vim kept backwards compatibility, it introduced a bunch of features 
that will be hard to embrace fully in plugins and yet remain backwards 
compatible with older Vims.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: "syntax reset" in colorschemes

[Ben Fritz]

On Wednesday, March 30, 2016 at 9:58:29 PM UTC-5, James McCoy wrote:
> There seems to be a snippet that's been cargo-culted into colorschemes,
> but I can't find justification for.
> 
> if exists('syntax_on')
>   syntax reset
> endif
> 
> Given that syntax items just link to highlight groups and it's the
> highlight groups which define the colors, why should a colorscheme be
> calling ":syntax reset"?
> 
> The reason I noticed this is that there's actually a noticeable impact
> of resetting the syntax now.  If there was before, I never encountered
> it.
> 
> If a syntax file is using ":syn iskeyword", then this is cleared when a
> user changes their colorscheme, breaking the highlighting that was in
> effect.  This can trivially be seen with the sh syntax.
> 
> --8<--
> #!/bin/sh
> apply_patch make-some-case-work
> 
> if true; then
> echo Something
> fi
> -->8--
> 
> Given the above foo.sh, everything looks appropriately highlighted when
> initially opened.  Set the colorscheme again (even just back to what it
> is -- :exe 'color '.g:colors_name) and now the fi is highlighted as an
> error while most of the rest has lost its highlighting.
> 
> So, is this just a relic of the original implementation or is there
> an actual reason that this snippet needs to be put into colorschemes?
> If it's legitimate, shouldn't it be done by Vim instead of cargo-culted
> into every colorscheme?
> 

I've seen colorschemes reach into specific syntaxes and highlight individual 
groups, overriding the links. I'd guess the syn reset command is to recover 
from that when switching to a new scheme. See for example, solarized.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Ben Fritz]

On Wednesday, March 23, 2016 at 6:21:21 PM UTC-5, Manuel Ortega wrote:
> > That reminds me of something else. Why isn't 'modified' set when you change 
> >cryptmethod or the encryption password?
> 
> 
> 
> 
> 
> Isn't it because the *buffer* hasn't changed?  IIUC, in the latter case the 
> *file* changes, not the buffer.  In the former case neither has changed, so 
> for sure 'modified' should not be set.
> 
> 

If you change any of 'fileformat', 'fileencoding', 'bomb', or 'nofixeol' then 
the buffer doesn't change either, only the file. 'cryptmethod' is the oddball 
here.

I view the 'modified' flag as saying "if you save this buffer then the file 
will change".

I got caught once while I was testing something where I had the wrong password 
because I had quit Vim after changing the password, but I hadn't saved yet. Vim 
let me do that without any complaint, because the buffer wasn't modified.

This might be a decent use for an OptionSet autocmd event, but that seems like 
a hack.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Arrow characters shouldn't be wide

[Ben Fritz]

On Monday, March 21, 2016 at 11:52:38 AM UTC-5, Manuel Ortega wrote:
> 
> At least some of these worries can be fixed by setting "noemoji", but I find 
> it inexplicable that "emoji" is ON by default, given how it messes up 
> operating with non-emoji characters.
> 
> 
> Either Vim needs to only apply "emoji" to emoji, or it needs to not make 
> "emoji" on by default.
> 
> 

OK, well I can agree with all of that as well. So maybe my complaint is not 
without merit. But at least I can fix my immediate problem. So thanks for 
making it an option! Maybe it can be improved as suggested?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Arrow characters shouldn't be wide

[Ben Fritz]

On Monday, March 21, 2016 at 11:40:14 AM UTC-5, Ben Fritz wrote:
> On Monday, March 21, 2016 at 11:29:20 AM UTC-5, Ben Fritz wrote:
> > A recent patch (since 1507; I assume it was 1604) broke my preferred 
> > "showbreak" setting for text files.
> > 
> 
> 
> More problems. I also have a plugin (signify) which places characters of my 
> choosing in the sign column for text which differs from the version checked 
> into source control. Some of the characters I've used for that are also now 
> double-width. Admittedly some look much better in double-width but since this 
> worked before, it's a little frustrating. Especially because, many of these 
> characters still only take a single cell for the glyph itself, so the extra 
> empty cell seems pointless.

Oh dear. I am very sorry, this is all resolved by putting this in my .vimrc:

   set noemo

Which is actually quite satisfying by itself.

Next time I promise I'll read the docs before complaining.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Arrow characters shouldn't be wide

[Ben Fritz]

On Monday, March 21, 2016 at 11:29:20 AM UTC-5, Ben Fritz wrote:
> A recent patch (since 1507; I assume it was 1604) broke my preferred 
> "showbreak" setting for text files.
> 


More problems. I also have a plugin (signify) which places characters of my 
choosing in the sign column for text which differs from the version checked 
into source control. Some of the characters I've used for that are also now 
double-width. Admittedly some look much better in double-width but since this 
worked before, it's a little frustrating. Especially because, many of these 
characters still only take a single cell for the glyph itself, so the extra 
empty cell seems pointless.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Arrow characters shouldn't be wide

[Ben Fritz]

A recent patch (since 1507; I assume it was 1604) broke my preferred 
"showbreak" setting for text files.

I have been setting showbreak to ↖ (U+2196 NORTH WEST ARROW). The glyph for 
this character still only occupies a single cell on my gvim, however it is 
treated as a wide character so it uses two screen cells (the second one is 
empty) and is not allowed in the 'showbreak' option.

As far as I can tell most of the other arrow characters are still a single cell 
only, but the (NORTH|SOUTH) (EAST|WEST) ARROW characters are treated as double 
width. (RIGHT|LEFT)WARDS ARROW only take a single cell, so growing to take two 
cells when you rotate 45 degrees seems strange.

Also double-width now are (LEFT|RIGHT)WARDS ARROW WITH HOOK, even though the 
very similar DOWNWARDS ARROW WITH (TIP|CORNER) (LEFT|RIGHT)WARDS characters are 
still single width.

Any of these can obviously fit in a single cell in gvim at least. Do they cause 
problems elsewhere?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.