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

and composing characters in Insert mode with 'delcombine' on : Bug or feature ?

elcombine' is on? And in the second case, shouldn't the fact that actually goes backward in the buffer (removing the composing character first and the spacing character afterwards) be documented somewhere (either under ":h i_" or –maybe preferably– by mentioning under ":h 'delcombine'"

Re: bug(?): Unicode Symbol as half-width in CJK

> In CJK, this bug is very old, but it has not been fixed yet. I believed > someone would be interested in it and solve it, but until now I'm inquiring > here because no one seems to be interested. > > As far as I know, in text editors like vim Only fixed-width fonts are > availab

Re: bug(?): Unicode Symbol as half-width in CJK

On Mon, Dec 18, 2023 at 12:28:24PM +0100, Christian Brabandt wrote: > I am not using a gui based mail client, that does not help me. Eric -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your

Re: bug(?): Unicode Symbol as half-width in CJK

On Mo, 18 Dez 2023, Korean user1 (in CJK) wrote: > vim-cmd-cjk-symbol-halfwidth-bug-1.gif Thanks, Christian -- "I don't think so," said Ren' e Descartes. Just then, he vanished. -- -- You received this message from the "vim_dev" maillist. Do not top-post

Re: bug(?): Unicode Symbol as half-width in CJK

That patch seem to do something different, e.g. simply adding horizontal whitespace between gui cells on Windows (only). I don't see how this is related to displaying half-width chars. Thanks, Chris Thanks, Christian -- Information Center, n.: A room staffed by professional computer

Re: bug(?): Unicode Symbol as half-width in CJK

in the patch folder, but I think the part I > pointed out as a bug is related to the 2003-charspace.diff file. > I tested it on the vim of Kaoriya and attached 2 gif files. > > vim-kaoriya-fork-display-unicode-symbol-1.gif > vim-kaoriya-fork-display-unicode-symbol-2.gif I am not u

Re: bug(?): Unicode Symbol as half-width in CJK

tware/vim/ > http://vim-jp.org/redirects/koron/vim-kaoriya/latest/win64/ > (vim82-kaoriya-win64-8.2.1287-20200724.zip) > > There are several diff files in the patch folder, but I think the part I > pointed out as a bug is related to the 2003-charspace.diff file. > I tested it on

Re: bug(?): Unicode Symbol as half-width in CJK

Tested in vim version 9.0.2173. 2023년 12월 18일 월요일 오전 10시 15분 54초 UTC+9에 Tony Mechelynck님이 작성: > On Mon, Dec 18, 2023 at 2:01 AM Korean user1 (in CJK) > wrote: > >> In CJK, this bug is very old, but it has not been fixed yet. I believed >> someone would be inter

Re: bug(?): Unicode Symbol as half-width in CJK

On So, 17 Dez 2023, Korean user1 (in CJK) wrote: > In CJK, this bug is very old, but it has not been fixed yet. I believed > someone would be interested in it and solve it, but until now I'm inquiring > here because no one seems to be interested. > > As far as I know, in text e

Commit: patch 9.0.1928: Vim9: constructor type checking bug

patch 9.0.1928: Vim9: constructor type checking bug Commit: https://github.com/vim/vim/commit/b895b0fabce7d952a6617eb69fc1e1597ece8b00 Author: h-east Date: Sun Sep 24 15:46:31 2023 +0200 patch 9.0.1928: Vim9: constructor type checking bug Problem: Vim9: constructor type

Re: [vim/vim] [vim9script] Regression after fixing constructor argument type checking bug (Issue #13102)

Hi, On Sat, Sep 16, 2023 at 1:30 AM Lifepillar wrote: > Steps to reproduce > > Patch 9.0.1724 (“vim9class constructor argument type checking bug”) has > introduced a regression in one of my Vim 9 libraries. I have a test suite > that caught that > <https://github.com/life

patch 9.0.1724: vim9class constructor argument type checking bug

patch 9.0.1724: vim9class constructor argument type checking bug Commit: https://github.com/vim/vim/commit/2261c89a49ff2115e1ccc9ab9211e9f0d5a37578 Author: h-east Date: Wed Aug 16 21:49:54 2023 +0900 patch 9.0.1724: vim9class constructor argument type checking bug Problem

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

Re: Bug in :vmap

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

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

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

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.

Re: 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

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

Re: Bug in Vim window height calculation with 'winfixheight'

Yegappan Lakshmanan wrote: > > > I see the following problem with the 'winfixheight' option. > > > > > > 1. Open two vertically split windows > > > > > > :vsplit > > > > > > 2. Open a horizontally split window with the 'winfixheight' option: > > > > > > :botright 5new

Re: Bug in Vim window height calculation with 'winfixheight'

Hi Bram, On Fri, Jul 23, 2010 at 11:17 AM Bram Moolenaar wrote: > > > Yegappan Lakshmanan wrote: > > > I see the following problem with the 'winfixheight' option. > > > > 1. Open two vertically split windows > > > > :vsplit > > > > 2. Open a horizontally split window with the

[vim/vim] Possible bug

Hi, I fuzz vim and found a suspicious line of code here. https://github.com/vim/vim/blob/master/src/option.c#L153:13 It seems to miss a nullptr check here, when the alloc fails, the STRCPY later will cause a crash. best regards, Kang -- -- You received this message from the "vim_dev"

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

Re: 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 Bu

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

gt; > 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 tha

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

s 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: > > > > > > d63a85592cef0ee4f0fec

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

r 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: > > > > d63a85592cef0ee4f0fec5efe2f8d66b31f01f

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

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

Bug in patch 9.0.0907 causes E1312 in autocmd

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 wi

BUG: Dead keys with spurious character

learning vimscript and more advanced stuff. After I heard about the 9.0 release of Vim I wondered if it would have solved some issues I had back then, and to my surprise it actually did. So I decided to give Vim 9.0 a try. Now, here's where the problems come again. I have found this bug when I

Re: [vim/vim] bug still not fixed in v8.2.5157: different behavier between vim and gvim, about (Issue #10615)

> Thanks Bram for rolling back this 'fix'. Very surprised by the regression > caused, I wonder how this patch can pass the tests. If I can help in the > future to add or run tests, please let me know. NiVa There are no tests for this low-level functionality. Perhaps there is a way to add

Re: [vim/vim] bug still not fixed in v8.2.5157: different behavier between vim and gvim, about (Issue #10615)

Thanks Bram for rolling back this 'fix'. Very surprised by the regression caused, I wonder how this patch can pass the tests. If I can help in the future to add or run tests, please let me know. NiVa Le samedi 25 juin 2022 à 14:46:08 UTC+2, Bram Moolenaar a écrit : > 8.2.4807 has been

netrw formatting bug and improvement and documentation improvement

I have a small patch, below, for the netrw plugin. - I found that the netrw plugin didn't properly recognize the difference between netrw_sizestyle values of "h" and "H" if ignorecase is turned on. - I also prefer to have it format the size with a sometimes consistent width. I

Re: Strange cut-n-paste bug?

On Sa, 11 Sep 2021, $Bill wrote: > Using the 19 lines of text below (numbered sequentially in 1st 2 cols) as a > test case - please save to unix file fmt file on Windows 10 file system to > reproduce my problem. > > My editor is gvim on Windows 10 64-bit: > VIM - Vi IMproved 8.2 (2019

Strange cut-n-paste bug?

Using the 19 lines of text below (numbered sequentially in 1st 2 cols) as a test case - please save to unix file fmt file on Windows 10 file system to reproduce my problem. My editor is gvim on Windows 10 64-bit: VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jun 12 2020 22:02:10)

Re: [vim/vim] A possible divide by zero bug in misc2.c (#8767)

Hi, Op di 17 aug. 2021 08:31 schreef yiyuaner : > In the file misc2.c, the function coladvance2 has the following code > > : > > int width = curwin->w_width - win_col_off(curwin); > if (finetune >

Re: [vim/vim] Potential vim bug related to :bd of linked file and opening again

t; > instead of opening the actual file it again opens the symlink file: > > > > $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv > > > > I think this is a bug. > > > > I am using vim 8.2.1523 > > > > Thanks in advance :) > > IIUC you fel

Re: [vim/vim] Potential vim bug related to :bd of linked file and opening again

n i try to open the original file > > :e $ROOT/src/verif/glx/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv > > instead of opening the actual file it again opens the symlink file: > > $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv > > I think this is a bug. > > I am using vim

[vim/vim] Potential vim bug related to :bd of linked file and opening again

ain opens the symlink file: *$OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv* I think this is a bug. I am using vim 8.2.1523 Thanks in advance :) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying

Re: Bug in vim script 'comments'?

Gary Johnson wrote: > A change was made to the 'comments' setting in ftplugin/vim.vim at > commit 7ff78465f7057a672a6de0d75d56286da253501b (between 8.2.1175 > and 8.2.1176) that introduced a change in formatting behavior that > I think is a bug. > > The setting of the

Bug in vim script 'comments'?

A change was made to the 'comments' setting in ftplugin/vim.vim at commit 7ff78465f7057a672a6de0d75d56286da253501b (between 8.2.1175 and 8.2.1176) that introduced a change in formatting behavior that I think is a bug. The setting of the 'comments' option was changed from this: setlocal com

Re: Bug in :sh introduced at 8.2.1833

ds to be done > again. > > I'll remove the patch for now. Perhaps someone can debug why this is > needed. I'm trying to look at this in the cracks, but the cracks aren't very wide these days. I'm posting this for anyone else who might be looking at this issue. I was curious about the

Re: Bug in :sh introduced at 8.2.1833

Gary Johnson wrote: > Starting with 8.2.1833, the :sh command no longer works when vim is > reading text from stdin. The screen flashes, but nothing else > happens. > > To demonstrate this, execute the following: > > $ ls | vim -N -u NONE - > :sh > > Using git bisect, I found the

Bug in :sh introduced at 8.2.1833

Starting with 8.2.1833, the :sh command no longer works when vim is reading text from stdin. The screen flashes, but nothing else happens. To demonstrate this, execute the following: $ ls | vim -N -u NONE - :sh Using git bisect, I found the offending commit. $ git bisect bad

Re: Vim bug

On Mi, 18 Nov 2020, Abraham Santos wrote: > This file (sample.pro) is visualized in wrong colors. Cant attach so i will > paste the content here. > > QT += quick multimedia > > CONFIG += c++11 > > # You can make your code fail to compile if it uses deprecated APIs. > # In order to do so,

Vim bug

This file (sample.pro) is visualized in wrong colors. Cant attach so i will paste the content here. QT += quick multimedia CONFIG += c++11 # You can make your code fail to compile if it uses deprecated APIs. # In order to do so, uncomment the following line. #DEFINES +=

Re: Possible bug in pattern processing for try/catch blocks

NOT caught. It appears that using the > "^" metacharacter here causes the message not to match. > > Can anyone else confirm this? Is this a bug? > > It definitely surprised me. > > The exception that is thrown is "Vim(echoerr):foo bar baz". So if you want

Possible bug in pattern processing for try/catch blocks

: try echoerr 'foo bar baz' catch /^foo/ echo 'caught' endtry You will see that the message was NOT caught. It appears that using the "^" metacharacter here causes the message not to match. Can anyone else confirm this? Is this a bug? It definitely surp

Re: [bug] terminal is sometimes in cooked mode at :confirm prompt

Jason Franklin wrote: > Note that this bug report and patch is not my work. This solution was > provided to me by a colleague named "Brandon Pfeifer" to submit to this > list. Please credit him in the commit message and changelog if this > patch is accep

[bug] terminal is sometimes in cooked mode at :confirm prompt

Greetings: Note that this bug report and patch is not my work. This solution was provided to me by a colleague named "Brandon Pfeifer" to submit to this list. Please credit him in the commit message and changelog if this patch is accepted. To reproduce... - latest

Re: Fwd: Bug tracking for vim-perl

On Wed, Apr 15, 2020 at 9:06 PM Bram Moolenaar wrote: > > > Tony wrote: > > > After sending a message to the address vim-p...@googlegroups.com > > mentioned as "maintainer" at top of the Perl ftplugin > > $VIMRUNTIME/ftplugin/perl.vim I got the message below. IIUC this means > > that the

[bug] Bad highlighting from syntax/man.vim

Greetings: Some man page headers and footers are not highlighted properly. Examples on Debian 10 include "man last" and "man ufw". This commit changes the highlighting rules to always highlight the first and last lines, regardless of their form. This means that man pages that look like (in the

Re: Fwd: Bug tracking for vim-perl

Tony wrote: > After sending a message to the address vim-p...@googlegroups.com > mentioned as "maintainer" at top of the Perl ftplugin > $VIMRUNTIME/ftplugin/perl.vim I got the message below. IIUC this means > that the maintainer address should be changed. The syntax and indent > perl.vim

Fwd: Bug tracking for vim-perl

all three perl6.vim scripts, already include the "new" reporting address. Best regards, Tony. -- Forwarded message - From: Andy Lester Date: Tue, Apr 14, 2020 at 5:06 PM Subject: Bug tracking for vim-perl To: Please report your problem to the GitHub issue tracker a

[bug] The :Man command overwrites the unnamed register

Greetings: Every time the ":Man" command is executed, it will overwrite the unnamed register. See the test in the patch below for the reproduction. diff --git a/runtime/ftplugin/man.vim b/runtime/ftplugin/man.vim index d7ce4d8ac..1c13c8065 100644 --- a/runtime/ftplugin/man.vim +++

Re: [vim/vim] C syntax highlighting bug with uncommented #include (#5705)

On Friday, 28 February 2020 06:21:20 UTC, Christian Brabandt wrote: > > Is that actually valid syntax? > It is valid syntax. According to the standard all comments are replaced with spaces before executing pre-processor directives like #include. This means any directive can appear after a

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

Jason Franklin wrote: > On 2/3/20 3:30 PM, Bram Moolenaar wrote: > > Yes, that makes sense. It only happens once, after most of the startup > > has been done. It should happen on a next pass through main_loop(), but > > apparently some typehead is consumed at a lower level without returning >

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

On 2/3/20 3:30 PM, Bram Moolenaar wrote: > Yes, that makes sense. It only happens once, after most of the startup > has been done. It should happen on a next pass through main_loop(), but > apparently some typehead is consumed at a lower level without returning > to the main loop. Thanks, Bram.

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

Jason Franklin wrote: > I've come up with a small patch that fixes this issue for me very reliably > for me. It breaks no tests, and it fixes both the lagging status line > and title string on my machine: > > diff --git a/src/main.c b/src/main.c > index 68a419eaa..4bd0219c0 100644 > ---

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

I've come up with a small patch that fixes this issue for me very reliably for me. It breaks no tests, and it fixes both the lagging status line and title string on my machine: diff --git a/src/main.c b/src/main.c index 68a419eaa..4bd0219c0 100644 --- a/src/main.c +++ b/src/main.c @@ -893,11

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

ew more times and finally noticed it once. Must be a race > condition. > Thank goodness! I was beginning to think I was crazy. It's weird that I can reliably produce the bug on every invocation. I don't have any problem reproducing from one try to the next. Maybe the build configuration is

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

Jason Franklin wrote: > On 1/30/20 1:53 PM, Bram Moolenaar wrote: > >> When you say there is no problem, do you mean that the rendering happens > >> as expected, or after you press a key? I need to press a key to see the > >> screen update. > > > > I don't need to press a key. > > Have you

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

Jason Franklin wrote: > On 1/30/20 10:14 AM, Bram Moolenaar wrote: > > I don't see any problem. Window title is updated and status line shows > > properly. > > > I have attached a screenshot that shows what I see after running this > command: > > VIMRUNTIME=../runtime ./vim -u NONE \ >

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

On 1/30/20 10:14 AM, Bram Moolenaar wrote: > I don't see any problem. Window title is updated and status line shows > properly. > I have attached a screenshot that shows what I see after running this command: VIMRUNTIME=../runtime ./vim -u NONE \ --cmd 'set nocp lz title laststatus=2'

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

Jason Franklin wrote: > On 1/30/20 8:02 AM, Christian Brabandt wrote: > > Have you tried with a dumb terminal, so Vim won't try to figure all this > > out, e.g. TERM=dumb vim (you won't have fun with this one, as it > > doesn't show colors) > > > > or alternatively with one of the

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

On 1/30/20 8:02 AM, Christian Brabandt wrote: > Have you tried with a dumb terminal, so Vim won't try to figure all this > out, e.g. TERM=dumb vim (you won't have fun with this one, as it > doesn't show colors) > > or alternatively with one of the builtin terminals: > >

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

On Mi, 29 Jan 2020, Jason Franklin wrote: > 1. maketitle() is called twice in the NeoVim startup process, once in Vim > 2. in NeoVim, char_avail() is zero even with the same options as above (-u > NONE --cmd 'set nocp lz title') > > I'm not sure why char_avail() returns a different response

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

On Wednesday, January 29, 2020 at 3:28:06 PM UTC-5, Bram Moolenaar wrote: > > > Possibly Vim asks the terminal for the version, and the response can be > read from the input. You could make t_RV empty to avoid that. > I don't think this is the right fix. NeoVim doesn't have this problem for

Re: [BUG] Confusing behavior of the char_avail() function breaks titlestring

Jason Franklin wrote: > I discovered a bug a while ago that can be observed in xterm, > gnome-terminal, > and konsole (on KDE). > > To reproduce the bug, with the latest build... > > 1. cd src/ > 2. VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp lz title' > 3.

[BUG] Confusing behavior of the char_avail() function breaks titlestring

Greetings: I discovered a bug a while ago that can be observed in xterm, gnome-terminal, and konsole (on KDE). To reproduce the bug, with the latest build... 1. cd src/ 2. VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp lz title' 3. note that the title string is not drawn, also, possibly

Re: [vim/vim] Bug (crash) in vim in terminal (#5410)

Can you check your autocommands? What kind of python plugins are you running? As a workaround, try a vim without python. That should fix the crash. > Am 29.12.2019 um 20:50 schrieb Klaus Ethgen (Vim Github Repository) > : > >  > Also no success. :-( > > That github is somewhat picky with

Re: [BUG] v:errmsg is set when opening gVim

Jason Franklin wrote: > Found a small bug. > > Reproduce: > > 1. gVim --clean > 2. :echo v:errmsg > > The error message is due to some missing error checking in menu.vim. I > updated the test for this script. > > I also noticed that delmenu.vi

[BUG] v:errmsg is set when opening gVim

Greetings, Found a small bug. Reproduce: 1. gVim --clean 2. :echo v:errmsg The error message is due to some missing error checking in menu.vim. I updated the test for this script. I also noticed that delmenu.vim uses :silent! instead of :unlet!. The latter is preferable because it doesn't

Odd display bug with gVim under Windows

Load the attached file in gVim and you should see the line of "x" characters display higher than they should. For me on my recent compile they display so high that they interfere with the top line of the buffer displaying the alphabet. This appears to happen when the line contains the one

Re: Bug: vim 8 can't write to Gnome Virtual File System mounts while every other program can (including vim 7.4)

> Somewhere between Vim 7.4 and Vim 8 (or at least the Vim 8 that Ubuntu > ships), the ability to write > to files mounted over Gnome's Virtual File System (GVFS) was lost. > > See this Ubuntu bug from a few months ago that nobody noticed: > > https://bugs.launchpad.n

Bug: vim 8 can't write to Gnome Virtual File System mounts while every other program can (including vim 7.4)

Somewhere between Vim 7.4 and Vim 8 (or at least the Vim 8 that Ubuntu ships), the ability to write to files mounted over Gnome's Virtual File System (GVFS) was lost. See this Ubuntu bug from a few months ago that nobody noticed: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1813679

Re: strange vim-airline bug

Christian wrote: > I just received a bug for vim-airline for which I suspect this might be > caused by a vim particularity. The bug is here: > https://github.com/vim-airline/vim-airline/issues/1989 > > The symptom is, that if one uses 'R' and replaces a bit, and right after &g

strange vim-airline bug

Hi, I just received a bug for vim-airline for which I suspect this might be caused by a vim particularity. The bug is here: https://github.com/vim-airline/vim-airline/issues/1989 The symptom is, that if one uses 'R' and replaces a bit, and right after that presses 'r' the statusline switches

Re: Bug of vim script

no spaces. Best regards, Tony. On Sun, Sep 15, 2019 at 9:47 AM Tony Mechelynck wrote: > > On Sun, Sep 15, 2019 at 8:55 AM Shidong Wang wrote: > > > > Hello, I am not sure if it is a bug, but it always make me confuses: > > > > here is a exmaple: > > >

Bug of vim script

a: is a scope, like g: or s:, for arguments of the function. For example: function WithArgs(first, second) echo a:first a:second echo a:1 a:2 endfunction Regards, John Little -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text

Re: Bug of vim script

On Sun, Sep 15, 2019 at 8:55 AM Shidong Wang wrote: > > Hello, I am not sure if it is a bug, but it always make me confuses: > > here is a exmaple: > > func Test() > let c = 'sss' > let a = 1 > let b = 2 > echo c[a:b] > endf > > then call Test(),

Bug of vim script

Hello, I am not sure if it is a bug, but it always make me confuses: here is a exmaple: func Test() let c = 'sss' let a = 1 let b = 2 echo c[a:b] endf then call Test(), you will get error, Undefined variable: a:b of cause this can be avoided by changing the last line to echo c[a : b

Re: Peculiar bug with title string (simple repro)

On Sunday, June 23, 2019 at 2:40:30 AM UTC+2, Jason Franklin wrote: > Interested to see if anyone can reproduce this: > > ./vim --clean --cmd 'set lz title' --cmd 'autocmd VimEnter * sleep' > > Summary: > > > If it works for you, you may see that the title string is not > redrawn when

Peculiar bug with title string (simple repro)

Interested to see if anyone can reproduce this: ./vim --clean --cmd 'set lz title' --cmd 'autocmd VimEnter * sleep' Summary: If it works for you, you may see that the title string is not redrawn when Vim is fully loaded up. That is, when the VimEnter autocommands take too long with

Re: [bug] Session file does not restore correct current window on each tab page

> Wel already do use :argadd actually, when starting with "vim file1 > file2". The first buffer is wiped out, we just don't have buffer number > one. I think this is not true if 'hidden' is set. I failed to include that in my example though. Sorry for being unclear there. With 'hidden' the

Re: [bug] Session file does not restore correct current window on each tab page

Jason Franklin wrote: > > Perhaps using :argadd works to create the buffers without actually > > opening them or any other side effects. Then later reset the > > argument list. > > I think it's even trickier than using :argadd. For example... > > vim --clean > :argadd test.txt > :e

Re: [bug] Session file does not restore correct current window on each tab page

Bram, > Perhaps using :argadd works to create the buffers without actually > opening them or any other side effects. Then later reset the > argument list. I think it's even trickier than using :argadd. For example... vim --clean :argadd test.txt :e test.txt Notice that you're now

Re: [bug] Session file does not restore correct current window on each tab page

Christian wrote: > On Di, 21 Mai 2019, Jason Franklin wrote: > > > > Does this also fix https://github.com/vim/vim/issues/4352 I suppose not? > > > > No, it does not fix that issue. > > > > However, I'm not exactly sure that the issue referenced is a valid > > complaint. It was my

Re: [bug] Session file does not restore correct current window on each tab page

On Tue, May 21, 2019 at 2:31 PM Jason Franklin wrote: > > > Does this also fix https://github.com/vim/vim/issues/4352 I suppose not? > > No, it does not fix that issue. > > However, I'm not exactly sure that the issue referenced is a valid > complaint. It was my understanding that buffer numbers

Re: [bug] Session file does not restore correct current window on each tab page

On Di, 21 Mai 2019, Jason Franklin wrote: > > Does this also fix https://github.com/vim/vim/issues/4352 I suppose not? > > No, it does not fix that issue. > > However, I'm not exactly sure that the issue referenced is a valid > complaint. It was my understanding that buffer numbers are

Re: [bug] Session file does not restore correct current window on each tab page

> Does this also fix https://github.com/vim/vim/issues/4352 I suppose not? No, it does not fix that issue. However, I'm not exactly sure that the issue referenced is a valid complaint. It was my understanding that buffer numbers are simply id numbers and shouldn't be relied upon for anything

Re: [bug] Session file does not restore correct current window on each tab page

On Mo, 20 Mai 2019, Jason Franklin wrote: > When restoring a session that has multiple tab pages, the current > window for each tab page is not restored as expected. The new test > below currently fails but should pass: Does this also fix https://github.com/vim/vim/issues/4352 I suppose not?

[bug] Session file does not restore correct current window on each tab page

When restoring a session that has multiple tab pages, the current window for each tab page is not restored as expected. The new test below currently fails but should pass: diff --git a/src/testdir/test_mksession.vim b/src/testdir/test_mksession.vim index bc41396..80bedfc 100644 ---

Re: [BUG] :bn/:bp do not respect shortmess+=F when 'hidden' is set (ATTN: chrisbra)

the problem I > noticed here? > > Well, we can go back to the master branch (no patch) and see: > > $ ./vim --clean > > :set hidden > :e file1 > :e file2 > :let x = execute('bn', '') > " Notice, the message appears, as expected. >

[BUG] :bn/:bp do not respect shortmess+=F when 'hidden' is set (ATTN: chrisbra)

= execute('bn', '') " Notice, the message appears, as expected. :echo x " But, it wasn't captured! I'm not sure how to fix this problem. The bug appears to be that execute() does not capture messages that are set to be printed after the next redraw, as opposed to being printe

Re: [bug] vim on windows does not seem to expand environment variables

On 2019-03-26, Christian Brabandt wrote: > On Di, 26 Mär 2019, Gary Johnson wrote: > > > On 2019-03-26, Charles Cooper wrote: > > > > ... neither of the following work: > > > > :echo expand("$PATH") > > > This works for me now as it has in the past, using a gvim compiled with > > > MSVC.

Re: [bug] vim on windows does not seem to expand environment variables

On Di, 26 Mär 2019, Bram Moolenaar wrote: > expand() wasn't made for expanding environment variables. Why not use > $PATH directly? because I was trying to use an environment variable that is not know to Vim :) > Not sure if $random works, might be something built into cmd.exe. Yes it

Re: [bug] vim on windows does not seem to expand environment variables

On Di, 26 Mär 2019, Gary Johnson wrote: > On 2019-03-26, Charles Cooper wrote: > > > ... neither of the following work: > > > :echo expand("$PATH") > > This works for me now as it has in the past, using a gvim compiled with > > MSVC. Could there be a difference if compiled with gcc? > >

Re: [bug] vim on windows does not seem to expand environment variables

Christian wrote: > having read :h expand-env, I suspected that this also works on Windows, > however it does not seem to be the case: > > :echo $PATH > " This correctly shows the path, but neither of the following work: > :echo expand("$PATH") > :echo expand("%PATH%") > > My use case is to

  1   2   3   4   5   6   7   8   9   10   >