Re: [vim/vim] Update style guides and add formatter (PR #15789)
On 2024-10-08, Christian Brabandt wrote: > I tend to be sympathetic to those changes and getting rid of tabs is a good > change in my opinion (although we lose some alignments). I leave this open for > a few days, but will probably merge it, unless other maintainers strongly > disagree. I don't see any reason that we should lose alignments. Unlike a previous commenter, I would never trade off readability for an automatic formatter, nor would I use a formatter without checking what it just formatted for readability and consistency with the style used in that file. Regards, Gary -- -- 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/20241009185001.GJ15474%40phoenix.
Re: [vim/vim] Fix style and typo in documents (PR #15801)
On 2024-10-04, zeertzjq wrote: > @zeertzjq commented on this pull request. > > --- > > In runtime/doc/starting.txt: > > > @@ -972,9 +973,9 @@ accordingly. Vim proceeds in this order: > The |v:vim_did_enter| variable is set to 1. > The |VimEnter| autocommands are executed. > > -The $MYVIMRC or $MYGVIMRC file will be set to the first found vimrc and/or > -gvimrc file while $MYVIMDIR is set to the users personal runtime directory > -'rtp' (typically the first entry in 'runtimepath'). > +The $MYVIMRC or $MYGVIMRC environment variable will be set to the first found > > ⬇️ Suggested change > > -The $MYVIMRC or $MYGVIMRC environment variable will be set to the first found > +The $MYVIMRC or $MYGVIMRC environment variables will be set to the first > found If the statement is about the $MYVIMRC and $MYGVIMRC environment variables and not to only one of them, then the change should be: -The $MYVIMRC or $MYGVIMRC environment variable will be set to the first found +The $MYVIMRC and $MYGVIMRC environment variables will be set to the first found Regards, Gary -- -- 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/20241004233639.GI15474%40phoenix.
Re: [vim/vim] ignorecase gets set globally when editing ada file (Issue #15772)
On 2024-10-03, Martin Krischik wrote: > BTW it seems your current version has the same problem (setting > ignorecase, > which should be a user setting) > > But Ada is an ignore case language so that would be annoying for ada > programmer. It would be helpful, especially for those who use multiple > languages, if it was possible to set the ignore case depending on language. How about using BufEnter and BufLeave autocommands to control 'ignorecase'? BufEnter would check the 'filetype' and if "ada", then save the current value of 'ignorecase' and set 'ignorecase'. BufLeave would check the 'filetype' and if "ada", then restore the saved value of 'ignorecase'. Regards, Gary -- -- 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/20241003211702.GH15474%40phoenix.
Re: [vim/vim] In .vimrc, how to tell if gvim is under git 3way merge or not? (Discussion #15785)
On 2024-10-02, flyingosprey wrote:
> On Windows, I ran
>
> git config --global --replace-all merge.tool gvimdiff
> git config --global --replace-all mergetool.gvimdiff.path "C:/Program
> Files/Vim
> /vim90/gvim.exe"
> git config --global --replace-all mergetool.gvimdiff.trustExitCode false
> git config --global --replace-all merge.conflictstyle diff3
>
> to set gvim as git mergetool.
>
> I want to set a different color when git merge. I found
>
> if &diff
> colorscheme codedark
> endif
>
> does not work because when git merge starts, &diff is 0.
>
> Questions: In .vimrc, how to tell if gvim is under git 3way merge or not?
>
> Thanks for your suggestion.
The only way I use git on Windows is from Cygwin or from Git for
Windows, so these comments apply to those environments.
I'm surprised that "if &diff" doesn't work. In my ~/.gitconfig, the
vimdiff mergetool is this:
cmd = "vim -d -c '4wincmd w | wincmd J | wincmd =' $LOCAL $BASE $REMOTE
$MERGED"
The -d option sets &diff before .vimrc is sourced.
A few ideas come to mind:
1. After git opens gvim, execute
:echo $GIT
to complete all the environment variables in gvim's environment
that begin with "GIT".
Alternatively, shell out, then look for those variable from the
shell, e.g.,
:sh
$ env | grep GIT
See if any of those variable names or values are unique to the
merge command. If some are, then test their existence and/or
values in your .vimrc.
2. Wait to test the value of &diff until gvim is finished opening
files, e.g.,
autocmd VimEnter if &diff | colorscheme codedark | endif
That has the problem that it will set your colorscheme for any
vimdiff command.
3. Expand the VimEnter autocommand above to either count the number
of windows (winnr("$")) and check that the number is 4, or
traverse the open windows and check that &diff is set in all of
them.
4. Examine the v:argv variable and look for a pattern in the
arguments that might be unique to the git merge command.
HTH,
Gary
--
--
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/20241003205529.GG15474%40phoenix.
Re: [vim/vim] Vim file-save strategy breaks file-watching applications (Issue #15733)
You both make good arguments. This may be worth an exception after all. Regards, Gary -- -- 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/20240925051545.GF15474%40phoenix.
Re: [vim/vim] Vim file-save strategy breaks file-watching applications (Issue #15733)
On 2024-09-24, Nir Lichtman wrote: > Very interesting, I actually noticed this behavior a couple of days ago and I > wasn't sure why it specifically occurred with Vim, but this clears it up. > > Opened a PR to address this issue by changing the default value of bkc: #15739 If you are aware of 'bkc', then you know what the options are. In any case, you most definitely do not want to change the default value. There are countless users who depend on Vim to work consistently, and there are few things as frustrating as a tool that you suddenly notice is working differently without knowing why or when it changed. I love that I can depend on Vim to work the same after an update as before. Regards, Gary -- -- 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/20240925041114.GE15474%40phoenix.
Re: [vim/vim] Implement lstat() for Windows (PR #15014)
On 2024-06-17, Christian Brabandt wrote: > If that is the case, I am fine with skipping. But I don't know how to detect > that Vim is running in a Mingw/Msys environment. My MINGW64 installation has a couple of environment variables that you could test. MSYSTEM=MINGW64 OSTYPE=msys Regards, Gary -- -- 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/20240617193709.GB15474%40phoenix.
Re: Calls to ch_log() left in released code
On 2024-06-02, Christian Brabandt wrote: > On Sa, 01 Jun 2024, Gary Johnson wrote: > > > I would like to request that developers not leave calls to ch_log() > > enabled in released code, that is, in code that has been committed > > to the GitHub repo. > > > > I just tried debugging some Vim code by sprinkling calls to ch_log() > > in it. When I ran tail on the log file, I was inundated with log > > messages from other sources, making it hard to find mine. To quiet > > the log, I put #if 0/#endif around several calls in > > > > channel.c > > evalfunc.c > > main.c > > ops.c > > os_unix.c > > ui.c > > > > It would be nice if the responsible developers would fix those in > > the manner they prefer, since the project doesn't seem to have > > a uniform solution for this, such as the one used in term.c. > > > > Perhaps a note about not leaving calls to ch_log() enabled when > > you're done debugging should be added to src/README.md. > > I thought the idea was that you can use `--log file` and have a log with > all kind of information that can be used even with released versions of > Vim. So I have used it e.g. to debug what keys are received by Vim when > a user complains certain keys don't work in alacritty or kitty terminal. > > If we disable the calls to ch_log() we wouldn't be able to debug those, > no? True, but the log can become so noisy as to be useless for debugging any other problem. It seems we have two conflicting needs. What I've seen on other projects is for there to be groups of debug print statements, with each group assigned one of 32 bits. These were enabled at compile time for debugging in the lab rather than in the field, but it could be done at run time, either as a command-line argument or a function call. Such groups could be given names instead of bits to make the UI friendlier and more extensible. Another, simpler approach would be to add a global, compile-time macro that would be enabled for releases, but could be disabled by a developer to quiet all those terminal-related calls to ch_log(). That would allow a developer wanting to use ch_log() for their own purposes to simply add something like -DNOTERMDEBUG or -UTERMDEBUG to the CFLAGS in their environment. Regards, Gary -- -- 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/20240602190531.GC31154%40phoenix.
Calls to ch_log() left in released code
I would like to request that developers not leave calls to ch_log() enabled in released code, that is, in code that has been committed to the GitHub repo. I just tried debugging some Vim code by sprinkling calls to ch_log() in it. When I ran tail on the log file, I was inundated with log messages from other sources, making it hard to find mine. To quiet the log, I put #if 0/#endif around several calls in channel.c evalfunc.c main.c ops.c os_unix.c ui.c It would be nice if the responsible developers would fix those in the manner they prefer, since the project doesn't seem to have a uniform solution for this, such as the one used in term.c. Perhaps a note about not leaving calls to ch_log() enabled when you're done debugging should be added to src/README.md. Regards, Gary -- -- 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/20240602021159.GB31154%40phoenix.
Re: Forwarding of Issues and PRs from GitHub to the vim_dev List
On 2024-05-30, Christian Brabandt wrote: > On Di, 28 Mai 2024, Gary Johnson wrote: > > > I follow Vim development activity through the vim_dev mailing list > > rather than at https://github.com/vim/vim/. That generally works > > well, except that I seem to miss the original postings of some > > issues and/or PRs. I see responses, but not the original postings, > > so I'm potentially missing postings that no one responds to. > > > > A recent example is Christian's PR #14862. I saw only Ben's comment > > (and now mine) in the list. > > > > Is the connection from GitHub to the list broken, or do I have > > something misconfigured? > > There either seems to be some rate-limiting done by Google Groups or > those messages got blocked by Google for other reasons (like they > trigger some spam or other fraud detection). There is nothing I can do > to fix this unfortunately if I don't know what is the reason for this. > > I think the easiest way to follow Vim Development from Github is, if you > got to the Vim Repository page on Github https://github.com/vim/vim and > you click on the little watch button. Then you receive notifications for > all PRs, Issues and activities there in. Of course this requires to have > a github account. I have a GitHub account, but the email address associated with it is my personal/social/household email account which I read with a web mail client. The traffic to it from GitHut is pretty low. For the vim_dev list and all other technical email lists, I use a different account which I regularly fetch and read using a procmail-like filter and mutt. I haven't figured out how to change the email address that my GitHub account uses for notifications without messing up who-knows-what-else associated with that account. I suppose I could create a new account with my technical email address just for notifications. Regards, Gary -- -- 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/20240530140944.GA31154%40phoenix.
Re: [vim/vim] Why vim search exclude the letter in current cursor? (Discussion #14871)
On 2024-05-29, ElwinGao wrote: > when I search text like this: > > 1. www.github.com > 2. www.google.com > > --- > > current cursor(cursor type is block) on the first "w" in first line，and then I > using "/" to search target words: "www" > when I type "enter" to search，the cursor jump to the first "w" in second line > I think vim will scan word from current letter(not jump to next "www"), but > vim > will search word exclude current letter > I don't understand why design like this? If Vim included the current location in the search and stopped at the first "w" of the "www" in the first line, typing "n" to find the next match would find that same match at the same location and the search would never progress. Regards, Gary -- -- 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/20240529154523.GJ24132%40phoenix.
Forwarding of Issues and PRs from GitHub to the vim_dev List
I follow Vim development activity through the vim_dev mailing list rather than at https://github.com/vim/vim/. That generally works well, except that I seem to miss the original postings of some issues and/or PRs. I see responses, but not the original postings, so I'm potentially missing postings that no one responds to. A recent example is Christian's PR #14862. I saw only Ben's comment (and now mine) in the list. Is the connection from GitHub to the list broken, or do I have something misconfigured? Regards, Gary -- -- 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/20240528190317.GI24132%40phoenix.
Re: [vim/vim] Please consider switching to the XDG runtime when no vimrc exists but ~/.config/vim does (Issue #14766)
On 2024-05-13, Diego Viola wrote: > Please consider doing a runtime switch to the XDG one when a ~/.config/vim > directory exists. > > Currently the runtime switch happens when ~/.config/vim/vimrc exists, and > that's fine. > > However, while testing #14757 yesterday, I ran into some issues when I dropped > the syntax files in ~/.config/vim/syntax, I didn't have a vimrc anywhere and > somehow expected it to work. > > A fix for that was simple, just create a minimal ~/.config/vim/vimrc with > syntax on and that was it. > > I think it would be a lot better if Vim also checked for the presence of ~ > /.config/vim and enabled the XDG runtime in those cases. > > I think this is how ~/.vim currently works anyway, you don't have to have a > vimrc in ~/.vim and your syntax files will be sourced regardless. > > There may also be a chance that I misunderstood something, if so please let me > know and feel free to close this issue. I may be missing something, too, but I think you're right. I didn't think about that enough during the PR review. The location of the user's vim directory should be determined by searching that prioritized list of places and selecting the first one that is actually a directory or a link to a directory. The location of the user's vimrc should be determined separately. It should be $HOME/.vimrc if it exists, else vimrc under the directory found above. Regards, Gary -- -- 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/20240513180549.GH24132%40phoenix.
Re: [vim/vim] Setting 'showbreak' affects the reported virtual column number in the status line. (Issue #14759)
On 2024-05-12, lkintact wrote: > Steps to reproduce > > 1. Run gvim.exe --clean. > 2. Execute :set showbreak=>. > 3. Execute :set laststatus=2 to enable the status line. > 4. Execute :set statusline=%v. > 5. Type 1000ia to put 1000 letters "a" in the buffer. Note that the > status line reports "1012". > > Expected behaviour > > The status line should report "1000". > > Version of Vim > > 9.1.296. > > Environment > > OS: Windows 10 Home. > Terminal: GUI. The number 1012 is correct. The statement closest to a definition of "virtual column" I could find in Vim's help is in ":help wincol()": The result is a Number, which is the virtual column of the cursor in the window. This is counting screen cells from the left side of the window. The leftmost column is one. A 1000-character line displayed in an 80-column window will wrap 12 times. Each time it wraps, Vim inserts the single-character 'showbreak' string, increasing the number of virtual columns occupied by the text by one each time. This is most easily seen at the end of the first screen line, column 80. With the cursor at column 80, the status line shows "80". Type l to move the cursor one character position to the right. The status line now shows "82". The cursor has moved to character position 81 but to virtual column 82 because that count includes the ">" at the left edge of the screen. HTH, Gary -- -- 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/20240512162443.GG24132%40phoenix.
'breakindent' seems to break gqap
When 'breakindent' is set and the window width is less than 'textwidth', the gqap command reformats indented paragraphs to less than 'textwidth'. Steps to reproduce 1. Create a file containing a single paragraph of arbitrary text, indented by one 8-space tab stop and formatted for a textwidth of 78. The text below, indented by a tab stop, will do. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam luctus lectus sodales, dictum augue vel, molestie augue. Duis sit amet rhoncus justo. Nullam posuere risus semper magna commodo scelerisque. Duis et venenatis sem. In rhoncus augue sed tempor mattis. Mauris id aliquet odio. 2. Open that file in vim in an 80-column terminal with this command (on one line): $ vim -N -u NONE -i NONE --cmd 'set ai tw=78 breakindent' -c vnew -c 'wincmd w' lorem_ipsum.txt 3. Execute gqap Ctrl-W | 4. Note that the paragraph has been reformatted so that the longest line is 70 columns. (This new text width varies with the window width in ways I haven't investigated.) Expected behavior The paragraph should be formatted for a text width of 'textwidth', regardless of the setting of 'breakindent' or the window width. It works as expected with 'breakindent' off. Version of Vim 9.1.366 8.2.2121 Environment Operating system: Ubuntu 22.04 Terminal: XTerm(389) Value of $TERM:xterm-256color Shell: bash 5.1.16(1)-release Regards, Gary -- -- 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/20240424181024.GD24132%40phoenix.
Re: [vim/vim] Documentation of CTRL-D/CTRL-U is no longer accurate (Issue #14338)
On 2024-04-02, Christian Brabandt wrote: > In any case, things are a bit in flow currently and we are not close to a > release. So some potential fallout can be expected. I try not to break > backwards compatibility intentionally, but of course I'd like Vim to be > improved and fixed. Yes it might be slightly differently from how Bram used to > work, but I need to make some compromises. I don't know all of the code as > good > as Bram and cannot test each change thoroughly and I have to trust > contributors > (which I think are also making a good job). Otherwise, the list of issues and > PRs just flows over and I will never get a chance to get those numbers down. Christian, You have been doing a fantastic job. I appreciate your hard work and your dedication to keeping that balance between backwards compatibility and improvement. Thank you. Thanks also to the others who have jumped in and helped to keep Vim thriving. Regards, Gary -- -- 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/20240402224626.GC24132%40phoenix.
Re: [vim/vim] Documentation of CTRL-D/CTRL-U is no longer accurate (Issue #14338)
On 2024-03-29, luukvbaal wrote: > I can try, but are we making a decision solely for backward compatibility? Or > can we consider which of the two old behaviors makes more sense for scrolling > the viewport. Either the cursor position stays the same and only starts moving > to be at the top/botline(CTRL-E/Y/F/B), or the cursor moves the same amount of > lines as the viewport did(CTRL-D/U). I don't know what the original developer was thinking, but I imagine the difference was deliberate. They're both useful. Which behavior makes more sense to you may not be what makes more sense to someone else. Unless there is a problem with the old behavior, other than the inconvenience of maintaining it, I think it should be restored. Regards, Gary -- -- 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/20240329184246.GB24132%40phoenix.
Re: [vim/vim] Minor bug: Does not append new line (Issue #14181)
On 2024-03-17, San wrote: > @chrisbra > Also i found another bug( or maybe its on purpose) > When you only have /t( tab or indentation) without any text on a new line. And > you navigate back to previous line and press delete button, the next line does > not get deleted but the /t( tab or indentation) does. When you create a new line for which Vim automatically provides indentation, and you don't add any text on that line, and you then move to a different line, Vim removes the indentation. This is by design, to avoid adding superfluous white space to a buffer. The delete button should delete one character. Why would you expect it to delete a line, and a different line at that? > Which in some cases is kind of annoying so most IDE's delete the next line > when > delete is pressed if the next line contains only /t's. That seems weird. A text file is simply a sequence of characters. Different editors have different ways of representing that to the user. In Unix, by convention, a text file is a sequence of lines, where each line is a sequence of characters terminated by a newline. Vim represents each line as a line-object (my term) without a newline. The end-of-line sequence terminating each line is implicit and does not appear in the Vim buffer, which is simply a sequence of line-objects. I'm not sure that was very clear. My point is that Vim's representation of a text file in a buffer may differ from what you're used to. It isn't a bug; it's by design. You may have to think differently about what it means to edit a Vim buffer for some of Vim's behavior to make sense to you. Regards, Gary -- -- 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/20240318172831.GE2578%40phoenix.
Re: [vim/vim] Add XDG_BASE_DIR support (PR #14182)
On 2024-03-15, Christian Brabandt wrote: > we could just use XDG_CONFIG_HOME/vim as we use $HOME/.vim only if we find > a XDG_CONFIG_HOME/vim/vimrc. But I would also put the viminfo in > XDG_CONFIG_HOME/vim since if the user is using XDG_DIRS they don't want > clutter in their HOME. > > That sounds fine. Except that the contents of ~/.vim is typically shareable among different vim installations, e.g., on different machines, while files such as ~/.viminfo are not. I use Dropbox and unison to keep my configuration files synced across several machines. I don't want register contents and command histories shared among those machines. If someone wants their viminfo file in some directory other than $HOME, they can always rename it in 'viminfo'. Yes, I could do that, too, but I really don't think the viminfo file belongs in the vim directory. Regards, Gary -- -- 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/20240315160908.GD2578%40phoenix.
Re: [vim/vim] Vim won't recognize custom colorschemes (Issue #14151)
On 2024-03-06, ShinyNeonCalvin wrote: > Steps to reproduce > > 1. Make a colorscheme file > 2. Put it in the same folder as other colorschemes > > Expected behaviour > > At one time, I was able to have vim recognize a color scheme I made by just > putting this code in the file and putting the file in :/usr/local/share/vim/ > vim90/colors/horror.vim with the other color scheme that come with a vim > installation: > > let g:colors_name = 'colorscheme-name' > > But now, this doesn't work. I've noticed this didn't work for GUI vim in > general, but there was a time when putting 'colorscheme ' worked like it did > the same as it does for the ones that come with the installation when you use > the standard terminal version of this software. > > Version of Vim > > 9.1 Since you're running 9.1, Vim is going to look for colorschemes in /usr/local/share/vim/vim91/colors rather than in /usr/local/share/vim/vim90/colors. That is one reason you should _never_ add files to or modify files in the $VIMRUNTIME directory (e.g., /usr/local/share/vim/vim91). Those files may be overwritten during an upgrade to a newer patch level or may no longer be in the 'runtimepath' when Vim is upgraded to a new release. Any files that you add or modify should be put in your ~/.vim directory, as Christian suggested, or in $VIM/vimfiles if you want to make them available to all users. Regards, Gary -- -- 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/20240308001552.GC2578%40phoenix.
Re: [vim/vim] Unintuitive behavior of navigating the jumplist (not obvious if cursor will be centered or not) (Issue #14132)
On 2024-03-05, Christian Brabandt wrote:
> Hm, thanks for your suggestion. I have mad a very quick patch here:
> chrisbra@fe4a04a
>
> This misses test so is not yet ready to be included, but you may want to try
> it
> out.
We should probably understand what Vim is doing now and why before
making severe changes and possibly reinventing rules.
While I agree that Vim's behavior can appear random, I do appreciate
that it seems to try to minimize scrolling and surprising jumps.
For example, when using % to jump between the top and bottom of
a block delimited by { and } or by #if and #endif, if the target
line is just off the top or bottom of the screen, Vim will scroll
the screen just a bit so that the target line and the cursor are at
the top or bottom line of the screen, as appropriate.
My guess is that there is a parameter somewhere in the code that
tells Vim, "if the screen would need to be scrolled less than
N lines to display the target line, scroll as little as possible;
otherwise, jump and center the cursor."
Maybe it would be sufficient to let users adjust that parameter, if
it exists.
Regards,
Gary
--
--
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/20240305222828.GB2578%40phoenix.
Re: [vim/vim] Please add hotkeys list to title page (Issue #14058)
On 2024-02-20, tyler-suard-parker wrote: > @chrisbra @zzzyxwvut I understand, I used Nano for years, despite Vim being > the > vastly superior editor, because Nano has the hotkeys right there on the > screen, > which makes it way easier to use. I know we can't do that with Vim, but just > having some of the essential commands right there on the main screen would go > a > long way to making Vim more user-friendly for beginners and more popular. > Also, > it is not clear that on-line help will show what the keystrokes are, or how to > use Vim. When I read on-line help, I think of talking to a tech support > representative, who might tell me that Vim is working but would not tell me > how > to use it. Except that that intro screen is there only until the user makes some change to the buffer, then it's gone. At that point, the user is not going to remember a long list of commands, but they may remember a very short list telling them how to exit and how to find help. I think that showing them more information than is already there would actually be _less_ helpful. Vim's built-in help _does_ show what the important keystrokes are as well as directing the user to more topics. It is probably the best help system you will find in any editor. In fact, if a new user learns only one thing from the intro screen, it should be to type ":help". That will show them how to quit. If you think that there should be an easier way for the user to find the list of commands you suggested, putting them in an easy-to- discover place under :help would be better than on the intro screen. Regards, Gary -- -- 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/20240220213315.GI26982%40phoenix.
Re: Proposal/Discussion on decoupling clipboard functionality from X11
On 2024-02-09, luca.saccar...@saccarosium.com wrote: > Hi all, > I would like to make a proposal for decoupling the clipboard > functionality from X11. > > I've study the code base for some time but I still need some help on > where and how exactly do this. > > The problem > === > > Currently in vim, on Linux, rely on X11 to interact with the system > clipboard. This come with the limitation that vim needs to be compiled > agaist X11. This means that the base vim package, in most distribution, > as no way to interact with the system clipboard which is a really nice, > sometimes essential, feature to have. > > If a normal user wants to have this feature they need to compile vim, > which is not something that everyone is comfortable doing, or install > gvim, which a lot of users don't want to have it installed. There are a couple of misunderstandings here. Many distributions offer a vim compiled with the X11 feature. The name of the package may not make that clear. For example, in Ubuntu, you would install the vim-gtk package. That would install _one_ vim binary that is linked to several names, including vim and gvim. The user can use vim or gvim as they choose--it's one binary that runs with a GUI or a terminal interface depending on the name by which it is invoked. Alternatively, if you have a gvim on your system, you can create a link to it named vim like this: ln -s /usr/bin/gvim ~/bin/vim as long as the directory containing the new vim link comes before the directory containing your non-X11 vim in your PATH. You could instead create an alias such as this: alias vim='gvim -v' Any of those will give you a vim with X11 enabled. Regards, Gary -- -- 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/20240210070150.GF26982%40phoenix.
Re: "around word" doesn't behave consistently due to white space, why?
On 2024-01-16, Britton Kerin wrote: > The sequence 'vaw' (visual around word is how I think of it) does > weird things depending on white space: > > * 'vaw' while on 'a' in 'foo bar' selects ' bar' (space followed by bar) > > * 'vaw' while on 'a' in 'foo bar ' (with trailing space) selects > 'bar ' (bar followed by space) > > Why? > > I could understand (though not exact agree with the policy) if spaces > are being viewed as part of particular words in this context, but I > don't see why adding a space after bar causes the one before it to not > be selected. I can't find where this is documented, but Vim defines "a word", for most purposes, as a sequence of word characters followed by white space. That definition can't hold at the end of the line, so the developers were left with a choice of including the preceding white space or not including any white space. The choice to include the preceding white space is pragmatic. If you want to cut a word from one place and paste it somewhere else, it is convenient for that cut to include white space so that you don't have to remove it separately from the cut location nor add it separately to the paste location. There is no following white space at the end of a line, so the preceding white space is included instead. Also, if you delete a word at the end of a line, presumably you don't want to leave white space at the end of that line. That logic is also applied in other situations where a sequence of word characters is followed by a non-word character such as a closing parenthesis. Regards, Gary -- -- 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/20240119164847.GC26982%40phoenix.
Re: [vim/vim] Syntax-based folding in gVim doesn't work on some Windows machines (Issue #13874)
On 2024-01-17, FEA-eng wrote: Try this on the machines where syntax folding works and where it doesn't while editing a file for which you expect it to work. :verbose set foldmethod? That should tell you where 'foldmethod' was last set and the value it was set to. Regards, Gary -- -- 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/20240117202839.GA26982%40phoenix.
Re: Commit: patch 9.1.0009: Cannot easily get the list of matches
On 2024-01-08, Yegappan Lakshmanan wrote: > Hi Gary, > > On Mon, Jan 8, 2024 at 12:14 PM Gary Johnson wrote: > > On 2024-01-07, Yegappan Lakshmanan wrote: > > > To demonstrate the use of the new matchbufline() function, I have > created > > the following script. This does search text completion from the list of > words > > in the current buffer. After typing a few letters in the "/" prompt, if > you > > press > > Tab, it will complete the word from the current buffer. If you press > Tab > > again, > > then it will go to the next match. If you press Shift-Tab, it will go > back to > > the previous match. > > I saved your script to a file and sourced it, but it gives me an > error. > > Error detected while processing /home/gary/.vim/match_tab.vim: > line 9: > E1171: Missing } after inline function > > Line 9 is: > > def SearchComplete(forward: bool): string > > > > I am not sure what is wrong from the above error message. In case there > is a cut/paste error, can you please try the attached file? Hi Yegappan, Thank you. That fixed the problem. I had copied your script from your original posting by decode-saving your message from mutt, then deleting the text before and after the script. It turns out that the leading spaces in that copy included non-breaking space characters, 0xa0, which somehow confused Vim's parser. I did have to convert your attachment from DOS to Unix line endings, but that was immediately apparent and not a problem. Regards, Gary -- -- 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/20240108230219.GK4044%40phoenix.
Re: Commit: patch 9.1.0009: Cannot easily get the list of matches
On 2024-01-07, Yegappan Lakshmanan wrote: > To demonstrate the use of the new matchbufline() function, I have created > the following script. This does search text completion from the list of words > in the current buffer. After typing a few letters in the "/" prompt, if you > press > Tab, it will complete the word from the current buffer. If you press Tab > again, > then it will go to the next match. If you press Shift-Tab, it will go back to > the previous match. I saved your script to a file and sourced it, but it gives me an error. Error detected while processing /home/gary/.vim/match_tab.vim: line9: E1171: Missing } after inline function Line 9 is: def SearchComplete(forward: bool): string I've updated to 9.1.16 and done a clean build without any configuration options. I haven't done anything with vim9script, so I don't recognize syntax errors by sight, nor do I know what else I might be missing. Regards, Gary $ VIMRUNTIME=runtime src/vim --version VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jan 8 2024 11:48:09) Included patches: 1-16 Compiled by gary@epicurus Huge version with GTK3 GUI. Features included (+) or not (-): +acl +file_in_path +mouse_urxvt -tag_any_white +arabic+find_in_path +mouse_xterm -tcl +autocmd +float +multi_byte+termguicolors +autochdir +folding +multi_lang+terminal -autoservername-footer-mzscheme +terminfo +balloon_eval +fork()+netbeans_intg +termresponse +balloon_eval_term +gettext +num64 +textobjects +browse-hangul_input +packages +textprop ++builtin_terms+iconv +path_extra+timers +byte_offset +insert_expand -perl +title +channel +ipv6 +persistent_undo +toolbar +cindent +job +popupwin +user_commands +clientserver +jumplist +postscript+vartabs +clipboard +keymap+printer +vertsplit +cmdline_compl +lambda+profile +vim9script +cmdline_hist +langmap -python+viminfo +cmdline_info +libcall -python3 +virtualedit +comments +linebreak +quickfix +visual +conceal +lispindent+reltime +visualextra +cryptv+listcmds +rightleft +vreplace +cscope+localmap -ruby +wildignore +cursorbind-lua +scrollbind+wildmenu +cursorshape +menu +signs +windows +dialog_con_gui+mksession +smartindent +writebackup +diff +modify_fname +sodium+X11 +digraphs +mouse +sound +xattr +dnd +mouseshape+spell -xfontset -ebcdic+mouse_dec +startuptime +xim +emacs_tags+mouse_gpm +statusline+xpm +eval -mouse_jsbterm -sun_workshop +xsmp_interact +ex_extra +mouse_netterm +syntax+xterm_clipboard +extra_search +mouse_sgr +tag_binary-xterm_save -farsi -mouse_sysmouse-tag_old_static system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" 2nd user gvimrc file: "~/.vim/gvimrc" defaults file: "$VIMRUNTIME/defaults.vim" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/usr/local/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/x86_64-linux-gnu -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -O2 -fno-strength-reduce -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lselinux -lcanberra -lsodium
Re: [vim/vim] enhance TermResponse to carry the attribute queried (PR #13829)
On 2024-01-07, Danek Duvall wrote: > I wanted to be able to set the colorscheme based on the terminal colors (and > adapt to terminal color changes), but there was no mechanism where > v:termrbgresp was reliably correctly set. This enhances TermResponse to > deliver > the type of response it got so that a handler can pick it apart and make > decisions based on it. > > The only real problem with the concept is that if you want to make decisions > based on both foreground and background, there's no way to know if both are > set > correctly. I'm not sure what a mechanism that provided that would even look > like. > > fgbg_event is probably wrong, but I needed something to check with has(). So, as I understand your change, where I now use :autocmd TermResponse * ... to wait for just the response to t_RV, I will now have to use :autocmd TermResponse ver ... If so, that may mess up a plugin expecting the former to respond only to the version. Other than that, this seems like a nice feature. Maybe change the event name? Regards, Gary -- -- 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/20240108011042.GI4044%40phoenix.
Re: [vim/vim] Remove diff* links added in #13776 and doc added in commit b1392be (PR #13825)
On 2024-01-07, Christian Brabandt wrote: > I have made a few minor changes, which turned out to be even more involved: > > • Renamed those new groups to Added, Changed and Removed (I initially went > with capitalizing the diffAdded to DiffAdded, but since hightlighting > groups are not case sensitive, it causes problems for linking the groups > in > the color schemes, so I had to make the name different and removed the > diff > prefix) > • Changed the links in the default colorschemes > • linked those new groups back in the diff syntax file. > • capitalize the color names consistently > > That is what I have temporarily queued, not sending out yet, would like to get > an okay for that.: > > https://github.com/chrisbra/vim/commit/0fea0abf5a2e4a9b91df9b1c0084d42e9a44f82d I tried cloning your repo without pulling down everything, $ clone --depth 3 --no-single-branch https://github.com/chrisbra/vim.git but it didn't include that commit. The latest relevant commit appeared to be cdd869fd9, so I checked that out and built it. The result looks pretty good on an xterm, tested with the following. $ git diff cdd869fd9^ cdd869fd9 | VIMRUNTIME=runtime src/vim -N -u NONE -i NONE --cmd 'set rtp=runtime' -c 'syntax on' - Regards, Gary -- -- 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/20240107210519.GH4044%40phoenix.
Re: [vim/vim] runtime(diff): Update default links (PR #13776)
On 2024-01-04, Christian Brabandt wrote: > Yeah also true. Whatever you do, you will choice wrong 🙈 I hadn't followed this discussion until just now when I did a git commit and looked at the diff section. It is butt ugly and unreadable. I use Vim to look at diffs daily, mostly in diff mode but often to look at patches. I have never run into any problems with the previous defaults. If some new application needs some new diff color thingy then add something, but retain the existing defaults and don't make drastic changes to defaults that had been working fine. Regards, Gary -- -- 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/20240106095326.GG4044%40phoenix.
Re: [vim/vim] Backward paragraph motion (i.e., {) does not behave as expected for one-line buffers (Issue #13780)
On 2023-12-26, Edwin Chan wrote:
> Steps to reproduce
>
> 1. Create a buffer with a single line of arbitrary text
> 2. Place the cursor anywhere on the line and perform any of the following
> actions:
> a. Press }: The cursor jumps to the end of the line
> b. Press {: The cursor unexpectedly jumps to the end of the line
> c. Press d, y, v, etc., followed by either } or {: The behavior is similar
> to the two cases above
>
> Expected behaviour
>
> If there are multiple non-empty lines (i.e., a single paragraph) in the
> buffer,
> } jumps to the end of the buffer and { jumps to the beginning. Therefore, {
> should similarly jump to the beginning of the buffer when there is only one
> line.
>
> See also https://vi.stackexchange.com/q/43730 for related discussion.
>
> Version of Vim
>
> 8.2.2121
This bug is also in the oldest version of vim I have already
compiled, 7.2.330.
If I understand the original author's intent, then the following
patch to 9.0.2185 seems to fix it. I may have missed something, but
I ran "make test" before and after the fix and the same tests failed
both times, so this fix doesn't break anything being tested.
Regards,
Gary
diff --git a/src/textobject.c b/src/textobject.c
index b315d0320..d4380b7cf 100644
--- a/src/textobject.c
+++ b/src/textobject.c
@@ -226,7 +226,7 @@ findpar(
if (both && *ml_get(curr) == '}') // include line with '}'
++curr;
curwin->w_cursor.lnum = curr;
-if (curr == curbuf->b_ml.ml_line_count && what != '}')
+if (curr == curbuf->b_ml.ml_line_count && what != '}' && dir > 0)
{
char_u *line = ml_get(curr);
--
--
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/20231227102510.GF4044%40phoenix.
Re: [vim/vim] GVIM not reporting correct byte offsets (Issue #13731)
On 2023-12-20, zeertzjq wrote: > And, some bytes in the file correspond to a multibyte char in latin-1 > encoding, > so such a byte counts as two bytes. I didn't understand that statement at first, but now I do. Thanks. When Vim's 'encoding' is utf-8 and it reads a file it sees as having a 'fileencoding' of latin1, it expands the latin1-encoded characters into utf-8-encoded characters in the buffer. Latin1-encoding uses 1 byte per character while UTF-8 uses 1, 2, 3 or 4 bytes per character. So the number of bytes in Vim's buffer may exceed the number of bytes in the file, as it does in the OP's case. If that's a problem, you can fix it by forcing Vim to use latin1 internally: $ vim --cmd 'set enc=latin1 nofixeol' index_video_5_0_1.mp4 or set binary mode: $ vim -b --cmd 'set noeol' index_video_5_0_1.mp4 Regards, Gary -- -- 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/20231220200821.GE4044%40phoenix.
Re: [vim/vim] GVIM not reporting correct byte offsets (Issue #13731)
On 2023-12-19, 3052 wrote:
> Steps to reproduce
>
> using this file (inside, not the zip):
>
> https://github.com/vim/vim/files/13720982/index_video_5_0_1.zip
>
> If I open the same file in GVIM and enter /mdat, enter, g, ctrl+g I get:
>
> Byte 2785
>
> Expected behaviour
>
> if I run this Go program:
>
> package main
>
> import (
>"bytes"
>"os"
> )
>
> func main() {
>b, err := os.ReadFile("index_video_5_0_1.mp4")
>if err != nil {
> panic(err)
>}
>i := bytes.Index(b, []byte("mdat"))
>println(i)
> }
>
> I get 2578. why is Vim off by over 200 bytes?
>
> Version of Vim
>
> https://github.com/vim/vim-win32-installer/releases/tag/v9.0.2175
>
> Environment
>
> https://github.com/vim/vim-win32-installer/releases/tag/v9.0.2175
I can replicate it with vim 9.0.2130 on Ubuntu 20.04, but I can't
explain it. Rather than use a custom program to count the bytes,
I just used hexdump. The full output of g Ctrl-G in vim is this:
Col 551-983 of 1063-1559; Line 8 of 4914; Word 713 of 35890; Char 2579 of
1282363; Byte 2785 of 1920490
Note that it reports "Char 2579", which should be byte 2579.
Regards,
Gary
--
--
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/20231220071933.GD4044%40phoenix.
Re: [vim/vim] Where to set compiler options to read /etc/vim, ~./vimrc, and `~/.vim/`? (Discussion #13268)
On 2023-10-04, Darin Hensley wrote: > I am compiling VIM in Ubuntu 20.04. I tried compiling it according to this > doc. > However, I can not get it to read the system file /etc/vim. It also does not > read ~./vimrc and does not read ~/.vim/ (contains colors, pack, plugins, etc) > and does not read ~/.vimrc. Where do I set these settings so it compiles with > these? The default configuration should just work. I've never had to set any of those when building Vim. The system I use most often is also Ubuntu 20.04. The output of :version or "vim --version" should contain a block like this, where the locations of all those files are shown. system vimrc file: "$VIM/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" 2nd user gvimrc file: "~/.vim/gvimrc" defaults file: "$VIMRUNTIME/defaults.vim" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/usr/local/share/vim" Does yours look like that? Also, you can see where Vim is finding these files at startup with the :scriptnames command. What files does that command show? If those don't give you enough clues, then another tool to try is strace, e.g., $ strace -o strace.out vim -cq The resulting strace.out file will show you all the files that vim checked the status of and tried to open. That would show if vim tried to open any of those files and why it may have failed. HTH, Gary -- -- 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/20231004184129.GE7180%40phoenix.
Re: [vim/vim] Guide to writing error messages (Discussion #13135)
On 2023-10-01, Restorer wrote: > Perhaps future codes can and should be grouped? > > The question is by what principle to group the messages. > Is it worth making groups for each Vim command (function). Or should they be > grouped by data types, or by Vim modes? > In my opinion, a good starting point would be the features available in the > editor combined with the already existing categorization for built-in > functions. > But whichever variant is adopted, there should necessarily be separate groups, > it seems to me, for cases that don't fall under any of the criteria (and there > are and will be such messages) and a group for internal Vim errors. I like your proposals so far, but I don't think this really matters. Since we have one central repository for the code, I don't think there's much chance of two committers using the same code, and if they do, it's easy to fix. The error codes themselves have never conveyed any information that I know of. All the information has been in the error message. And when that's not enough, there is :help on the error code. As you have discovered, it isn't easy to come up with a consistent, meaningful scheme for assigning numbers, either. And if some block of error codes is ever filled, you're back to choosing a next code that doesn't follow that scheme. Regards, Gary -- -- 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/20231002003718.GD7180%40phoenix.
Re: [vim/vim] inoremap /inoremap do not disable mouse cursor movements (#4900)
On 2023-09-28, SturkenSnure wrote:
> I'm having the same problem.
>
> The only solution I have found is to use a terminal emulator like rxvt.
> Otherwise, every other terminal emulator (gnome-terminal, konsole, kitty, etc)
> do the same thing.
>
> This is a really annoying feature. It should be possible to disable mouse
> scrolling in vim. Especially in insert mode.
>
> I have been using vi for almost 30 years. These strange "features" seem to
> creep up recently. Have been doing a lot of searching to turn off these bugs
> ("features").
>
> Some great settings to disable some of these bugs (features):
> set t_BE=
> set mouse=
> set ttymouse=
>
> But none of these fix the scroll wheel problem.
imap
imap
work fine for me in xterm, xfce4-terminal and GNOME Terminal. For
those to work, however, Vim must have control of the mouse, so you
can't expect those to work and have
:set mouse=
which gives control of the mouse to the terminal. Just leave
:set mouse=a
Regards,
Gary
--
--
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/20230928173443.GC7180%40phoenix.
Re: [vim/vim] Fix 'scrollbind' not working when scrolling inactive window (PR #13189)
On 2023-09-25, errael wrote: > I thought it was supposed to work that way. It is handy to be able to > scroll the two windows independently by just clicking and moving the > mouse. > > I actually was using that feature today. I'd never know explicitly about it, > and was surprised, but it was very handy. I did a little looking. The current behavior is described in ":help scroll-binding". When using the scrollbars, the binding only happens when scrolling the window with focus (where the cursor is). You can use this to avoid scroll-binding for a moment without resetting options. Therefore, this proposed "fix" should not be accepted. Regards, Gary -- -- 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/20230926065513.GB7180%40phoenix.
Re: [vim/vim] Fix 'scrollbind' not working when scrolling inactive window (PR #13189)
On 2023-09-25, zeertzjq wrote: > Problem: 'scrollbind' doesn't work when scrolling inactive window. > Solution: Call do_check_scrollbind() after scrolling inactive window. I thought it was supposed to work that way. It _is_ handy to be able to scroll the two windows independently by just clicking and moving the mouse. Regards, Gary -- -- 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/20230926063746.GA7180%40phoenix.
Re: bell(), looking for builtin function to ring the bell
On 2023-09-13, Ernie Rael wrote:
> Greetings,
>
> In a plugin I'm working on, when certain simple errors occur, I want to ring
> the bell, some kind of alert. A popup, use in some place in the plugin, is
> more
> than is needed.
>
> The closest thing I can find is
>
> call sound_playevent('bell')
>
> which isn't cross platform.
>
> What have I missed?
I use
normal \
but I don't know how cross-platform it is. It's documented at
:help :echoerr
You don't have to use :exe. I surround it with a test for
'errorbells', e.g.,
if &errorbells
normal \ " Generate a bell
endif
echohl ErrorMsg
echomsg "Oops!"
echohl None
Regards,
Gary
--
--
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/20230913174857.GD2657%40phoenix.
Re: [vim/vim] Vim cannot write *.vba files (#2694)
On 2023-08-19, Christian Brabandt wrote: > Yes, probably should get vimball as an own filetype. And possibly also get rid > of .vba as extension for vimball. It's been long gone and nowadays vimballs > use > the .vmb extension anyhow. All of the vimballs I have from Chip Campbell use the .vba extension. The first line of a .vba file could be inspected to determine whether it was a vimball. Regards, Gary -- -- 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/20230823160049.GS6600%40phoenix.
Re: [vim/vim] recompress vim48x48.png to save space (PR #12709)
On 2023-07-29, partev wrote: > closing this pull request. If you change your mind you can always run advpng > -z > -4 -i 400 $(find . -name '*.png') > > there are two more cases where 1.7 kB space saving is real and not impacted by > filesystem block size. What do you mean by that? How is the space used not impacted by the block size? > 1. various Linux packages of vim (.deb, .rpm, .tar.gz, etc.) will be 1.7 kB > smaller. > 2. various Linux container images (docker, LXC, etc.), most of which include > vim by default. In these case, you won't save any space unless the number of blocks occupied decreases, which is going to depend on how full the last block is. Again, this is a non-problem and not worth any effort to "fix". Regards, Gary -- -- 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/20230730161803.GR6600%40phoenix.
Re: [vim/vim] recompress vim48x48.png to save space (PR #12709)
On 2023-07-27, partev wrote: > I agree that doing only one .png file is maybe not worth doing, but > re-compressing all of them saves 1760 bytes, which I think is worth it. Except that, as Eric pointed out, it doesn't save any space at all. $ ll *.png -rw-rw-r-- 1 gary gary 454 Dec 7 2018 hi16-action-make.png -rw-rw-r-- 1 gary gary 425 Dec 7 2018 hi22-action-make.png -rw-rw-r-- 1 gary gary 226 Dec 7 2018 vim16x16.png -rw-rw-r-- 1 gary gary 347 Dec 7 2018 vim32x32.png -rw-rw-r-- 1 gary gary 474 Dec 7 2018 vim48x48.png Note that each file is less than 512 bytes, the smallest block size that I'm aware of. The block size on my hard drive is 4 kB, so each file easily fits within one block. $ du -sh *.png 4.0Khi16-action-make.png 4.0Khi22-action-make.png 4.0Kvim16x16.png 4.0Kvim32x32.png 4.0Kvim48x48.png So, compressing them will not have any effect at all on disk-space consumption. Something else you should consider is that, on my system, /usr/local/share/vim/vim90 consumes 41 MB and the *vim* files in /usr/local/bin consume 21 MB. Out of 62 MB, 1.7 kB is nothing--definitely not worth doing _anything_ about. Regards, Gary -- -- 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/20230727161412.GQ6600%40phoenix.
Re: [vim/vim] colored spaces in listchars (Issue #12705)
As others have written, if you're using gvim, it should just work because Vim is doing the copying and knows not to include the listchars characters. But even if you're using vim in a terminal such as xterm, it should also just work, because if Vim is properly configured to do the copying, again it knows not to include the listchars characters. The problem occurs when you use vim in a terminal and you let the terminal do the copying. I almost always use vim in a terminal. Vim has the +clipboard, +xterm_clipboard and +X11 features enabled, and has "mouse=a" and "clipboard=unnamed,autoselect,exclude:cons\|linux" set. I don't normally use the mouse much, but I just tried an experiment where I set 'listchars' in one vim instance, used the left mouse button to copy a block of text, then used the middle mouse button to paste it into another vim instance and all the actual text was pasted but none of the listchars characters. A common problem is that some distributions include a version of vim that does not have the +X11 feature. Check that with ":version". I don't know about the Windows Console--I never use it. Regards, Gary -- -- 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/20230725141637.GP6600%40phoenix.
Re: [vim/vim] :copen opens quickfix window below `lastwin` instead of `curwin` (Issue #12501)
On 2023-06-26, Enan Ajmain wrote: > But out of curiosity, this isn't what OP was after, is it? Munif was > looking to change the default QF behavior by opening the QF window under > the current window. Your function, Gary, opens the file in QF entry in > the previous window. They are different asks, AFAI can tell. I believe you are correct. I read the OP's request too hastily. Thank you for the tactful correction. Regards, Gary -- -- 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/20230626051431.GI6600%40phoenix.
Re: [vim/vim] :copen opens quickfix window below `lastwin` instead of `curwin` (Issue #12501)
On 2023-06-07, Munif Tanjim wrote:
> Might be that I'm misunderstanding the expected behavior.
>
> If it's not supposed to be opened under curwin, would it be possible to change
> the default behavior to open with WSP_BOT (instead of WSP_BELOW)?
I didn't like the default behavior, either, so I added this to my
~/.vim/after/ftplugin/qf.vim.
" The following is taken from the QFEnter.vim plugin,
" http://vim.sourceforge.net/scripts/script.php?script_id=4778,
" by yssl. I extracted and simplified the part I needed: When
" jumping to items from the quickfix window, open them in the
" previous window instead of the window above the quickfix
" window.
nnoremap:call QfEnter()
let b:undo_ftplugin .= "| nunmap "
function! QfEnter()
let l:lnum = line('.')
wincmd p
try
exe 'cc' l:lnum
normal! zv
catch /E37/
if &errorbells
normal \ " Generate a bell
endif
echohl ErrorMsg
echo matchstr(v:exception, ':\zs.*')
echohl None
endtry
endfunction
HTH,
Gary
--
--
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/20230625191658.GH6600%40phoenix.
Re: Bug in :vmap
On 2023-06-19, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > On 2023-06-15, Bram Moolenaar wrote:
> > > > On 2023-06-15, Bram Moolenaar wrote:
> > > > > > Help for :map- says that with , the right side of
> > > > > > a mapping will not be echoed on the command line, but messages from
> > > > > > the executed command are still given. This works with :nmap but not
> > > > > > with :vmap. I would expect it to work with :vmap as well.
> > > > > >
> > > > > > Steps to reproduce
> > > > > >
> > > > > > 1. Put the following in a file, say foo.vim.
> > > > > >
> > > > > > nmap gx :call DebugSilent()
> > > > > > vmap gx :call DebugSilent()
> > > > > > function DebugSilent()
> > > > > > echomsg "from DebugSilent"
> > > > > > endfunction
> > > > > >
> > > > > > 2. Start vim and source that file.
> > > > > >
> > > > > > $ vim -N --clean
> > > > > > :so foo.vim
> > > > > >
> > > > > > 3. Enter some word into the current buffer.
> > > > > >
> > > > > > 4. Visually select that word.
> > > > > >
> > > > > > viw
> > > > > >
> > > > > > 5. Type the mapping.
> > > > > >
> > > > > > gx
> > > > > >
> > > > > > 6. Note that no message appears, or just flashes by briefly.
> > > > > >
> > > > > > 7. Execute :messages to verify that the message was generated and
> > > > > > saved in message history.
> > > > > >
> > > > > > 8. Without visually selecting the word, type the mapping.
> > > > > >
> > > > > > gx
> > > > > >
> > > > > > 9. Note that the message does appear in the command line and
> > > > > > remains there.
> > > > > >
> > > > > > Expected behavior
> > > > > >
> > > > > > I expect the message to remain in the command line after the
> > > > > > execution of the vmap just as it does for a normal map.
> > > > >
> > > > > It appears to work as you expect when 'cmdheight' is 2 or more.
> > > > >
> > > > > Most likely the message is cleared when the "-- VISUAL --" mode
> > > > > message
> > > > > is removed. Setting 'noshowmode' helps.
> > > > >
> > > > > This should not happen though, when the message overwrites the mode
> > > > > then
> > > > > there is no need later to clear the mode message.
> > > >
> > > > I would expect it to work like gf (which itself is inconsistent).
> > > > If I put the cursor over "later" in the paragraph above and type
> > > > gf, I get a persistent error message in the command line:
> > > >
> > > > E447: Can't find file "later" in path
> > > >
> > > > If I visually-select "later" with viw and type gf, I get the same
> > > > message, but it appears for only about one second. It seems like it
> > > > should also persist, but at least I see it and can look in :messages
> > > > to read it again.
> > > >
> > > > 'cmdheight' doesn't seem to affect the behavior of gf, but setting
> > > > 'noshowmode' does "fix" it. It would be nice if visual mode could
> > > > be made smarter about clearing "-- VISUAL --" when that message has
> > > > been overwritten, or at least leave it for a second or two as
> > > > {Visual}gf does.
> > >
> > > The patch I made first had a strict condition of where the message is
> > > displayed. The "gf" error message is on a different line, causing that
> > > condition not to be true. I'll fix that.
> >
> > Your second patch seems to work fine, but the problem in my original
> > mapping and function remained. I finally found and fixed the
> > problem, but I don't understand what's going on.
> >
> > This test mapping and function (f
Re: Bug in :vmap
On 2023-06-15, Bram Moolenaar wrote:
> > On 2023-06-15, Bram Moolenaar wrote:
> > > > Help for :map- says that with , the right side of
> > > > a mapping will not be echoed on the command line, but messages from
> > > > the executed command are still given. This works with :nmap but not
> > > > with :vmap. I would expect it to work with :vmap as well.
> > > >
> > > > Steps to reproduce
> > > >
> > > > 1. Put the following in a file, say foo.vim.
> > > >
> > > > nmap gx :call DebugSilent()
> > > > vmap gx :call DebugSilent()
> > > > function DebugSilent()
> > > > echomsg "from DebugSilent"
> > > > endfunction
> > > >
> > > > 2. Start vim and source that file.
> > > >
> > > > $ vim -N --clean
> > > > :so foo.vim
> > > >
> > > > 3. Enter some word into the current buffer.
> > > >
> > > > 4. Visually select that word.
> > > >
> > > > viw
> > > >
> > > > 5. Type the mapping.
> > > >
> > > > gx
> > > >
> > > > 6. Note that no message appears, or just flashes by briefly.
> > > >
> > > > 7. Execute :messages to verify that the message was generated and
> > > > saved in message history.
> > > >
> > > > 8. Without visually selecting the word, type the mapping.
> > > >
> > > > gx
> > > >
> > > > 9. Note that the message does appear in the command line and
> > > > remains there.
> > > >
> > > > Expected behavior
> > > >
> > > > I expect the message to remain in the command line after the
> > > > execution of the vmap just as it does for a normal map.
> > >
> > > It appears to work as you expect when 'cmdheight' is 2 or more.
> > >
> > > Most likely the message is cleared when the "-- VISUAL --" mode message
> > > is removed. Setting 'noshowmode' helps.
> > >
> > > This should not happen though, when the message overwrites the mode then
> > > there is no need later to clear the mode message.
> >
> > I would expect it to work like gf (which itself is inconsistent).
> > If I put the cursor over "later" in the paragraph above and type
> > gf, I get a persistent error message in the command line:
> >
> > E447: Can't find file "later" in path
> >
> > If I visually-select "later" with viw and type gf, I get the same
> > message, but it appears for only about one second. It seems like it
> > should also persist, but at least I see it and can look in :messages
> > to read it again.
> >
> > 'cmdheight' doesn't seem to affect the behavior of gf, but setting
> > 'noshowmode' does "fix" it. It would be nice if visual mode could
> > be made smarter about clearing "-- VISUAL --" when that message has
> > been overwritten, or at least leave it for a second or two as
> > {Visual}gf does.
>
> The patch I made first had a strict condition of where the message is
> displayed. The "gf" error message is on a different line, causing that
> condition not to be true. I'll fix that.
Your second patch seems to work fine, but the problem in my original
mapping and function remained. I finally found and fixed the
problem, but I don't understand what's going on.
This test mapping and function (from the original problem report)
now works fine when I move the cursor over a word and type "viwgx".
vmap gx :call DebugSilent()
function DebugSilent()
echomsg "from DebugSilent"
endfunction
But if I add this :normal command to the function, the message
disappears.
function DebugSilent()
normal gvy
echomsg "from DebugSilent"
endfunction
If I add :silent in front of the :normal command, the message
persists again as desired.
function DebugSilent()
silent normal gvy
echomsg "from DebugSilent"
endfunction
I don't understand why the :normal command affects a message echoed
_after_ the :normal command.
Regards,
Gary
--
--
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/20230615204451.GE6600%40phoenix.
Re: Patch 9.0.1634
On 2023-06-15, Bram Moolenaar wrote:
> Patch 9.0.1634
> Problem:Message is cleared when removing mode message (Gary Johnson).
> Solution: Do not clear the command line after displaying a message.
> Files: src/message.c, src/testdir/test_messages.vim,
> src/testdir/dumps/Test_message_not_cleared_after_mode_1.dump,
> src/testdir/dumps/Test_message_not_cleared_after_mode_2.dump
Thanks! That fixes the problem in my example and the inconsistency
in {Visual}gf, but it doesn't fix the problem in the code I was
working on when I discovered this. I'll try to find some time today
to figure out what's going on there.
Regards,
Gary
--
--
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/20230615165342.GD6600%40phoenix.
Re: Bug in :vmap
On 2023-06-15, Bram Moolenaar wrote:
> > Help for :map- says that with , the right side of
> > a mapping will not be echoed on the command line, but messages from
> > the executed command are still given. This works with :nmap but not
> > with :vmap. I would expect it to work with :vmap as well.
> >
> > Steps to reproduce
> >
> > 1. Put the following in a file, say foo.vim.
> >
> > nmap gx :call DebugSilent()
> > vmap gx :call DebugSilent()
> > function DebugSilent()
> > echomsg "from DebugSilent"
> > endfunction
> >
> > 2. Start vim and source that file.
> >
> > $ vim -N --clean
> > :so foo.vim
> >
> > 3. Enter some word into the current buffer.
> >
> > 4. Visually select that word.
> >
> > viw
> >
> > 5. Type the mapping.
> >
> > gx
> >
> > 6. Note that no message appears, or just flashes by briefly.
> >
> > 7. Execute :messages to verify that the message was generated and
> > saved in message history.
> >
> > 8. Without visually selecting the word, type the mapping.
> >
> > gx
> >
> > 9. Note that the message does appear in the command line and
> > remains there.
> >
> > Expected behavior
> >
> > I expect the message to remain in the command line after the
> > execution of the vmap just as it does for a normal map.
>
> It appears to work as you expect when 'cmdheight' is 2 or more.
>
> Most likely the message is cleared when the "-- VISUAL --" mode message
> is removed. Setting 'noshowmode' helps.
>
> This should not happen though, when the message overwrites the mode then
> there is no need later to clear the mode message.
I would expect it to work like gf (which itself is inconsistent).
If I put the cursor over "later" in the paragraph above and type
gf, I get a persistent error message in the command line:
E447: Can't find file "later" in path
If I visually-select "later" with viw and type gf, I get the same
message, but it appears for only about one second. It seems like it
should also persist, but at least I see it and can look in :messages
to read it again.
'cmdheight' doesn't seem to affect the behavior of gf, but setting
'noshowmode' does "fix" it. It would be nice if visual mode could
be made smarter about clearing "-- VISUAL --" when that message has
been overwritten, or at least leave it for a second or two as
{Visual}gf does.
Regards,
Gary
--
--
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/20230615162716.GC6600%40phoenix.
Bug in :vmap
Help for :map- says that with , the right side of a mapping will not be echoed on the command line, but messages from the executed command are still given. This works with :nmap but not with :vmap. I would expect it to work with :vmap as well. Steps to reproduce 1. Put the following in a file, say foo.vim. nmap gx :call DebugSilent() vmap gx :call DebugSilent() function DebugSilent() echomsg "from DebugSilent" endfunction 2. Start vim and source that file. $ vim -N --clean :so foo.vim 3. Enter some word into the current buffer. 4. Visually select that word. viw 5. Type the mapping. gx 6. Note that no message appears, or just flashes by briefly. 7. Execute :messages to verify that the message was generated and saved in message history. 8. Without visually selecting the word, type the mapping. gx 9. Note that the message does appear in the command line and remains there. Expected behavior I expect the message to remain in the command line after the execution of the vmap just as it does for a normal map. Version of Vim 9.0.1632 Environment Operating system: Ubuntu 20.04 Terminal: XTerm(380) Value of $TERM:xterm-256color Shell: bash 5.0.17 Regards, Gary -- -- 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/20230614231223.GB6600%40phoenix.
Re: [vim/vim] Provide `shortmess` option to combine `S` messages and search count (Issue #12316)
On 2023-04-29, Dani Dickstein wrote: > Currently the shortmess option matrix for search messages looks like this: > > Feature 'shortmess' setting > +s+S +s-S -s-S -s+S ??? > "search hit TOP/BOTTOM, continuing at BOTTOM/TOP" NNN NYY Y > Y > when search wraps > display "W" when search wraps NNY YNN Y > Y > display search count NYN YNY N > Y > > I find both the first and third feature helpful - I don't often notice the > "W," > esp. since it's on the other side of the screen and I'm not always watching > the > search count. I'd like to have a setting combination that lets me enable both > of them. I don't care whether or not the W is displayed also. +1 Regards, Gary -- -- 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/20230430023855.GC21381%40phoenix.
Re: [vim/vim] sh/bash highlight broken since upgrade of sh.vim version 205 (Issue #11937)
On 2023-04-05, Nick Jensen wrote: > Yes it is: http://www.drchip.org/astronaut/vim/ That page exists, but all the links to his scripts fail with error 404. Regards, Gary -- -- 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/20230405203202.GA9105%40phoenix.
Debug print statements left in list_mappings()?
There seem to be a couple of debug print statements left in list_mappings() in map.c, so that when I execute :verbose abbreviate dt (I have an abbreviation "dt"), I see at the top of the output: Seen modifyOtherKeys: true Kitty keyboard protocol: Cleared I discovered that these were added here: patch 9.0.0794: there is no way to find out if modifyOtherKeys has been seen patch 9.0.0930: cannot debug the Kitty keyboard protocol with TermDebug It seems to me that these are for debugging and have nothing to do with where abbreviations are defined. They just add clutter to the output of ":verbose abbreviate" and should be queried some other way or enabled only for such debugging. Regards, Gary -- -- 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/20230320163624.GC13894%40phoenix.
Re: [vim/vim] Terminal inside Vim sets $LINES environment variable globally instead of locally? (Issue #12160)
On 2023-03-15, user202729 wrote: > I'm not sure if this is a bug or not. > > Basically, if we use bash, then the subprocesses does not inherit the values > of > $LINES environment variable... > > $ echo $LINES > 100 > $ bash -c 'echo $LINES' > > $ bash -ic 'echo $LINES' > 100 > $ > > here, in the second invocation, $LINES environment variable is not inherited > from the parent bash process. > > However, in vim, $LINES are set globally -- if you execute the same commands > in > a :term inside vim, > the second line will also print out the number. > > (note: I think https://stackoverflow.com/q/1780483/ says that these variables > should be set "locally" only, but > it doesn't explain why.) I didn't get from that article that LINES _should_ not be exported, just that it wasn't. This never made sense to me. Several programs use LINES and COLUMNS to know how large a display they have to work with, so I would think that they would always be exported. Many years ago, I put the following in my ~/.bashrc and haven't had any related problems since. export LINES export COLUMNS shopt -s checkwinsize > This is a problem because when I run :term in vim, then run ipython (now in > vim > /term os.environ["LINES"] > is a fixed value, while in xterm/bash it's not set), then run less from it, > the > LINES is fixed regardless of changes > to the environment variable. Unsetting LINES in ipython works as a workaround. Your problem seems to be not that LINES is exported but that it sometimes has the wrong value. I don't understand what you mean when you say it is "fixed regardless of changes". It sounds like you are setting LINES in one process and expecting to affect another, already-running process. You might have a look at this article: https://help.ubuntu.com/community/EnvironmentVariables It would help us to solve this issue if you provided more details, such as exactly what you do to observe the problem and what the problem is. user202729 later wrote: > I think the code responsible for that is https://github.com/vim/vim/blob/ > 67578e5bcf7404d40d42876b738b72e68add1a3e/src/os_unix.c#L4285 > > Maybe it's better to not set the environment variables instead, and let the > subprocess e.g. bash detect it itself? Does it break anything? I am not aware of a specification that says what a program _should_ or _must_ do with environment variables when it forks a child, but I like that vim does what it does; it avoids problems from programs that expect to have LINES and COLUMNS set when they are run. Changing it would probably break some users' scripts. Moreover, I don't see how it should break anything the way it is now. Regards, Gary -- -- 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/20230316185138.GB13894%40phoenix.
Re: [vim/vim] Vim: Warning: Output is not to a terminal (Issue #12071)
On 2023-02-27, Bram Moolenaar wrote: > So, can this issue be closed, or should we change something in Vim? > E.g. adding that :unlet command in the diff filetype plugin? I think it could be closed, but it's not my issue. I don't think there is anything to change in Vim. There are a few other GIT_ environment variables that I unlet in my vimrc because their presence causes odd behavior of git commands launched from Vim or in subshells of Vim, but some users may want to know about the presence of those variables or their values, so I wouldn't automatically unlet them in, say, defaults.vim. The "git difftool" command opens files in their normal file type, so the diff filetype plugin wouldn't apply. By the time the "git diff" command is executed, it's too late to change the command's behavior. At least that's what I observe with my bash, git and Vim configurations. Regards, Gary -- -- 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/20230228021055.GD10570%40phoenix.
Re: [vim/vim] Vim: Warning: Output is not to a terminal (Issue #12071)
On 2023-02-26, Gary Johnson wrote: > On 2023-02-26, huang bin bin wrote: > > Steps to reproduce > > > > 1.git config difftool = vimdiff , > > 2.use git difftool open vimdiff compare git index file . > > 3. execute :r ! git diff or !git diff > newfile then you will see bash get > > hung, it can't back to vim . yout will have to ctrl+z to back terminal ,but > > vim > > and previous bash process still alive background. > > > > by the way, use vim without git , this bug can't reproduct,even in vimdiff > > mode > > > > Expected behaviour > > > > git difftool = vimdiff > > compare git index , can use "!git diff >newfile" write data to a new file > > > > Version of Vim > > > > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jul 25 2021 21:26:36) > > > > Environment > > > > windows > > git bash > > xterm > > I can reproduce this with: > > - Vim 9.0.1355 > - Git 2.34.1 > - Ubuntu 22.04 > > I made sure my vimrc was not a factor by creating a file named vim > in my home directory: > > #!/bin/bash > exec /usr/local/bin/vim -N -u NONE -i NONE "$@" > > and starting git like this: > > $ PATH=$HOME:$PATH git difftool > > :r!git diff > > I did notice that with my normal vimrc, the ":r!git diff" command > does not hang Vim, but instead inserts these three lines into the > buffer: > > Vim: Warning: Output is not to a terminal > ^[[24;1H^[[23;2t^[[23;1t^[[J2 files to edit > fatal: external diff died, stopping at src/search.c > > where those ^[ are Vim's rendering of escape characters and > src/search.c is the only modified file in my Vim repo, where I ran > these commands. The difference is probably due to some workarounds > in my vimrc for other problems Vim has with launching sub-shells. > I haven't tried to identify the settings that affect this problem. This appears to be a bug in git rather than a bug in vim. The 'git diff' command normally pipes a context diff to less. Under the conditions of this bug report, it appears that git is using 'vim -d ...' _and_ piping the output to less. I can't tell exactly what git thinks it's doing, but I think I've found a workaround: after executing 'git difftool', in Vim, execute: :unlet $GIT_EXTERNAL_DIFF before executing ':r!git diff' or any other git command. That could probably be put in your vimrc, but I haven't tried that yet to check for side-effects. HTH, Gary -- -- 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/20230227031630.GC10570%40phoenix.
Re: [vim/vim] Vim: Warning: Output is not to a terminal (Issue #12071)
On 2023-02-26, huang bin bin wrote: > Steps to reproduce > > 1.git config difftool = vimdiff , > 2.use git difftool open vimdiff compare git index file . > 3. execute :r ! git diff or !git diff > newfile then you will see bash get > hung, it can't back to vim . yout will have to ctrl+z to back terminal ,but > vim > and previous bash process still alive background. > > by the way, use vim without git , this bug can't reproduct,even in vimdiff > mode > > Expected behaviour > > git difftool = vimdiff > compare git index , can use "!git diff >newfile" write data to a new file > > Version of Vim > > VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jul 25 2021 21:26:36) > > Environment > > windows > git bash > xterm I can reproduce this with: - Vim 9.0.1355 - Git 2.34.1 - Ubuntu 22.04 I made sure my vimrc was not a factor by creating a file named vim in my home directory: #!/bin/bash exec /usr/local/bin/vim -N -u NONE -i NONE "$@" and starting git like this: $ PATH=$HOME:$PATH git difftool :r!git diff I did notice that with my normal vimrc, the ":r!git diff" command does not hang Vim, but instead inserts these three lines into the buffer: Vim: Warning: Output is not to a terminal ^[[24;1H^[[23;2t^[[23;1t^[[J2 files to edit fatal: external diff died, stopping at src/search.c where those ^[ are Vim's rendering of escape characters and src/search.c is the only modified file in my Vim repo, where I ran these commands. The difference is probably due to some workarounds in my vimrc for other problems Vim has with launching sub-shells. I haven't tried to identify the settings that affect this problem. Regards, Gary -- -- 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/20230226215800.GB10570%40phoenix.
Scope of 'scrollopt' too much?
I've noticed a problem when I have multiple tab pages open, each containing two windows that are diff'd, and I execute :diffoff! or :tabclose! in one of the tabs. Either one of those commands resets the value of 'scrollopt' from "ver,jump,hor" to "ver,jump". The problem is that 'scrollopt' is a global options, so its reset value affects the diffs in all the tab pages, not just the one in which :diffoff! or :tabclose! was executed. I encounter this problem frequently when using the Fugitive ":Git difftool -y" command and close one of the tabs. It is not a bug in Fugitive; I can reproduce it starting with "$ vim -N -u NONE -i NONE -p file1 file2". I could execute :diffoff again after :diffoff! as mentioned in ":help :diffoff", but that's annoying and not even possible in the :tabclose! case. Would it be possible to fix this problem, perhaps by doing something like making 'scrollopt' tab-local (I know there's currently no such thing) or resetting it to "ver,jump" only when no window in any tab page is in diff mode? Regards, Gary -- -- 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/20230225011522.GA10570%40phoenix.
Re: Bug in patch 9.0.0907 causes E1312 in autocmd
On 2023-01-28, Matt Martini wrote:
> Gary,
>
> I (and others) are having the same issue with vim-nerdtree-tabs.
> It is fully described here: issue #102
>
> There is a function that when a tab is closed, checks if the last buffer is
> NERDTree.
> and if it is it closes/quits.
>
> It was using similar code to yours:
>
> if exists("t:NERDTreeBufName") && bufwinnr(t:NERDTreeBufName) != -1 && winnr
> ("$") == 1
>
> or the variants
>
> if (winnr("$") == 1 && exists("b:NERDTreeType") && b:NERDTreeType ==
> "primary"):
>
> if (winnr("$") == 1 && exists("b:NERDTree") && b:NERDTree.isTabTree())
>
> The code was working until 9.0.900+ (I don't know the exact patch).
>
> Unfortunately, the vim-nerdtree-tabs plugin is no longer maintained, so we
> must
> find a solution on our own.
>
> Were you able to find a workaround or another method of solving your issue?
>
> Matt
Matt,
The solution I finally adopted was to use feedkeys(), like this.
" Note the ending ":\". This clears the "quit" from the command line.
"
autocmd BufWinEnter __Calendar
\ augroup MyCalendar
\ | autocmd!
\ | autocmd BufEnter if winnr("$") == 1 | call
feedkeys(":quit\:\") | endif
\ | augroup END
This isn't all that different from the original code that failed
after patch 9.0.907.
autocmd BufWinEnter __Calendar
\ autocmd BufEnter if winnr("$")==1 | quit | endif
Sometime later, I encountered the same error while using the linediff
plugin (https://badge.fury.io/gh/andrewradev/linediff.vim). I fixed
that one temporarily with this change, then reported it to the
author.
diff --git a/autoload/linediff/differ.vim b/autoload/linediff/differ.vim
index 23a69ce..023c716 100644
--- a/autoload/linediff/differ.vim
+++ b/autoload/linediff/differ.vim
@@ -211,7 +211,11 @@ endfunction
function! linediff#differ#CloseDiffBuffer(force) dict
if bufexists(self.diff_buffer)
let bang = a:force ? '!' : ''
-exe "bdelete".bang." ".self.diff_buffer
+" [GAJ 2022-12-19] Change direct :bdelete command to a feedkeys()
+" operation to work around the new behavior of patch 9.0.907 that
+" prohibits certain operations such as buffer deletions in autocommand
+" contexts. The ":\" erases the command from the command line.
+call feedkeys(":bdelete".bang." ".self.diff_buffer."\:\")
endif
endfunction
He thought there might be a race condition (he may have actually
observed one--I forget) when using feedkeys() and preferred the
following solution.
diff --git a/autoload/linediff/differ.vim b/autoload/linediff/differ.vim
index 23a69ce..b9f3d12 100644
--- a/autoload/linediff/differ.vim
+++ b/autoload/linediff/differ.vim
@@ -211,7 +211,16 @@ endfunction
function! linediff#differ#CloseDiffBuffer(force) dict
if bufexists(self.diff_buffer)
let bang = a:force ? '!' : ''
-exe "bdelete".bang." ".self.diff_buffer
+let diff_buffer = self.diff_buffer
+
+if has('patch-9.0.907')
+ " Vim forbids closing the window inside an autocommand, so let's do
it
+ " afterwards.
+ " Ref: https://github.com/AndrewRadev/linediff.vim/issues/36
+ call timer_start(1, {-> execute('bdelete'.bang.' '.diff_buffer) })
+else
+ exe 'bdelete'.bang.' '.diff_buffer
+endif
endif
endfunction
Regards,
Gary
--
--
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/20230128204917.GG6446%40phoenix.
Re: [vim/vim] Remove 'r' and 'o' from formatoptions. (PR #11700)
On 2022-12-20, madjxatw wrote: > This behavior is really annoying! Whether to insert a comment leader should be > decided by user but not assumed by the editor. Most of the time when placing a > short trailing comment, I don't want a comment continuation. At least o should > be removed. >From my vimrc: autocmd FileType * setlocal formatoptions-=o " Override any filetype plugin's attempt " to set the 'fo' 'o' option, which inserts " a comment leader when opening a new line. HTH, Gary -- -- 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/20221220181246.GD6446%40phoenix.
vim_dev@googlegroups.com
On 2022-12-02, Gary Johnson wrote: > I've submitted a bug report to the mintty project, issue #1189. This doesn't seem to have been a bug in mintty, but mintty resolved the conflict with xterm anyway in version 3.6.3, which is now the latest version in Cygwin. Regards, Gary -- -- 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/20221219191725.GC6446%40phoenix.
Re: Bug in patch 9.0.0907 causes E1312 in autocmd
On 2022-12-14, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > > > I've had an autocommand in my vimrc for quite some time that
> > > > I noticed recently was causing the following error message when
> > > > activated:
> > > >
> > > > Error detected while processing BufEnter Autocommands for
> > > > "":
> > > > E1312: Not allowed to change the window layout in this autocmd
> > > >
> > > > I performed a git bisect on the Vim source and found that the bug
> > > > was introduced here:
> > > >
> > > > d63a85592cef0ee4f0fec5efe2f8d66b31f01f05 is the first bad commit
> > > > commit d63a85592cef0ee4f0fec5efe2f8d66b31f01f05
> > > > Author: Bram Moolenaar
> > > > Date: Sat Nov 19 11:41:30 2022 +
> > > >
> > > > patch 9.0.0907: restoring window after WinScrolled may fail
> > > >
> > > > Problem:Restoring window after WinScrolled may fail.
> > > > Solution: Lock the window layout when triggering WinScrolled.
> > > >
> > > > src/errors.h | 2 ++
> > > > src/ex_docmd.c | 18 -
> > > > src/proto/window.pro | 1 +
> > > > src/version.c| 2 ++
> > > > src/window.c | 56
> > > > +---
> > > > 5 files changed, 71 insertions(+), 8 deletions(-)
> > > >
> > > > This is the autocommand in my vimrc and the reason for it being
> > > > there:
> > > >
> > > > " If the Calendar window is open when the last non-Calendar
> > > > " window is closed, Vim continues to run with the Calendar
> > > > " window occupying the full Vim window. Fix this,
> > > > " automatically close the Calendar window if it is the only
> > > > " window.
> > > > "
> > > > autocmd BufWinEnter __Calendar
> > > > \ autocmd BufEnter if winnr("$")==1 | quit | endif
> > >
> > > So you have a BufEnter autocommand that closes the buffer (with some
> > > condition). The BufEnter event can be triggered in various places, and
> > > they are most likely not prepared for the buffer disappearing.
> >
> > The autocommand is defined only when the buffer name is "__Calendar"
> > and the "" pattern is used so that that is the only buffer
> > in which the command is triggered. The event can be triggered in
> > only one place and that place is prepared for it.
>
> That is your specific situation. Other users may have very different
> situations. And we need to deal with all of them...
>
> > > There already is quite a lot of code to handle side effects of what an
> > > autocmd may do, but it's getting very complicated. In some cases it's
> > > better to just not allow certain actions. For a BufEnter event it seems
> > > quite natural to disallow deleting that buffer. Why would you delete a
> > > buffer you just entered?
> >
> > In this case, I want to delete a buffer if it is the only buffer
> > displayed in the tab. I never use that buffer alone, only alongside
> > another buffer. When I close that other buffer, I want the
> > __Calendar buffer to be deleted, too, because I'm done with it.
> > I got tired of typing ":q" twice, so I created the
> > autocommand to save some typing and time, i.e., to make the scenario
> > "just work" as Vim usually gives me the tools to do.
> >
> > The BufEnter event is used because that's what happens when a window
> > is closed: some other window is entered. And with the test for
> > 'winnr("$")==1', it isn't closed every time it is entered, but only
> > when it is the last open window in the tab.
>
> The idea of BufEnter is that you can set some options specifically for a
> buffer, setup mappings or insert some template text. Deleting the
> buffer isn't really anticipated.
>
> > > Since this stuff is so complicated we keep finding new problems. So
> > > once in a while something that was allowed before is no longer allowed,
> > > because there are situations where it causes a crash.
> > >
> > > The situation you describe seems quite rare, thus I think we just have
> > > to accept this no longer works. You
Re: Bug in patch 9.0.0907 causes E1312 in autocmd
On 2022-12-14, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > I've had an autocommand in my vimrc for quite some time that
> > I noticed recently was causing the following error message when
> > activated:
> >
> > Error detected while processing BufEnter Autocommands for "":
> > E1312: Not allowed to change the window layout in this autocmd
> >
> > I performed a git bisect on the Vim source and found that the bug
> > was introduced here:
> >
> > d63a85592cef0ee4f0fec5efe2f8d66b31f01f05 is the first bad commit
> > commit d63a85592cef0ee4f0fec5efe2f8d66b31f01f05
> > Author: Bram Moolenaar
> > Date: Sat Nov 19 11:41:30 2022 +
> >
> > patch 9.0.0907: restoring window after WinScrolled may fail
> >
> > Problem:Restoring window after WinScrolled may fail.
> > Solution: Lock the window layout when triggering WinScrolled.
> >
> > src/errors.h | 2 ++
> > src/ex_docmd.c | 18 -
> > src/proto/window.pro | 1 +
> > src/version.c| 2 ++
> > src/window.c | 56
> > +---
> > 5 files changed, 71 insertions(+), 8 deletions(-)
> >
> > This is the autocommand in my vimrc and the reason for it being
> > there:
> >
> > " If the Calendar window is open when the last non-Calendar
> > " window is closed, Vim continues to run with the Calendar
> > " window occupying the full Vim window. Fix this,
> > " automatically close the Calendar window if it is the only
> > " window.
> > "
> > autocmd BufWinEnter __Calendar
> > \ autocmd BufEnter if winnr("$")==1 | quit | endif
>
> So you have a BufEnter autocommand that closes the buffer (with some
> condition). The BufEnter event can be triggered in various places, and
> they are most likely not prepared for the buffer disappearing.
The autocommand is defined only when the buffer name is "__Calendar"
and the "" pattern is used so that that is the only buffer
in which the command is triggered. The event can be triggered in
only one place and that place is prepared for it.
> There already is quite a lot of code to handle side effects of what an
> autocmd may do, but it's getting very complicated. In some cases it's
> better to just not allow certain actions. For a BufEnter event it seems
> quite natural to disallow deleting that buffer. Why would you delete a
> buffer you just entered?
In this case, I want to delete a buffer if it is the only buffer
displayed in the tab. I never use that buffer alone, only alongside
another buffer. When I close that other buffer, I want the
__Calendar buffer to be deleted, too, because I'm done with it.
I got tired of typing ":q" twice, so I created the
autocommand to save some typing and time, i.e., to make the scenario
"just work" as Vim usually gives me the tools to do.
The BufEnter event is used because that's what happens when a window
is closed: some other window is entered. And with the test for
'winnr("$")==1', it isn't closed every time it is entered, but only
when it is the last open window in the tab.
> Since this stuff is so complicated we keep finding new problems. So
> once in a while something that was allowed before is no longer allowed,
> because there are situations where it causes a crash.
>
> The situation you describe seems quite rare, thus I think we just have
> to accept this no longer works. You can probably find another way.
I'll buy that the code is getting very complicated and that some use
cases aren't worth supporting. It's just a shame when useful tools
are prevented from working because they don't work in every case,
and frustrating when things that used to work stop working.
I don't know what other event is triggered when a window/buffer
becomes the last one open in a tab. I suppose I could try having
a BufDelete or WinClosed event check whether the buffer/window being
closed is the next-to-last one in a tab, and if the other buffer is
__Calendar, then also close that window somehow. (I know my use of
"window" and "buffer" above is a little loose.) I just hope those
commands haven't required the same protections as BufEnter.
Thanks for taking the time to explain the situation.
Regards,
Gary
--
--
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/20221214174231.GA6446%40phoenix.
Bug in patch 9.0.0907 causes E1312 in autocmd
I've had an autocommand in my vimrc for quite some time that
I noticed recently was causing the following error message when
activated:
Error detected while processing BufEnter Autocommands for "":
E1312: Not allowed to change the window layout in this autocmd
I performed a git bisect on the Vim source and found that the bug
was introduced here:
d63a85592cef0ee4f0fec5efe2f8d66b31f01f05 is the first bad commit
commit d63a85592cef0ee4f0fec5efe2f8d66b31f01f05
Author: Bram Moolenaar
Date: Sat Nov 19 11:41:30 2022 +
patch 9.0.0907: restoring window after WinScrolled may fail
Problem:Restoring window after WinScrolled may fail.
Solution: Lock the window layout when triggering WinScrolled.
src/errors.h | 2 ++
src/ex_docmd.c | 18 -
src/proto/window.pro | 1 +
src/version.c| 2 ++
src/window.c | 56
+---
5 files changed, 71 insertions(+), 8 deletions(-)
This is the autocommand in my vimrc and the reason for it being
there:
" If the Calendar window is open when the last non-Calendar
" window is closed, Vim continues to run with the Calendar
" window occupying the full Vim window. Fix this,
" automatically close the Calendar window if it is the only
" window.
"
autocmd BufWinEnter __Calendar
\ autocmd BufEnter if winnr("$")==1 | quit | endif
Steps to reproduce
1. Start Vim with the following command (one line):
$ vim -N -u NONE -i NONE -c tabnew -c vnew -c 'autocmd BufEnter
if winnr("$")==1 | quit | endif' -c 'wincmd w'
This opens a new tab, opens a new window in that tab, creates
a BufEnter autocommand in that buffer, and moves the cursor to
the right window.
2. Execute
:q
The error message appears.
3. Hit ENTER to continue. The right window has closed, but the
left window (now the only window on that tab page) remains open.
Expected behavior
At step 2, there should be no error message and both windows on the
second tab page should have closed, leaving only the first tab
page.
The right window was closed by :q. That caused the cursor to enter
the remaining window in that tab, triggering the autocommand and
closing that window and the tab.
Version of Vim
Observed on version 9.0.1034. Found to have been introduced at
version 9.0.0907.
Environment
Operating system: Ubuntu 22.04
Terminal: XTerm(373)
Value of $TERM: xterm-256color
Shell: bash
Regards,
Gary
--
--
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/20221214092230.GI16317%40phoenix.
vim_dev@googlegroups.com
On 2022-12-02, Bram Moolenaar wrote: > Gary Johnson wrote: > > [...] > > > > I assume that mintty can't handle the escape sequences that do work for > > > xterm. To find out which one please use a log: > > > > > > vim -N -u NONE -i NONE --log logfile --cmd 'set bg&' > > > > > > Around where you type the edit command you should be able to find some > > > "raw key input:" and "raw terminal output:" lines that hopefully provide > > > more information. > > > > I did that with TERM=xterm-256color and TERM=mintty and used vimdiff > > to compare the two logfiles. I found the offending escape sequence, > > but I don't know what it means. > > > > When TERM=xterm-256color, at the end of the "raw terminal output:" > > line that prints the introductory message is the sequence > > > > ^[[?4m > > > > I looked in the xterm source, in the file ctlseqs.txt, but could not > > find that sequence, i.e., CSI ? ... m. > > This is a new escape sequence that xterm version 377 supports. It is > used to request the current modifyOtherKeys state. It was supposed to > not do anything for existing terminals. It is documented here: > https://invisible-island.net/xterm/ctlseqs/ctlseqs.html > Search for "XTQMODKEYS". Ah. I didn't think about it being a new escape sequence so I looked in the source code I had on hand, which was for version 370. Thanks for the link. > I looked at what appears to be the page that explains escape sequences > for Mintty: https://github.com/mintty/mintty/wiki/CtrlSeqs > I cannot find this escape sequence there. Does this happen > accidentally? You could ask the mintty project about it. I didn't see it there, either. [...] > > I would still like to know what that escape sequence is supposed to > > do. If mintty's response seems to be a bug, then I'll report it to > > the author. > > It would certainly be good to know if mintty intentionally uses this CSI > code for something. It is unexpected, perhaps even a bug. I've submitted a bug report to the mintty project, issue #1189. Regards, Gary -- -- 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/20221203002925.GE16317%40phoenix.
vim_dev@googlegroups.com
On 2022-12-02, Christopher Plewright wrote: > > ESC[4m is "set underline mode" Thanks, but the sequence I'm seeing is ESC[?4m. Regards, Gary -- -- 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/20221202233432.GD16317%40phoenix.
vim_dev@googlegroups.com
On 2022-12-02, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > After updating to the latest Vim, 9.0.0984, and starting Vim in
> > a terminal without a file specified, the command line font was
> > extremely tiny. (I'd estimate the font size to be 4 points.) If
> > a file was opened from the command line, its font in the buffer was
> > also tiny. Subsequent commands typed in the command line were of
> > the expected font. The font in the buffer remained tiny until ^L
> > was typed.
> >
> > Bisecting my vimrc and my usual color scheme plugin revealed the
> > command causing the tiny font to be
> >
> > :set bg&
> >
> > and bisecting the git commits showed the bad commit to be
> > 733a69b29f0b0c3d2ddca463a41bdd912379bc5e, tag v9.0.0980.
> >
> > Steps to reproduce
> >
> > 1. vim -N -u NONE -i NONE --cmd 'set bg&'
> > 2. Type a colon (:) and note that it is in a very tiny font.
> > 3. Continue typing the ex command to edit some file, e.g.,
> > ":e feature.h". Note that the file is displayed in the buffer
> > in the same tiny font.
> >
> > Expected behavior
> >
> > I expect Vim to use the same 11-pt font it normally uses, as set in
> > the terminal's preferences.
> >
> > Version of Vim
> >
> > 9.0.0980 and 9.0.0984
> >
> > Environment
> >
> > Operating system: Cygwin version 3.3.6-1 (latest as of 2022-12-01)
> > on Windows 10 Pro version 22H2
> > Terminal: mintty version 3.6.2-1 (also latest as of 2022-12-01)
> > Value of $TERM: xterm-256color
>
> This doesn't look right. Doesn't mintty have a termcap/terminfo entry
> and you can set $TERM accordingly?
Thanks very much for the reply.
It turns out that it does and you can. I've always left it set to
xterm-256color for the usual reason that "everything" knows how to
talk to an xterm-256color terminal.
I set TERM to mintty and the problem disappears.
> Since $TERM includes "xterm" Vim assumes the terminal behaves like an
> xterm and will enable modifyOtherKeys level 2. This should be harmless
> if the terminal advertises to be working like xterm but doesn't actually
> support it.
>
> I assume that mintty can't handle the escape sequences that do work for
> xterm. To find out which one please use a log:
>
> vim -N -u NONE -i NONE --log logfile --cmd 'set bg&'
>
> Around where you type the edit command you should be able to find some
> "raw key input:" and "raw terminal output:" lines that hopefully provide
> more information.
I did that with TERM=xterm-256color and TERM=mintty and used vimdiff
to compare the two logfiles. I found the offending escape sequence,
but I don't know what it means.
When TERM=xterm-256color, at the end of the "raw terminal output:"
line that prints the introductory message is the sequence
^[[?4m
I looked in the xterm source, in the file ctlseqs.txt, but could not
find that sequence, i.e., CSI ? ... m.
When I send that sequence from Vim to mintty with
:call echoraw("\e[?4m")
characters on the command line are printed in the tiny font.
I did a similar comparison between the logfiles with and without "-c
'set bg&'" argument. When that argument was _not_ present, the
logfile contained additional "raw terminal output:" lines that
presumably reset the font.
> You can also change the 'keyprotocol' option, e.g. make it empty, and
> see what effect that has.
Adding the argument
--cmd 'set keyprotocol='
or
-c 'set keyprotocol='
had no effect, whether set before or after bg&: the font on the
command line was always tiny.
So the correct solution is to set TERM=mintty. I'll do that and see
if anything else breaks, although I don't use that computer much for
my current work, so I won't notice anything for a while.
I would still like to know what that escape sequence is supposed to
do. If mintty's response seems to be a bug, then I'll report it to
the author.
Regards,
Gary
--
--
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/20221202224719.GC16317%40phoenix.
vim_dev@googlegroups.com
After updating to the latest Vim, 9.0.0984, and starting Vim in a terminal without a file specified, the command line font was extremely tiny. (I'd estimate the font size to be 4 points.) If a file was opened from the command line, its font in the buffer was also tiny. Subsequent commands typed in the command line were of the expected font. The font in the buffer remained tiny until ^L was typed. Bisecting my vimrc and my usual color scheme plugin revealed the command causing the tiny font to be :set bg& and bisecting the git commits showed the bad commit to be 733a69b29f0b0c3d2ddca463a41bdd912379bc5e, tag v9.0.0980. Steps to reproduce 1. vim -N -u NONE -i NONE --cmd 'set bg&' 2. Type a colon (:) and note that it is in a very tiny font. 3. Continue typing the ex command to edit some file, e.g., ":e feature.h". Note that the file is displayed in the buffer in the same tiny font. Expected behavior I expect Vim to use the same 11-pt font it normally uses, as set in the terminal's preferences. Version of Vim 9.0.0980 and 9.0.0984 Environment Operating system: Cygwin version 3.3.6-1 (latest as of 2022-12-01) on Windows 10 Pro version 22H2 Terminal: mintty version 3.6.2-1 (also latest as of 2022-12-01) Value of $TERM: xterm-256color Shell: bash version 4.4.12-3 Additional Context During the git bisect, each version of Vim was built with these commands: $ make distclean $ make No environment variables were set to affect the build. Regards, Gary -- -- 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/20221202021937.GB16317%40phoenix.
Re: [vim/vim] Incorrect indentation when pasting indented text from insert mode with `autoindent` enabled (Issue #11553)
On 2022-11-15, Melker Österberg wrote: > Steps to reproduce > > 1. > vim -u DEFAULTS -c "set autoindent" > > 2. Enter insert mode and paste the following with + (assuming that you > have copied it to your clipboard register) > > foo > bar > baz > > 3. Pasted text looks like this: > > foo > bar > baz > > If I disable autoindent, i.e. run vim -u DEFAULTS, the text gets pasted with > the correct indentation. > > Expected behaviour > > Text gets pasted like this: > > foo > bar > baz That is expected behavior. From ":help i_CTRL-R": The text is inserted as if you typed it, but mappings and abbreviations are not used. If you have options like 'textwidth', 'formatoptions', or 'autoindent' set, this will influence what will be inserted. This is different from what happens with the "p" command and pasting with the mouse. To get the behavior you want, use +. From ":help i_CTRL-R_CTRL-O": Insert the contents of a register literally and don't auto-indent. Does the same as pasting with the mouse ||. Regards, Gary -- -- 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/20221115172457.GA4274%40phoenix.
Re: [vim/vim] Enable new diff option linematch (PR #9661)
On 2022-11-07, Jonathon wrote: > This was recently merged to Neovim (neovim/neovim#14537). Are you interested > in > merging it to vim if I update this pull request? I'd be interested in trying it out. Regards, Gary -- -- 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/20221107184608.GB24291%40phoenix.
Re: [vim/vim] Fix shellcheck compiler for shell scripts (PR #11509)
On 2022-11-05, Balki wrote: > Problem: :compiler shellcheck does not work > Solution: Add ' %' to makeprg to pass current file to shellcheck The 'makeprg' set by compiler files generally does not include %. If the user wishes to make the current file, then they supply the % themselves. Regards, Gary -- -- 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/20221106044013.GA24291%40phoenix.
Re: [vim/vim] Question-mark or forward-slash truncates a search-string (Issue #11460)
On 2022-10-29, Gary Johnson wrote: > On 2022-10-29, Carl Ponder wrote: > > Based on this posting > > https://vim.fandom.com/wiki/Searching_for_expressions_which_include_slashes > > I tried re-mapping the '/' in my ~/.vimrc > > > > command! -nargs=1 / let @/ = |set hlsearch > > > > but it didn't work. > > That won't work because user-defined commands must begin with an > upper-case letter. See > > :help user-commands > > To remap a command such as /, you must use a mapping, such as this > example: > > :cnoremap eescape(getcmdline(), '/'):cunmap CR> > > See > > :help map-overview > :help x_CTRL-\_e > :help getcmdline() > :helpgrep \cctrl-\\.\?e > > and the mappings in the file > > $VIMRUNTIME/macros/less.vim > > That mapping is probably too simple, but it worked in the few test > cases I tried. I got so involved in the problem of mapping that I forgot about mapping /. Here's a better example, again just fleshed out to the point of working, but closer to a complete solution. :nnoremap / :call SlashEscape()/ :function SlashEscape() :cnoremap eescape(getcmdline(), '/'):cunmap CR> :endfunction Regards, Gary -- -- 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/20221030004548.GF14398%40phoenix.
Re: [vim/vim] Question-mark or forward-slash truncates a search-string (Issue #11460)
On 2022-10-29, Carl Ponder wrote: > Based on this posting > https://vim.fandom.com/wiki/Searching_for_expressions_which_include_slashes > I tried re-mapping the '/' in my ~/.vimrc > > command! -nargs=1 / let @/ = |set hlsearch > > but it didn't work. That won't work because user-defined commands must begin with an upper-case letter. See :help user-commands To remap a command such as /, you must use a mapping, such as this example: :cnoremap eescape(getcmdline(), '/'):cunmap CR> See :help map-overview :help x_CTRL-\_e :help getcmdline() :helpgrep \cctrl-\\.\?e and the mappings in the file $VIMRUNTIME/macros/less.vim That mapping is probably too simple, but it worked in the few test cases I tried. HTH, Gary -- -- 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/20221030002100.GE14398%40phoenix.
Re: [vim/vim] patch 9.0.0817 (fb0cf23)
On 2022-10-28, Bram Moolenaar wrote: > Strange that this went missing. I'll add it now, please suggest a git > command for more info on the commit if needed. I understand your frustration with git. Here are a couple of commands I use to examine commits. To see the commit messages in a pager, including the names of the affected files: $ git log --name-only --decorate To see side-by-side diffs of the changes between two commits, for example, between the commit with the tag v9.0.0805 and its predecessor: $ git difftool v9.0.0805^..v9.0.0805 You can specify any two commits by their tags, by their commit hashes, or by either of those with modifiers such as ^ to indicate a parent. The best way to fix a bad commit really depends on the situation and on what has been pushed. It's generally difficult to change anything already pushed. In my limited experience, the safest way to make a change is to create a new commit that contains the code the way you want it, including any reversions, and commit and push that. Anything fancier than that, that you don't understand well, can easily lead to mistakes and more frustration. HTH, Gary -- -- 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/20221028180428.GD14398%40phoenix.
Re: [vim/vim] Add first class support for json format (Issue #11426)
On 2022-10-22, Prabir Shrestha wrote: > JSON is a common format that is used when coding backend apis. Would be good > if > vim had first class support for formatting JSON so that we don't have to use > external tool or website. I don't use JSON a lot. What sort of formatting do you want that the existing json.vim or jsonc.vim indent plugin doesn't provide? Regards, Gary -- -- 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/2022102629.GC14398%40phoenix.
Problem with zG and spelloptions=camel
I was trying to add a word to the internal word list with zG. The status line indicated that the word was added, but it remained highlighted as a bad word. Steps to reproduce 1. $ cd ~/src/vim/vim # where latest clean build of Vim resides. 2. $ VIMRUNTIME=runtime vim -N -u NONE -i NONE -c 'set spell' 3. $ set spelloptions=camel 4. Add a line with these words: Hello AB1234YZ world. 5. Note that "AB1234YZ" is highlighted as a bad word. 6. Move the cursor to 'A'. 7. Type zG 8. Note that a message like the following is displayed in the command/status line. Word 'AB1234' added to /tmp/v9NFArp/0 9. Note also that that word remains highlighted as a bad word. 10. Move the cursor to the 'Y'. 11. Type zG 12. Note that a message like the following is displayed in the command/status line. Word 'YZ' added to /tmp/v9NFArp/0 13. Note also that 'YZ' is no longer highlighted as a bad word but 'AB1234' still is. Expected behavior I expect 'AB1234' to not be highlighted as a bad word. 'AB1234' is not highlighted as bad word if it appears in the text alone, but is highlighted when a some other word is appended, even a properly-spelled, capitalized word. Version of Vim 9.0.783 Environment Operating system: Ubuntu 20.04 Terminal: Xterm(370) Value of $TERM:xterm-256color Shell: bash Additional Context I don't know that this has ever worked. I didn't try earlier versions with the 'spelloptions' option. I just tried zG on a similar string--a processor part number--for the first time today. Regards, Gary -- -- 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/20221017184154.GL24999%40phoenix.
Re: Cscope regression at patch 9.0.0584
On 2022-10-13, Bram Moolenaar wrote: > I'm glad you could locate the source of the problem. Please try the > patch below. How could we make a regression test for this? I tested it in the cases that had failed before and they work fine now. Thank you. As for a regression test, I'll have to think about that and spend some time understanding test_cscope.vim. Regards, Gary -- -- 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/20221013151002.GK24999%40phoenix.
Re: Cscope regression at patch 9.0.0584
On 2022-10-12, Gary Johnson wrote:
> I started noticing odd behavior from cscope recently, so I ran 'git
> bisect' and found the problem at this commit:
>
> $ git bisect good
> dc21552c9a83413a018a91e61649cc632929d6a1 is the first bad commit
> commit dc21552c9a83413a018a91e61649cc632929d6a1
> Author: Bram Moolenaar
> Date: Sun Sep 25 17:03:26 2022 +0100
>
> patch 9.0.0584: cscope test with wrong executable name fails
>
> Problem:Cscope test with wrong executable name fails.
> Solution: Use /bin/sh to execute the command. (Yegappan Lakshmanan)
>
> src/if_cscope.c | 27 ---
> src/testdir/test_cscope.vim | 14 +-
> src/version.c | 2 ++
> 3 files changed, 23 insertions(+), 20 deletions(-)
I had a little time this evening, so I built 9.0.0584 and ran it
with gdb. I found a problem in cs_create_connection(), in
if_cscope.c. That function creates a command line to be executed,
but does so incorrectly, so when that command line is converted to
argc and argv[] for execvp(), the arguments are incorrect.
>From gdb, just before execvp() is to be called:
(gdb) p cmd
$6 = 0x55f932b0 "/bin/sh -c \"exec gtags-cscope -dl -f
/home/gary/src/vim/vim/GTAGS\" -P/home/gary/src/vim/vim -a"
(gdb) p *argv@5
$8 = {0x55cbb1c0 "/bin/sh", 0x55f8d420 "-c",
0x55f8dcb0 "exec gtags-cscope -dl -f /home/gary/src/vim/vim/GTAGS",
0x55f8ef60 "-P/home/gary/src/vim/vim", 0x55f93a40 "-a"}
The problem is that the quotes that close the exec command are
placed after the -f file name instead of at the end of the complete
command. That causes execvp() to get the exec argument as
exec gtags-cscope -dl -f /home/gary/src/vim/vim/GTAGS
followed by two more arguments,
-P/home/gary/src/vim/vim
-a
I haven't thought through the effect of that, but it doesn't seem
right. The fix should be pretty simple, but I have no more time to
work on it tonight.
Someone else can fix it if they wish, or I'll try fixing it
tomorrow.
Regards,
Gary
--
--
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/20221013074928.GJ24999%40phoenix.
Cscope regression at patch 9.0.0584
I started noticing odd behavior from cscope recently, so I ran 'git bisect' and found the problem at this commit: $ git bisect good dc21552c9a83413a018a91e61649cc632929d6a1 is the first bad commit commit dc21552c9a83413a018a91e61649cc632929d6a1 Author: Bram Moolenaar Date: Sun Sep 25 17:03:26 2022 +0100 patch 9.0.0584: cscope test with wrong executable name fails Problem:Cscope test with wrong executable name fails. Solution: Use /bin/sh to execute the command. (Yegappan Lakshmanan) src/if_cscope.c | 27 --- src/testdir/test_cscope.vim | 14 +- src/version.c | 2 ++ 3 files changed, 23 insertions(+), 20 deletions(-) I build a GNU Global database in a project's root directory, and then use that database with vim's :cscope commands to find references to symbols. I doesn't matter where I start vim in the project's directories because vim knows how to construct the full pathname to each target file. Since that commit, however, I've had to start vim in the project's root directory for the :cs find s " command to work. Otherwise, vim leaves out part of the path to the file. For example, I have my vim repo at ~/src/vim/vim, and that's where my GTAGS, etc., files are located. 1. $ cd ~/src/vim/vim 2. $ cd src 3. $ vim -N -u NONE 4. :set cscopeprg=gtags-cscope 5. :cs add /home/gary/src/vim/vim/GTAGS /home/gary/src/vim/vim -a 6. :set cscopequickfix=a-,c-,d-,e-,f0,g0,i-,s-,t- 7. :cs find s parse_printoptions Vim opens ~/src/vim/vim/hardcopy.c. Note that this should be ~/src/vim/vim/src/hardcopy.c--the "src/" component was omitted. This works properly if vim is started in the ~/src/vim/vim directory or is a version older than 9.0.0584. Version of Vim 9.0.658 but this been happening since patch 9.0.0584 Environment Operating system: Ubuntu 20.04 Terminal: XTerm(370) Value of $TERM:xterm-256color Shell: bash 5.0.17 GNU Global and gtags-cscope: 6.6.4 Regards, Gary -- -- 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/20221013014140.GI24999%40phoenix.
Re: gvim :sh ^U broken by patch 8.2.0851
On 2022-10-08, Bram Moolenaar wrote: > Gary Johnson wrote: > > > > > > I seldom use gvim on Linux and even less often use :sh from gvim, so > > > > > I didn't notice this until recently when projects and my workflow > > > > > changed. > > > > > > > > > > When :sh is used in gvim to launch a shell, the backspace and ^U no > > > > > longer work. Instead of backspacing or clearing the line, each just > > > > > puts gibberish in the line. I discovered that each was broken by > > > > > a different commit, so I'm reporting them separately. > > > > [...] > > > > > I still wonder why it took so long for someone to uncover this problem. > > > And what other things might still be wrong... > > > > Well, the arrow keys are kinda funky, too. Executing :sh and > > pressing the up-arrow, then Enter produces this, where the boxes are > > on one line and two characters wide. > > > > $ |00| |00| |00| k > > |9B| |9B| |9B| > > \udc9bku: command not found > > > > I tried looking at the arrow-key keycodes in gvim, but whether > > I prefixed the key with ^V or ^K, all I got was the key name, e.g., > > . > > > > The other arrow keys behave similarly. The characters on the > > command line look the same, but the last letter of the command that > > bash sees are different. > > > > Key Command > > --- > > up-arrow \udc9bku > > down-arrow \udc9bkd > > left-arrow \udc9bkl > > right-arrow \udc9bkr > > > > The shifted arrow keys give similar results but also appear > > differently on the command line. > > I believe it has always been like this. The $TERM in the shell is set > to "dumb", which means it doesn't support any special keys. > > There have been ideas to simulate a more clever terminal, perhaps vt52. > But using a terminal window is a much better alternative. That sounds reasonable. I just tried it in the two oldest gvims I have lying around and they behaved the same. I seldom use :sh in gvim, and then just for quick checks, so a dumb terminal is fine. Regards, Gary -- -- 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/20221008215508.GH24999%40phoenix.
Re: gvim :sh ^U broken by patch 8.2.0851
On 2022-10-04, Bram Moolenaar wrote: > Gary Johnson wrote: > > > > I seldom use gvim on Linux and even less often use :sh from gvim, so > > > I didn't notice this until recently when projects and my workflow > > > changed. > > > > > > When :sh is used in gvim to launch a shell, the backspace and ^U no > > > longer work. Instead of backspacing or clearing the line, each just > > > puts gibberish in the line. I discovered that each was broken by > > > a different commit, so I'm reporting them separately. [...] > I still wonder why it took so long for someone to uncover this problem. > And what other things might still be wrong... Well, the arrow keys are kinda funky, too. Executing :sh and pressing the up-arrow, then Enter produces this, where the boxes are on one line and two characters wide. $ |00| |00| |00| k |9B| |9B| |9B| \udc9bku: command not found I tried looking at the arrow-key keycodes in gvim, but whether I prefixed the key with ^V or ^K, all I got was the key name, e.g., . The other arrow keys behave similarly. The characters on the command line look the same, but the last letter of the command that bash sees are different. Key Command --- up-arrow \udc9bku down-arrow \udc9bkd left-arrow \udc9bkl right-arrow \udc9bkr The shifted arrow keys give similar results but also appear differently on the command line. Regards, Gary -- -- 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/20221008191439.GG24999%40phoenix.
Re: Patch 9.0.0655
On 2022-10-04, Bram Moolenaar wrote: > Patch 9.0.0655 > Problem:passing modifier codes to a shell running in the GUI. (Gary > Johnson) > Solution: Include modifier codes into the key and drop the modifiers. > Files: src/term.c, src/proto/term.pro, src/os_unix.c, src/os_win32.c Thank you again, for the patch and for fixing this and the other one so quickly. Regards, Gary -- -- 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/20221004172245.GE24999%40phoenix.
Re: gvim :sh ^U broken by patch 8.2.0851
On 2022-10-03, Gary Johnson wrote: > I seldom use gvim on Linux and even less often use :sh from gvim, so > I didn't notice this until recently when projects and my workflow > changed. > > When :sh is used in gvim to launch a shell, the backspace and ^U no > longer work. Instead of backspacing or clearing the line, each just > puts gibberish in the line. I discovered that each was broken by > a different commit, so I'm reporting them separately. > > Steps to reproduce > > 1. $ vim -g -N -u NONE -i NONE > 2. :sh > 3. Type a bunch of printing characters, it doesn't seem to matter > what. For example: > > $ hello > > 4. Type ^U (Ctrl-U). > 5. The line changes to something I can't reproduce here. It's > something like this: > > $ hello |00| |00| u > |9B| |9B| > > where the 'u' has an umlaut and each box occupies two spaces on > the one line. That line is immediately followed by these two > (so a newline must have been inserted, too): > > Uhello\udc9b\udcfc: command not found > $ U > > Hitting Enter at this point results in this: > > U: command not found > > Expected behavior > > The 'hello' should be erased and the cursor moved to the start > of the now-empty line. > > Version of Vim > > 9.0.651 > > Environment > > Operating system: Ubuntu 20.04.5 > Terminal: Not applicable, but gvim launched from an xterm > Value of $TERM: > In the original xterm: xterm-256color > In the :sh shell: dumb > Shell: bash > Desktop: xfce4 > Behavior is the same in GNOME on Ubuntu 22.04. > > Last output from 'git bisect': > > $ git bisect good > f4ae6b245a54f11dd967d06b80f30e5abf55fb82 is the first bad commit > commit f4ae6b245a54f11dd967d06b80f30e5abf55fb82 > Author: Bram Moolenaar > Date: Sat May 30 19:52:46 2020 +0200 > > patch 8.2.0851: can't distinguish from accented "a" in the GUI > > Problem:Can't distinguish from accented "a" in the GUI. > Solution: Use another way to make mapping work. (closes > #6163) > > src/getchar.c | 20 +++- > src/gui.c | 4 ++-- > src/gui_gtk_x11.c | 44 +--- > src/version.c | 2 ++ > 4 files changed, 28 insertions(+), 42 deletions(-) > > I should have mentioned this in my report of the backspace bug, but > at every 'git bisect' step, vim was build with these commands in an > environment that should not have affected the build (i.e., no > vim-affecting environment variables): > > $ make distclean > $ make -j6 So I did a little bit of poking at this with git and gdb and discovered that at patch v8.2.0851, a block of code was moved from gui_gtk_x11.c:keyval_to_string() to getchar.c:merge_modifyOtherKeys(). In a working version of the code, e.g. v8.2.0850, that block coverts the key code for ^U to the value of ^U. In a non-working version of the code, e.g. v8.2.0851, where that block has been moved, that block is not executed when the user types ^U in the shell, so the conversion is not done and shell receives something else. I don't understand the overall flow of keycode processing well enough to know where best to put that block, but it shouldn't have been moved from where it was. Maybe put it in both places, or create a small function to encapsulate that block and call it in both places? Regards, Gary -- -- 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/20221003235909.GD24999%40phoenix.
Re: Patch 9.0.0653
On 2022-10-03, Bram Moolenaar wrote: > Patch 9.0.0653 (after 8.2.0260) > Problem:BS and DEL do not work properly in an interacive shell. (Gary > Johnson) > Solution: Adjust the length for replaced codes. > Files: src/term.c, src/proto/term.pro, src/os_unix.c, src/os_win32.c Much better now! Thank you. Regards, Gary -- -- 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/2022100319.GC24999%40phoenix.
gvim :sh ^U broken by patch 8.2.0851
I seldom use gvim on Linux and even less often use :sh from gvim, so I didn't notice this until recently when projects and my workflow changed. When :sh is used in gvim to launch a shell, the backspace and ^U no longer work. Instead of backspacing or clearing the line, each just puts gibberish in the line. I discovered that each was broken by a different commit, so I'm reporting them separately. Steps to reproduce 1. $ vim -g -N -u NONE -i NONE 2. :sh 3. Type a bunch of printing characters, it doesn't seem to matter what. For example: $ hello 4. Type ^U (Ctrl-U). 5. The line changes to something I can't reproduce here. It's something like this: $ hello |00| |00| u |9B| |9B| where the 'u' has an umlaut and each box occupies two spaces on the one line. That line is immediately followed by these two (so a newline must have been inserted, too): Uhello\udc9b\udcfc: command not found $ U Hitting Enter at this point results in this: U: command not found Expected behavior The 'hello' should be erased and the cursor moved to the start of the now-empty line. Version of Vim 9.0.651 Environment Operating system: Ubuntu 20.04.5 Terminal: Not applicable, but gvim launched from an xterm Value of $TERM: In the original xterm: xterm-256color In the :sh shell: dumb Shell: bash Desktop: xfce4 Behavior is the same in GNOME on Ubuntu 22.04. Last output from 'git bisect': $ git bisect good f4ae6b245a54f11dd967d06b80f30e5abf55fb82 is the first bad commit commit f4ae6b245a54f11dd967d06b80f30e5abf55fb82 Author: Bram Moolenaar Date: Sat May 30 19:52:46 2020 +0200 patch 8.2.0851: can't distinguish from accented "a" in the GUI Problem:Can't distinguish from accented "a" in the GUI. Solution: Use another way to make mapping work. (closes #6163) src/getchar.c | 20 +++- src/gui.c | 4 ++-- src/gui_gtk_x11.c | 44 +--- src/version.c | 2 ++ 4 files changed, 28 insertions(+), 42 deletions(-) I should have mentioned this in my report of the backspace bug, but at every 'git bisect' step, vim was build with these commands in an environment that should not have affected the build (i.e., no vim-affecting environment variables): $ make distclean $ make -j6 Regards, Gary -- -- 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/20221003191005.GB24999%40phoenix.
gvim :sh backspace broken by patch 8.2.0260
I seldom use gvim on Linux and even less often use :sh from gvim, so I didn't notice this until recently when projects and my workflow changed. When :sh is used in gvim to launch a shell, the backspace and ^U no longer work. Instead of backspacing or clearing the line, each just puts gibberish in the line. I discovered that each was broken by a different commit, so I'm reporting them separately. Steps to reproduce 1. $ vim -g -N -u NONE -i NONE 2. :sh 3. Type a bunch of printing characters, it doesn't seem to matter what. For example: $ hello 4. Type the backspace key. 5. The 'o' is replaced by a 'b' and the cursor remains at the end of the line. Expected behavior The cursor should move one space to the left, erasing the 'o'. Version of Vim 9.0.651 Environment Operating system: Ubuntu 20.04.5 Terminal: Not applicable, but gvim launched from an xterm Value of $TERM: In the original xterm: xterm-256color In the :sh shell: dumb Shell: bash Desktop: xfce4 Behavior is the same in GNOME on Ubuntu 22.04. Last output from 'git bisect': $ git bisect bad f4140488c72cad4dbf5449dba099cfa7de7bbb22 is the first bad commit commit f4140488c72cad4dbf5449dba099cfa7de7bbb22 Author: Bram Moolenaar Date: Sat Feb 15 23:06:45 2020 +0100 patch 8.2.0260: several lines of code are duplicated Problem:Several lines of code are duplicated. Solution: Move duplicated code to a function. (Yegappan Lakshmanan, closes #5330) src/option.c | 136 - src/os_unix.c | 24 +- src/os_win32.c | 25 +- src/proto/term.pro | 1 + src/quickfix.c | 24 +++--- src/regexp.c | 22 + src/regexp_bt.c| 12 + src/regexp_nfa.c | 12 + src/term.c | 31 src/version.c | 2 + 10 files changed, 128 insertions(+), 161 deletions(-) Regards, Gary -- -- 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/20221003183643.GA24999%40phoenix.
Re: [vim/vim] Cannot use ctrl+x to cut using mswin.vim (Issue #10965)
On 2022-08-23, Ahnaf Al Nafis wrote: > You mswin cannot be activated by default in Linux. Why do you think that? The OP explicitly sourced $VIMRUNTIME/mswin.vim in their vimrc. When I source that file in gvim on my Ubuntu 20.04 system, Ctrl-A, Ctrl-C and Ctrl-V behave as they would on Windows. Regards, Gary -- -- 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/20220823154345.GE6741%40phoenix.
Re: merge/diff (Re: List of Vim features to vote on)
On 2022-08-18, Ernie Rael wrote: > On the voting page I see: > >5 92 improve diff mode: automatic refresh, better merge support >... >11 72 add diff/merge capability for git, mercurial et al. > > I don't understand the intent of item 11. For example, there's the > plugin > > https://docs.stevelosh.com/splice.vim/ > > Which is full featured. (It's a vimL/python hybrid); there's > instructions for using it from git, mercurial and bazaar; there's a > demo screencast. I think it has some great features; I'm far from > expert on merging and/or merge tools; so who knows. Splice hasn't been > touched in around 10 years. > > I'm wondering if there's a need for item 11 since plugins can do it, > perhaps Splice could be released with vim if an out of the box merge > tool is wanted. There is also Fugitive, and I've written my own that's a small enhancement to git's vimdiff merge tool. I agree. Vim should offer features and interfaces that allow it to be a powerful diff engine and display for users directly and from plugins, but it shouldn't know anything about any particular VCS. Plugins should handle the interfaces to and idiosyncrasies of the VCSs. Regards, Gary -- -- 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/20220819031836.GD6741%40phoenix.
Re: [vim/vim] git mergetool use vimdiff, vimrc &diff is 0 (Issue #10934)
On 2022-08-17, aohan237 wrote: > @chrisbra maybe the way git mergetool use vimdiff cause this. > > @vim-ml 's cmd solution goes right. maybe i should ask git for an answer, > there > is no doc on this feature I don't know whether you saw my earlier, lengthy reply to Chris, but that answered the question of _what_ changed in git. The URL that Chris posted explains a little of the _why_, but not all. It just said that they made the mergetool better, but it didn't explain how the new way was better. What the git developers did was to change the mergetool command that diffs the various versions of the file being merged. They used to start the command with "vim -f -d ...", which started vim in diff mode so that &diff was 1 when vimrc was sourced. They changed the command to start with "vim -f -c 'echo | ..." and somewhere in that command they execute diffthis in a loop. Consequently, that command does not put vim into diff mode when it starts and vimrc is sourced when &diff is 0. It is not clear at all to me why someone thought the new mergetool command was in some way better than the old one. The problem is solely due to the change made in git. I thought that the mergetool command was documented somewhere in the git documentation, but I haven't looked for it in a long while. You _might_ find some explanation for the change in the git mailing list archives or in the git log of the git repository, but not all developers explain their reasoning very well. The git mailing list would be the place to ask about this. Regards, Gary -- -- 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/20220818050631.GC6741%40phoenix.
Re: [vim/vim] git mergetool use vimdiff, vimrc &diff is 0 (Issue #10934)
On 2022-08-17, Christian Brabandt wrote: > I wonder, if this is caused by the recent changes in git release 2.37 on how > vimdiff is called https://github.com/git/git/blob/v2.37.0/Documentation/ > RelNotes/2.37.0.txt I wonder. I'm still running git 2.26.2. If, from the Vim instance running the merge, I execute this: :!ps -fH I see this: UID PIDPPID C STIME TTY TIME CMD gary 109235 109234 0 10:16 pts/900:00:00 bash gary 109430 109235 0 10:18 pts/900:00:00 git mergetool gary 109431 109430 0 10:18 pts/900:00:00 /bin/sh /usr/lib/git-core/git-mergetool gary 109489 109431 0 10:18 pts/900:00:00 /bin/sh /usr/lib/git-core/git-mergetool gary 109490 109489 0 10:18 pts/900:00:00 vim -d -c 4wincmd w | wincmd J | wincmd = ./mary_LOCAL_109431.txt ./mary_BASE_109431.txt ./mary_REMOTE_109431.txt mary.txt gary 109535 109490 0 10:20 pts/900:00:00 ps -fH I wonder what the OP sees on their Mac. I _think_ a Mac has ps. OK, I tried another experiment. I have Cygwin running on a Windows 10 PC and it has git 2.37.1 and Vim 9.0. I set up the same experiment as on my Ubuntu system, but stripped the ~/.gitconfig file down to its essentials so that it would use the default mergetool. When I did that and ran the following: $ git mergetool :sh $ COLUMNS=512 ps -fH I saw this: UIDPID PPID C STIME TTY TIME CMD gjohn 1507 1506 0 10:27 pty0 00:00:00 -bash gjohn 1857 1507 0 10:41 pty0 00:00:00 git mergetool gjohn 1858 1857 0 10:41 pty0 00:00:00 /bin/sh /usr/libexec/git-core/git-mergetool gjohn 2070 1858 0 10:41 pty0 00:00:01 vim -f -c echo | split | vertical split | 1b | wincmd l | vertical split | 2b | wincmd l | 3b | wincmd j | 4b | tabdo windo diffthis -c tabfirst ./mary_LOCAL_1858.txt ./mary_BASE_1858.txt ./mary_REMOTE_1858.txt mary.txt gjohn 2076 2070 0 10:43 pty0 00:00:00 /bin/bash gjohn 2129 2076 0 10:48 pty0 00:00:00 /bin/bash gjohn 2128 2076 0 10:48 pty0 00:00:00 procps -fH Sure enough, the new git mergetool using vimdiff does not start vim in diff mode. Good find, Chris. So I guess the OP can either define mergetool in their ~/.gitconfig to something more like mine or like the old git default, or figure out how to get the information they want from the new mergetool command. Regards, Gary -- -- 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/20220817175854.GB6741%40phoenix.
Re: [vim/vim] git mergetool use vimdiff, vimrc &diff is 0 (Issue #10934)
On 2022-08-17, Christian Brabandt wrote: > most likely, diff mode is enabled after the vim has completely started up (and > after .vimrc) is read. Run it interactively using :echo &diff or in a VimEnter > autocommand. I don't think this is a bug here. Something funny is going on, though. When I try that experiment on my Ubuntu 20.04 system with Vim 9.0, &diff is 1. I've had one or more tests of "if &diff" in my vimrc for years and they have always worked as expected. Here is the mergetool section of my ~/.gitconfig, for what it's worth. [merge] tool = vimdiff trustExitCode = true conflictStyle = diff3 [mergetool "vimdiff"] cmd = "vim -d -c '4wincmd w | wincmd J | wincmd =' $LOCAL $BASE $REMOTE $MERGED" Maybe there's something different about some of this on a Mac. Regards, Gary -- -- 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/20220817160918.GA6741%40phoenix.
Re: [RFC] improvements to :tselect and :tjump
On 2022-08-11, Brandon Richardson wrote: > Hello all, > > I've been prototyping some alternative commands to :tselect and :tjump and I'm > looking to get a bit of feedback from the community on whether this > functionality is something worth introducing into the core project. This > functionality originally started it's life as small plugin in my dotfiles and > I've grown to really enjoy the experience it provides. I figured that the > community could benefit, so I've been working to implement it as a core > feature > in vim. > > When there are multiple tag matches for a particular keyword, :tag and CTRL-] > both jump to the first match by default. Alternatively, :tselect and :tjump > can > be used to select which match to jump to by showing a message and prompting > for > input. > > I'd like to propose two new commands, :pwtselect and :pwtjump and perhaps a > new > key mapping that displays the tag matches in a popup window at the cursor > position. The user may then select which tag to jump to. It would look and > feel > very similar to the completion popup features, and it leverages much of the > existing foundation for :tselect and friends. > > Each entry in the popup window could have the format "[] > ". We could also include "info" fields and the the line from the file > (massaged from the "cmd" field like in the current implementation of :tselect > and friends). > > If this is something the community deems worth pursuing, I'll continue > pressing > forward on my patch series. I'd love to hear people's thoughts and opinions. There is a plugin that implements some of what you are proposing, tagselect.vim, "Provides a better :tselect command," by Hari Krishna Dara. It was last updated on June 9, 2005. https://www.vim.org/scripts/script.php?script_id=1282 It provides the same display of tag information as :tselect and related commands do, but in an easier-to-use menu. I have Ctrl-] mapped to the :Tjump command. It could use some updating. I think what you propose is a good idea. I'm not sure that it needs to be incorporated into Vim if it works well as a plugin. That is, if it's not missing some functionality or performance that it would have if made part of Vim, then it's probably better to leave it as a plugin. For one thing, a plugin is easier to modify, so it is a better medium for proposing new functionality than changes to core Vim. If the functionality was to be added to Vim, I don't think there is a need for more commands. I think users will prefer either your interface or the original, but will probably not switch between the two. Therefore, I would propose an option that let the user choose between interfaces, perhaps with choices of legacy, Hari's style with the menu in a split window, and your style with the menu in a pop-up window. On the other hand, having an option that changes the behavior of an existing command could break plugins that use :tselect and related commands. So maybe it would be better to have new functions that the user can map, although that's not as convenient. My rambling $0.02. Regards, Gary -- -- 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/20220812042701.GM12539%40phoenix.
Re: [vim/vim] remove misleading :3mat from the documentation (PR #10691)
On 2022-07-10, haron13-2019 wrote: > When skimming over documentation it is easy to erroneously believe one can use > ":3mat" command - see my recent bug report #10690 instantly closed by > @chrisbra > > > Thinking about it a bit, may be this is good idea to officially remove ":3mat" > from the documentation. For normal use cases it is anyway not (really) > available, it can be only used (as far as I understood) only in some exotic > circumstances - for example that standard matchit plugin is deactivated? > > Another "improvement" - documentation encourages plugin authors to use > ":2mat". > Is it not better to leave ":mat" and ":2mat" for interactive usage entirely > and > ask plugin authors to use matchadd() call directly? I think your change goes too far. The :3match command _does_ exist and it _can_ be used. In fact, it _is_ used, by the matchparen plugin. I don't think that hiding it or pretending that it doesn't exist benefits the user. I certainly would not remove the mentions of the matchparen plugin. For example, matcharg(3) returns a different result than matcharg(4) and :3match will work while :4match will fail. This could be confusing to the user without an discoverable explanation. The semi-reserved status of match ID 3 should be mentioned in a few more places, such as ":help matchadd()", but I would not remove any of the existing documentation on it. Regards, Gary -- -- 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/20220710225006.GF12539%40phoenix.
diff anomalies with multiple tabs
I'm not sure this is bug, but it's not what I expect and I don't know of a workaround. I often use the Fugitive command ":Git difftool -y" to open a set of tabs, each one containing a diff of the working tree version of a file with some other version of that file. I sometimes use a command such as CTRL-W_], :scscope or :new to open another window to look at other uses or the definition of some variable. If any of those commands opens a new buffer, that window and its new buffer are not included in the diff. However, if any of those commands opens an already-open buffer from another tab, and that buffer was included in a diff in that tab, then the new window and that existing buffer are added to the diff in the current tab. Since the new window and its buffer are usually unrelated to the windows and their buffers already in the current tab, the display becomes a mess of change highlighting. Also, the new window is scrollbound and cursorbound to the other windows, so scrolling around in it drags the other windows along. Further, closing the new window does not remove its buffer from the diff set, leaving the highlighting mess. It seems to me that since diff options are window-local and not buffer-local, the fact that a buffer is included in a diff in one tab should not follow it when it is opened in a different tab. Steps to reproduce 1. Create a set of four files, a, b, c and d, such that a and b have slight differences, c and d have slight differences, but a and b are very different from c and d. The files I used are attached. 2. Start vim: $ vim -N -u NONE -i NONE 3. Execute the following. :e b :vert diffsplit a :tabnew d :vert diffsplit c :wincmd w 4. Open some unrelated file in a new window, e.g., :new ~/.vim/vimrc 5. Browse around that file and note that the other windows are not affected. 6. Close that window: :close 7. Open one of the files already open in the other tab: :new b 8. Note that the highlighting of all the lines in all the windows in the current tab has changed to DiffAdd, DiffChange or DiffDelete. 9. Close this window: :close 10. Note that the highlighting of the two original windows remains affected by the now-closed window. Executing :diffoff in the new window will fix the problem temporarily, but it comes back as soon as another existing, diffed buffer is opened in that window. Expected behavior I expect a buffer opened in a new window to not be part of the diff of other windows in that tab, regardless of whether it is already open in some other tab and whether a window in which it is open in that other tab is part of a diff. Version of Vim 9.0.0 Environment Operating system: Ubuntu 20.04 Terminal: XTerm(370) Value of $TERM:xterm-256color Shell: bash Regards, Gary -- -- 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/20220629001636.GC12539%40phoenix. Mary had a little lamb, Its fleece was white at snow, And everywhere that Mary went, The lamb was sure to go. Mary had a little goat, Its fleece was white at snow, And everywhere that Mary went, The goat was sure to go. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam luctus lectus sodales, dictum augue vel, molestie augue. Duis sit amet rhoncus justo. Nullam posuere risus semper magna commodo scelerisque. Duis et venenatis sem. In rhoncus augue sed tempor mattis. Mauris id aliquet odio. Sed eget est aliquam, pulvinar enim elementum, ultricies lorem. Integer egestas dui dui, nec viverra felis semper a. Mauris sed sodales est. Nulla ultrices nulla vitae sem convallis, ut tincidunt enim fermentum. Pellentesque nulla nisi, pellentesque a augue sit amet, vulputate ornare massa. Phasellus ultrices vitae augue vitae faucibus. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam luctus lectus sodales, dictum augue vel, molestie augue. Duis sit amet rhoncus justo. Nullam posuere risus semper minima commodo scelerisque. Duis et venenatis sem. In rhoncus augue sed tempor mattis. Mauris id aliquet odio. Sed eget est aliquam, pulvinar enim elementum, ultricies lorem. Float egestas dui dui, nec viverra felis semper a. Mauris sed sodales est. Nulla ultrices nulla vitae sem convallis, ut tincidunt enim fermentum. Pellentesque nulla nisi, pellentesque a augue sit amet, vulputate ornare massa. Phasellus ultrices vitae augue vitae faucibus.
Re: Diff loses sync
On 2022-06-24, Bram Moolenaar wrote: > Gary Johnson wrote: > > > I've noticed for a while when diffing two versions of a file that > > the two windows sometimes get out of sync. I created and attached > > two files that exhibit this problem. For this example, I ran vim > > version 8.2.5154 in an 80x24 xterm. > > > > Steps to reproduce [...] > Thanks for providing a good repro case. The window height also matters, > it must not have too many lines. > > I'll fix it. Please check for any places that then might fail, the > rules about 'scrollbind' and 'cursorbind' are tricky. Thank you. The new version worked great on the files I was working on when I reported the problem. I'll continue to watch for any other issues. Regards, Gary -- -- 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/20220624164146.GB12539%40phoenix.
Diff loses sync
I've noticed for a while when diffing two versions of a file that the two windows sometimes get out of sync. I created and attached two files that exhibit this problem. For this example, I ran vim version 8.2.5154 in an 80x24 xterm. Steps to reproduce 1. Save the attached files to disk. 2. Start vim as $ vimdiff -N -u NONE -i NONE demo_left demo_right The display initially looks fine. 3. Move the cursor to the right window: 4. Move the cursor down five lines: j Note that when the cursor reaches the fifth line 6, containing "Lorem", the left window scrolls to display common block one in roughly the center while the right window remains unchanged, like this. (I removed eight columns from each window to make it fit in the width of a standard email page.) --| line 1 --| line 2 --| line 3 --| line 4 --| --| Lorem --| ipsum --| dolor --| sit --| amet, // Common block | consectetur // one| adipiscing // containing | elit. // four lines | Etiam | luctus --| lectus --| sodales, --| dictum --| augue --| vel, --| molestie --| augue. demo_left 6,185% demo_right 6,1Top 5. Move the cursor down to the bottom of the window and one line more. The right window scrolls one line as expected and the left window scrolls to align itself properly with the right window. 6. Use the j key to move further down in the right buffer and more odd things happen, as when the cursor moves to line 39, containing "Vestibulum". The left window scrolls to show the last 3 lines of common block one at the top and the first line of common block two at the bottom. Expected behavior I expect the left window to remain in sync with the right window, displaying common buffer lines on the same screen line. Version of Vim 8.2.5154 Environment Operating system: Ubuntu 20.04 Terminal: XTerm(370) Value of $TERM: xterm-256color Shell: bash 5.0.17(1)-release Regards, Gary -- -- 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/20220624013606.GA12539%40phoenix. line 1 line 2 line 3 line 4 // Common block // one // containing // four lines // Common block // two // containing // four lines line 1 line 2 line 3 line 4 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam luctus lectus sodales, dictum augue vel, molestie augue. Duis sit amet rhoncus justo. Nullam posuere risus semper magna // Common block // one // containing // four lines Vestibulum tincidunt aliquam ipsum id venenatis. Nam nec sollicitudin justo. Vestibulum id consequat arcu, a aliquet nulla. // Common block // two // containing // four lines
Re: [vim/vim] EOL whitespace highlight (Issue #10516)
On 2022-06-03, Clément Bœsch wrote: >>One person's magic incantation is another person's flexible >>solution. >> >>I tried such a solution for a while, and also tried Dan Church's >>shitespace.vim plugin, but neither did quite what I wanted, so >>I wrote my own plugin so that I could enable/disable such >>highlighting automatically per file type and per project and >>manually per window. >> >>The "right" solution varies from user to user. Vim provides tools >>that allow each user to have the behavior they want. > > I wouldn't explain the need for users to write such vimscript plugins to be > driven by the enjoyment of the flexibility of vim. I'd rather say that many > people are desperate and ends up writing and copy/pasting abominations from > the > web to circumvent the limitations of their editor. Yeah, but it's difficult to find an out-of-the-box configuration that's going to please everyone. Witness the controversy surrounding the defaults.vim file. >>> I'm not sure about which solution to pick between adding the >>> ability to set color codes in listchars, adding a global option or >>> something else. But the quoted blob is not exactly a solution for >>> most users. >> >>The _space_errors solution seems to be the easiest and is >>commonly, though not widely, used. If your favored language doesn't >>have that, propose or submit a patch. > > I never came across a filetype where I didn't want the trailing whitespace to > be shown as error, including a lot of unrecognized file types from vim, as > well > as a simple scratchpad. I'm not saying it doesn't exist, but it feels like the > exception. Do you have an example? - Some Vim help files (filetype help) - The calendar from the calendar.vim plugin (filetype calendar) - Some buffers created by the Fugitive plugin (filetype git) - Some quickfix error lists (filetype qf) I'm not going to fix those and the highlighting I use is jarring, so I disable the trailing whitespace highlighting for those filetypes. >>It's easy to visualize having Vim's highlighting "just work" for >>you, but it's trickier to achieve. From my experience, you would >>not be happy with a global setting; there are too many files whose >>EOL spaces you'd like to ignore while not ignoring those in the >>file(s) you're working on. > > Oh I'm not insisting on having a global setting. I was actually pretty seduced > by the proposition from @bfredl to add a dedicated highlight. Taking into > account what you said about language specificities, it brings the question > whether this default highlight could be overwritten by some syntax file, where > the trailing whitespace could be considered normal. That would be nice. I don't know whether it could be overridden with filetype resolution. I've actually been using matchadd() and matchdelete() to control that highlighting because I also want those spaces highlighted in files for which I don't want syntax highlighting enabled. Regards, Gary -- -- 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/20220603185845.GC23469%40phoenix.
Re: [vim/vim] EOL whitespace highlight (Issue #10516)
On 2022-06-03, Clément Bœsch wrote: > If we want to highlight EOL whitespaces, we currently have to rely > on magic incantations such as: > > highlight WhitespaceEOL ctermbg=red > match WhitespaceEOL /\\\@ augroup winenter_whitespaceeol > autocmd! > autocmd WinEnter * match WhiteSpaceEOL /\\\@ augroup END One person's magic incantation is another person's flexible solution. I tried such a solution for a while, and also tried Dan Church's shitespace.vim plugin, but neither did quite what I wanted, so I wrote my own plugin so that I could enable/disable such highlighting automatically per file type and per project and manually per window. The "right" solution varies from user to user. Vim provides tools that allow each user to have the behavior they want. > In C, there is c_space_errors setting that helps but it's C only > so it has a very limited use. c_space_errors is not just for C. If you grep $VIMRUNTIME/syntax for c_space_errors, you'll find it used by 8 file types. Further, grepping for just _space_errors will show that technique, with prefixes other than "c", used by another 13 file types. > I'm not sure about which solution to pick between adding the > ability to set color codes in listchars, adding a global option or > something else. But the quoted blob is not exactly a solution for > most users. The _space_errors solution seems to be the easiest and is commonly, though not widely, used. If your favored language doesn't have that, propose or submit a patch. It's easy to visualize having Vim's highlighting "just work" for you, but it's trickier to achieve. From my experience, you would not be happy with a global setting; there are too many files whose EOL spaces you'd like to ignore while not ignoring those in the file(s) you're working on. > As requested by the neovim project, this issue is a duplicate of > neovim/neovim# 18843. At the time of writing, a global option > solution seems rejected there while the other approaches are still > considered. There are reasons why they're still considering various approaches-- there probably isn't one that's going to make everyone happy. Regards, Gary -- -- 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/20220603161355.GB23469%40phoenix.
Re: [vim/vim] Write permissions seem to be determined by Unix permissions (Issue #10501)
On 2022-05-30, kaymvoit wrote: > Steps to reproduce > > This was observed in a SpectrumScale storage with CentOS. > Vim warns of a read only file, for a file with mode despite GPFS ACL via > NFSv4 ACLs grants full access. > > 1. Create file with mode > 2. Grand full access via (NFSv4) ACL > 3. Open file and read warning about readonly file > 4. Try to save, encounter E45: 'readonly' optin is set > 5. Override with !, save successfully > > (This came up due to the fact that the storage does not seem to set Unix > permission on files that inherited permissions when they were created via > CIFS, > but only ACLs). > > Expected behaviour > > Vim determines actual status of writability. > > Python's f.writeable() is able to determine the status correctly, so I assume > the information is more or less trivially there. > > Version of Vim > > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2020 16:13:17) Included > patches: 1-207, 209-629 > > Environment > > CentOS Linux release 7.9.2009 (Core) > TERM=xterm-256color > zsh 5.0.2 (x86_64-redhat-linux-gnu) > > Logs and stack traces > > No response > My very limited understanding of ACLs and Linux file permissions is that together they set an upper limit on file access. That is, a user's access is determined by the maximum granted by the two mechanisms. So, if a file has mode , nobody has permission to read, write or execute it, regardless of the ACL. Here is a citation from one reference: POSIX Access Control Lists on Linux https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html Therefore, the meaning of the group class permissions is redefined: under their new semantics, they represent an upper bound of the permissions that any entry in the group class will grant. Regards, Gary -- -- 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/20220530180921.GA23469%40phoenix.
Re: [vim/vim] formatoptions+=r continues a // comment that isn't at the start of the line (Issue #10006)
On 2022-05-22, Terry Greeniaus wrote:
> If I came across as confrontational I apologize. I am comforted to
> know that I will only have to keep my .vimrc up to date rather
> than carry around other files with me as well.
> @vim-ml, I find it odd to say it's a fix when the behaviour for as
> long as I have used vim (only around 16 years, granted, and vim is
> much older) has been to not auto-indent a line following
> a trailing comment.
I know, and it's been really irritating to have to jump through
hoops to get a properly-formatted comment, especially when editing
it to add or remove text from the first line, when Vim should just
know how to do that. And it does now.
> Also, I think you are confusing style guidelines ("Both the Linux
> kernel and Vim use multi-line end-of-line comments.") with
> actually entering code with an editor. If a comment must continue
> on the next line, then I agree that it should be indented and
> while I am entering such a comment if I hit the rightmost margin
> it would be ideal for the text editor to break the comment up into
> a new line with the automatic indent. Perhaps there is a setting
> to do that in vim; for me it just allows the line to continue past
> the width of my terminal so I need to manually break it after
> completing the over-long line.
I think that's a consequence of the behavior of the 't' and/or 'c'
flags. I'm sorry, I can't find where that's documented. It seems
that if the cursor is to the left of 'textwidth' when you begin
inserting text, text you add will automatically wrap. However, if
you begin inserting to the right of 'textwidth', or you begin to the
left of 'textwidth' and your inserted text does not cross
'textwidth' then the line will not be reformatted even if the total
length exceeds 'textwidth'.
> When I do have such a comment that extends past the rightmost
> margin and I manually break the line in the middle of the comment,
> this version of vim does auto-indent it for me which is ideal. So,
> yay! I did not test an older version of vim to see if this is new
> behaviour.
If I understand you correctly, this is the new behavior, the
behavior you're not happy with.
> However, and this is the big one: if I am typing a trailing
> comment, and I have not hit the rightmost margin (perhaps I'm
> nowhere even near it) and I manually hit Enter to put in a line
> break, it should absolutely never ever ever auto-indent it.
That's what the 'r' flag is for.
r Automatically insert the current comment leader after
hitting in Insert mode.
If you don't want that, then you will have to put
setlocal fo-=r
in an after/ftplugin/c.vim, because Vim sets it in
$VIMRUNTIME/ftplugin/c.vim.
> And yes, we can come up with an idea of how often this happens.
> Using the Linux kernel as an example, I ran the following script
> against commit ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e (which is
> where my HEAD happened to be and is not the current kernel HEAD):
[script omitted]
> The script searches for trailing double-slash comments, counts how
> many of them it finds and then counts how many times the next
> line(s) are whitespace-delimited comments at any indent. It makes
> no attempt to see if the followon line's indent actually matches
> the initial trailing comment's indent, so this is an upper bound
> on how many followon lines in the kernel could have benefited from
> an auto-indent.
[...]
> And here is the result on the Linux kernel (note that xargs splits
> up invocations so that there are no more than 5000 arguments
> passed to the script at a time which is why we get the results
> multiple times):
>
> % find linux/ -name "*.c" | xargs python3 comment_counter.py
> Trailing comments: 718
> Followon comments: 0
> Trailing comments: 1798
> Followon comments: 68
> Trailing comments: 1025
> Followon comments: 4
> Trailing comments: 889
> Followon comments: 5
> Trailing comments: 1264
> Followon comments: 13
> Trailing comments: 1285
> Followon comments: 19
> Trailing comments: 1148
> Followon comments: 3
> % find linux/ -name "*.h" | xargs python3 comment_counter.py
> Trailing comments: 11752
> Followon comments: 166
> Trailing comments: 7451
> Followon comments: 226
> Trailing comments: 538
> Followon comments: 8
> Trailing comments: 633
> Followon comments: 1
> Trailing comments: 634
> Followon comments: 46
>
> And finally, I tabulate the results:
>
> Total trailing comments: 29135
> Total followon comments: 559
> Percentage of time hitting should auto-indent:
> 1.9186545392140038%
> Percentage of time hitting should not auto-indent: 98.081345460786%
>
> I claim a >98% rate where the line following a trailing comment in
> the Linux kernel should not be indented is consistent with
> "practically nobody ever wants this behaviour". I also withdraw my
> baseless statistic that 3 people out of 15 million actually desire
> this behaviour since obviously that is completed unsubstantiated
> and not helpful to the discussi
