Re: [vim/vim] Minor bug: Does not append new line (Issue #14181)

[Gary Johnson]

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.

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

[Tony Mechelynck]

In Insert mode with 'delcombine' set, when the cursor is in a screen
cell containing not only a spacing character but also one or more
combining characters (or, in gvim, seems to be between that screen
cell and the one before it)  skips the spacing character and
removes a composing character (I haven't checked if it removes the
first one, the last one, or all of them). Now :help 'delcombine'
doesn't mention the  key. It does mention "Normal-mode x"
however, so the fact that the  key acts likewise in Normal mode
can be inferred from the stated fact (under ":h ") that there it
is equivalent to x or dl. But in Insert mode, x as a delete command
doesn't exist (except as Ctrl-O x which brings us temporarily into
Normal mode) and according to ":help i_"  deletes "the
character under the cursor"; repeated keypresses delete (in the
plain-vanilla case where only spacing characters are present)
successive characters going forward.

The meaning of the word "character" here is ambiguous: are the spacing
character and all its possible combining characters regarded as one
"character" or are they treated severally when 'delcombine' 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'", or both)?

Or else (if this is regarded as a bug –or a coding bug– rather than a
feature –or documentation bug–) shouldn't Insert-mode  remove the
spacing character and all its possible composing characters together
regardless of 'delcombine', unlike what x (and, by implication only,
) is documented to do in Normal mode, but like what  now
does (at patchlevel 9.1.137 and later) in Command-line mode?

This Insert-mode behaviour existed at patchlevel 9.1.136 and remains
so at patchlevel 9.1.140 so patch 9.1.137 had no effect on it.

I tested this in Cyrillic script because my owncoded Russian keymap
can easily produce a "combining acute accent" but I expect gvim (or
Console Vim if the underlying console knows about composing
characters) to behave identically with any composing characters in any
script.

Best regards,
Tony.

-- 
-- 
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/CAJkCKXsJ2OGUePNGumH8cwgLG0K-PpTe96ihzx9AumeGAjJOAg%40mail.gmail.com.

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

[Ken Takata]

Hi,

This kind of displaying error can happen by the ambiguous width characters.
This can happen when the character width defined by the selected font and 
the width that Vim is recognizing don't match.
(For console version of Vim, the width that the terminal emulator is 
recognizing must also match.)

Normally, this can be controlled by the 'ambiwidth' option.
If you use CJK fonts, setting this to "double" might be better.

KaoriYa Vim provides an additional setting to the 'ambiwidth' option.
It provides ambiwidth=auto setting which automatically recognize the width 
from the actual font.
(ambiwidth=auto is the default setting for KaoriYa Vim.)

If you use DirectWrite, the issue can be more complicated.
If a glyph isn't found in the current font, Windows automatically find the 
glyph from other fonts.
E.g. If you select a double-width font, but if the glyph from a 
single-width font is used,
the width can be changed.
(KaoriYa Vim's ambiwidth=auto patch doesn't support DirectWrite, but I have 
an additional patch to support it.)

If you need a fine tuning, you can also use setcellwidths().

Regards,
Ken Takata

2023年12月18日月曜日 10:01:58 UTC+9 Korean user1 (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 
> available.
>
> In the CJK area, CJK characters and Unicode symbols It is called 
> 'full-width character', and in comparison, English characters are called 
> 'half-width characters'.
>
> In other words, the width of the CJ[image: 
> vim-input-unicode-symbol-halfwidth-problems-korean.gif]K character is 
> exactly twice the width of the English character. In addition, the 'Unicode 
> symbol' should also be marked twice as wide. In vim, however, most of the 
> 'unicode symbols' are treated as half-width characters and are not 
> displayed correctly.
>
> I have attached a GIF animation file for easy understanding.
>

-- 
-- 
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/a020d4c3-8fb3-48f1-9544-a6117b5d2c9cn%40googlegroups.com.

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

[Eric Pruitt]

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 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/ZYDnO4RYD8VZN76T%40sinister.lan.codevat.com.

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

[Christian Brabandt]

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! 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/ZYA4/q9hXRYUvI1l%40256bit.org.

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

[Christian Brabandt]

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 people whose job it is to
tell you why you cannot have the information you require.

-- 
-- 
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/ZYAtGt8edtgVu1Cb%40256bit.org.

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

[Christian Brabandt]

On Mo, 18 Dez 2023, Korean user1 (in CJK) wrote:

> The range of Unicode symbols is extensive. I haven't tested all Unicode 
> symbols for half-width display.

Please give an example of such a char then.

> I tested it in the corrected vim yesterday by a Japanese named Kaoriya, and 
> there was no half-width marking problem I mentioned.
> I received it in the following url.
> 
> https://www.kaoriya.net/software/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 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 using a gui based mail client, that does not help me.

Thanks,
Christian
-- 
The moon is made of green cheese.
-- John Heywood

-- 
-- 
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/ZYAs2Nu5qoK%2BHlQu%40256bit.org.

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

[Korean user1 (in CJK)]

-
vim82-kaoriya-win64-8.2.1287-20200724.zip
/patch/2003-charspace.diff
-

# HG changeset patch
# Parent 4788b87d17786243e3d3b6fca78c4ff73026644b
implement 'charspace' for Windows GUI

diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index 8598713bc..1d83efb2a 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -1498,6 +1498,20 @@ A jump table for the options with a short 
description can be found at |Q_op|.
  This option cannot be set from a |modeline| or in the |sandbox|, for
  security reasons.
 
+ *'charspace'* *'csp'*
+'charspace' 'csp' number (default: 0)
+ global
+ {not in Vi}
+ {only in Windows GUI version and when compiled with
+ the |+kaoriya| feature}
+ Number of horizontal pixels inserted between characters.  Useful if
+ the font uses the full character cell width, making characters touch
+ each other.
+ When non-zero there is room for side of characters.
+ With some fonts there can  be too much room between characters (to
+ have space for left and right).  Then it make sense to set 'charspace'
+ to a negative value.  This may cause display problems though!
+
 *'cindent'* *'cin'* *'nocindent'* *'nocin'*
 'cindent' 'cin' boolean (default off)
  local to buffer
diff --git a/src/gui_w32.c b/src/gui_w32.c
index d9d835bd7..10c495c45 100644
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -1472,6 +1472,8 @@ GetFontSize(GuiFont font)
  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz",
  52, );
 gui.char_width = (size.cx / 26 + 1) / 2 + tm.tmOverhang;
+// add extra pixels for 'charspace' option.
+gui.char_width += p_charspace;
 
 gui.char_height = tm.tmHeight + p_linespace;
 
diff --git a/src/option.c b/src/option.c
index c581e47a1..93de1e307 100644
--- a/src/option.c
+++ b/src/option.c
@@ -3256,7 +3256,7 @@ set_num_option(
 }
 
 #ifdef FEAT_GUI
-else if (pp == _linespace)
+else if (pp == _linespace || pp == _charspace)
 {
  // Recompute gui.char_height and resize the Vim window to keep the
  // same number of lines.
diff --git a/src/option.h b/src/option.h
index 27aae4099..0844b743c 100644
--- a/src/option.h
+++ b/src/option.h
@@ -456,6 +456,9 @@ EXTERN int p_deco; // 'delcombine'
 #ifdef FEAT_EVAL
 EXTERN char_u *p_ccv; // 'charconvert'
 #endif
+#ifdef FEAT_GUI
+EXTERN long p_charspace; // 'charspace'
+#endif
 EXTERN char_u *p_cino; // 'cinoptions'
 #ifdef FEAT_CMDWIN
 EXTERN char_u *p_cedit; // 'cedit'
diff --git a/src/optiondefs.h b/src/optiondefs.h
index 6e9701ab3..e0c893f0d 100644
--- a/src/optiondefs.h
+++ b/src/optiondefs.h
@@ -566,6 +566,14 @@ static struct vimoption options[] =
  {(char_u *)0L, (char_u *)0L}
 #endif
  SCTX_INIT},
+{"charspace",   "csp",  P_NUM|P_NODEFAULT|P_VIM|P_RCLR,
+#ifdef FEAT_GUI
+ (char_u *)_charspace, PV_NONE,
+#else
+ (char_u *)NULL, PV_NONE,
+#endif
+ {(char_u *)0L, (char_u *)0L}
+ SCTX_INIT},
 {"cindent", "cin",  P_BOOL|P_VI_DEF|P_VIM,
 #ifdef FEAT_CINDENT
  (char_u *)_cin, PV_CIN,

2023년 12월 18일 월요일 오후 8시 10분 0초 UTC+9에 Korean user1 (in CJK)님이 작성:

> The range of Unicode symbols is extensive. I haven't tested all Unicode 
> symbols for half-width display.
> I tested it in the corrected vim yesterday by a Japanese named Kaoriya, 
> and there was no half-width marking problem I mentioned.
> I received it in the following url.
>
> https://www.kaoriya.net/software/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 the vim of Kaoriya and attached 2 gif files.
>
> [image: vim-kaoriya-fork-display-unicode-symbol-1.gif]
> [image: vim-kaoriya-fork-display-unicode-symbol-2.gif]
> 2023년 12월 18일 월요일 오후 5시 26분 7초 UTC+9에 Christian Brabandt님이 작성:
>
>> 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 editors like vim Only fixed-width fonts are 
>> available. 
>> > 
>> > In the CJK area, CJK characters and Unicode symbols It is called 
>> 'full-width character', and in comparison, English characters are called 
>> 'half-width characters'. 
>> > 
>> > In other words, the width of the 
>> CJvim-input-unicode-symbol-halfwidth-problems-korean.gifK character is 
>> exactly twice the width of the English character. In addition, the '

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

[Korean user1 (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 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 
>> available.
>>
>> In the CJK area, CJK characters and Unicode symbols It is called 
>> 'full-width character', and in comparison, English characters are called 
>> 'half-width characters'.
>>
>> In other words, the width of the CJ[image: 
>> vim-input-unicode-symbol-halfwidth-problems-korean.gif]K character is 
>> exactly twice the width of the English character. In addition, the 'Unicode 
>> symbol' should also be marked twice as wide. In vim, however, most of the 
>> 'unicode symbols' are treated as half-width characters and are not 
>> displayed correctly.
>>
>> I have attached a GIF animation file for easy understanding.
>>
>
> AFAIK, Vim is aware of the double width of most CJK characters, but you 
> may need to use gvim to display them correctly, because vim-in-console 
> depends on the underlying console for display.
>
> Which Vim version are you using ? From time to time, new versions of Vim 
> include definitions of newly defined Unicode characters concerning narrow 
> vs. wide characters, lowercase vs. uppercase correlations, etc. Version 
> 9.0.2173 has been published on 2023-12-17 or shortly before that.
>
> Best regards,
> Tony.
>

-- 
-- 
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/0440ee66-549b-4d6b-8724-a401e38e5ffdn%40googlegroups.com.

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

[Christian Brabandt]

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 editors like vim Only fixed-width fonts are 
> available.
> 
> In the CJK area, CJK characters and Unicode symbols It is called 'full-width 
> character', and in comparison, English characters are called 'half-width 
> characters'.
> 
> In other words, the width of the 
> CJvim-input-unicode-symbol-halfwidth-problems-korean.gifK character is 
> exactly twice the width of the English character. In addition, the 'Unicode 
> symbol' should also be marked twice as wide. In vim,
> however, most of the 'unicode symbols' are treated as half-width characters 
> and are not displayed correctly.

What symbol (name or codepoint) is this?  Perhaps it's wrong in the 
Unicode database? we are regularly syncing with the last released 
unicode database, last change was v9.0.2013 for Unicode release v15.1 
(released 23.09.2023)

Thanks,
Christian
-- 
Haste makes waste.
-- John Heywood

-- 
-- 
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/ZYACGcE0uiDFn4Hu%40256bit.org.

Commit: patch 9.0.1928: Vim9: constructor type checking bug

[Christian Brabandt]

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 checking bug
Solution: Fix class constructor regression

closes: #13102
closes: #13113

Signed-off-by: Christian Brabandt 
Co-authored-by: h-east 

diff --git a/src/proto/userfunc.pro b/src/proto/userfunc.pro
index e5d78b66f..7b4129b47 100644
--- a/src/proto/userfunc.pro
+++ b/src/proto/userfunc.pro
@@ -47,7 +47,7 @@ char_u *get_scriptlocal_funcname(char_u *funcname);
 char_u *alloc_printable_func_name(char_u *fname);
 char_u *save_function_name(char_u **name, int *is_global, int skip, int flags, 
funcdict_T *fudi);
 void list_functions(regmatch_T *regmatch);
-ufunc_T *define_function(exarg_T *eap, char_u *name_arg, garray_T 
*lines_to_free, int class_flags);
+ufunc_T *define_function(exarg_T *eap, char_u *name_arg, garray_T 
*lines_to_free, int class_flags, ocmember_T *obj_members, int obj_member_count);
 void ex_function(exarg_T *eap);
 ufunc_T *find_func_by_name(char_u *name, compiletype_T *compile_type);
 void ex_defcompile(exarg_T *eap);
diff --git a/src/proto/vim9instr.pro b/src/proto/vim9instr.pro
index 3f287d064..aef934f57 100644
--- a/src/proto/vim9instr.pro
+++ b/src/proto/vim9instr.pro
@@ -58,7 +58,7 @@ int check_internal_func_args(cctx_T *cctx, int func_idx, int 
argcount, int metho
 int generate_BCALL(cctx_T *cctx, int func_idx, int argcount, int method_call);
 int generate_LISTAPPEND(cctx_T *cctx);
 int generate_BLOBAPPEND(cctx_T *cctx);
-int generate_CALL(cctx_T *cctx, ufunc_T *ufunc, class_T *cl, int mi, type_T 
*mtype, int pushed_argcount);
+int generate_CALL(cctx_T *cctx, ufunc_T *ufunc, class_T *cl, int mi, int 
pushed_argcount);
 int generate_UCALL(cctx_T *cctx, char_u *name, int argcount);
 int check_func_args_from_type(cctx_T *cctx, type_T *type, int argcount, int 
at_top, char_u *name);
 int generate_PCALL(cctx_T *cctx, int argcount, char_u *name, type_T *type, int 
at_top);
diff --git a/src/testdir/test_vim9_class.vim b/src/testdir/test_vim9_class.vim
index 6c338167f..87679d814 100644
--- a/src/testdir/test_vim9_class.vim
+++ b/src/testdir/test_vim9_class.vim
@@ -921,6 +921,27 @@ def Test_class_new_with_object_member()
   Check()
   END
   v9.CheckSourceFailure(lines, 'E1013:')
+
+  lines =<< trim END
+  vim9script
+
+  class C
+this.str: string
+def new(str: any)
+enddef
+  endclass
+
+  def Check()
+try
+  var c = C.new(1)
+catch
+  assert_report($'Unexpected exception was caught: {v:exception}')
+endtry
+  enddef
+
+  Check()
+  END
+  v9.CheckSourceSuccess(lines)
 enddef
 
 def Test_class_object_member_inits()
diff --git a/src/userfunc.c b/src/userfunc.c
index efde29dcb..a27ff984d 100644
--- a/src/userfunc.c
+++ b/src/userfunc.c
@@ -65,6 +65,7 @@ one_function_arg(
garray_T*newargs,
garray_T*argtypes,
int types_optional,
+   garray_T*arg_objm,
evalarg_T   *evalarg,
exarg_T *eap,
int is_vararg,
@@ -136,7 +137,8 @@ one_function_arg(
 }
 
 // get any type from "arg: type"
-if (argtypes != NULL && (skip || ga_grow(argtypes, 1) == OK))
+if (argtypes != NULL && (skip || ga_grow(argtypes, 1) == OK)
+   && arg_objm != NULL && (skip || ga_grow(arg_objm, 1) == OK))
 {
char_u *type = NULL;
 
@@ -172,6 +174,7 @@ one_function_arg(
type = vim_strsave((char_u *)
(is_vararg ? "list" : "any"));
((char_u **)argtypes->ga_data)[argtypes->ga_len++] = type;
+   ((int8_T *)arg_objm->ga_data)[arg_objm->ga_len++] = FALSE;
}
 }
 
@@ -221,6 +224,7 @@ get_function_args(
 garray_T   *newargs,
 garray_T   *argtypes,  // NULL unless using :def
 inttypes_optional, // types optional if "argtypes" is not 
NULL
+garray_T   *arg_objm,  // NULL unless using :def
 evalarg_T  *evalarg,   // context or NULL
 int*varargs,
 garray_T   *default_args,
@@ -241,6 +245,8 @@ get_function_args(
ga_init2(newargs, sizeof(char_u *), 3);
 if (argtypes != NULL)
ga_init2(argtypes, sizeof(char_u *), 3);
+if (arg_objm != NULL)
+   ga_init2(arg_objm, sizeof(int8_T), 3);
 if (!skip && default_args != NULL)
ga_init2(default_args, sizeof(char_u *), 3);
 
@@ -295,7 +301,7 @@ get_function_args(
 
arg = p;
p = one_function_arg(p, newargs, argtypes, types_optional,
-evalarg, eap, TRUE, skip);
+ 

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

[Yegappan Lakshmanan]

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/lifepillar/vim-devel/blob/main/start/librelalg/test/test_librelalg.vim>,
> but I was able to nail down the issue to the following self-contained
> script:
>
> vim9script
> def ListifyKeys(keys: any): list>
>   if type(keys) == v:t_string
> return [[keys]]
>   endif
>   return keysenddef
> class Rel
>   this.keys: list>
>
>   def new(keys: any)
> const keys_: list> = ListifyKeys(keys)
>   enddef
> endclass
> def Test()
>   var R = Rel.new('A')enddef
> Test()
>
> This fails with E1013: Argument 1: type mismatch, expected
> list> but got string.
>
> Interestingly, if the this.keys attribute is removed, no error occurs.
> Expected behaviour
>
> I would expect the script above to run without errors. That was the case
> before patch 9.0.1724.
>
> The code currently checks for the type of arguments to the new()
constructor, even if the argument
name does not start with "this".  In the above example, if you rename the
"keys" argument to the
new() function, then you will not see this issue.

The following patch is needed to address this:

diff --git a/src/vim9instr.c b/src/vim9instr.c
index ccec0bcc3..7af478f71 100644
--- a/src/vim9instr.c
+++ b/src/vim9instr.c
@@ -1838,9 +1838,13 @@ generate_CALL(
{
class_T *clp = mtype->tt_class;
char_u  *aname = ((char_u **)ufunc->uf_args.ga_data)[i];
-   ocmember_T *m = object_member_lookup(clp, aname, 0,
NULL);
-   if (m != NULL)
-   expected = m->ocm_type;
+   if (STRNCMP(aname, "this.", 5) == 0)
+   {
+   aname += 5;
+   ocmember_T *m = object_member_lookup(clp, aname, 0,
NULL);
+   if (m != NULL)
+   expected = m->ocm_type;
+   }
}
}
else if (ufunc->uf_va_type == NULL

Some of the existing tests need to be adjusted for this change.

Regards,
Yegappan

-- 
-- 
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/CAAW7x7miWmq5tcFQL4YAS5rC_buoL74zXZX5DAt1Mxhg_Wsy%3DQ%40mail.gmail.com.

patch 9.0.1724: vim9class constructor argument type checking bug

[Christian Brabandt]

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: vim9class constructor argument type checking bug
Solution: fix it

closes: #12816

Signed-off-by: Christian Brabandt 
Co-authored-by: h-east 

diff --git a/src/proto/vim9instr.pro b/src/proto/vim9instr.pro
index 9372b1fc6..685094828 100644
--- a/src/proto/vim9instr.pro
+++ b/src/proto/vim9instr.pro
@@ -57,7 +57,7 @@ int check_internal_func_args(cctx_T *cctx, int func_idx, int 
argcount, int metho
 int generate_BCALL(cctx_T *cctx, int func_idx, int argcount, int method_call);
 int generate_LISTAPPEND(cctx_T *cctx);
 int generate_BLOBAPPEND(cctx_T *cctx);
-int generate_CALL(cctx_T *cctx, ufunc_T *ufunc, class_T *cl, int mi, int 
pushed_argcount);
+int generate_CALL(cctx_T *cctx, ufunc_T *ufunc, class_T *cl, int mi, type_T 
*mtype, int pushed_argcount);
 int generate_UCALL(cctx_T *cctx, char_u *name, int argcount);
 int check_func_args_from_type(cctx_T *cctx, type_T *type, int argcount, int 
at_top, char_u *name);
 int generate_PCALL(cctx_T *cctx, int argcount, char_u *name, type_T *type, int 
at_top);
diff --git a/src/testdir/test_vim9_class.vim b/src/testdir/test_vim9_class.vim
index e60b3b63c..cd67b5415 100644
--- a/src/testdir/test_vim9_class.vim
+++ b/src/testdir/test_vim9_class.vim
@@ -518,6 +518,83 @@ def Test_class_default_new()
   v9.CheckScriptFailure(lines, 'E119:')
 enddef
 
+
+def Test_class_new_with_object_member()
+  var lines =<< trim END
+  vim9script
+
+  class C
+this.str: string
+this.num: number
+def new(this.str, this.num)
+enddef
+def newVals(this.str, this.num)
+enddef
+  endclass
+
+  def Check()
+try
+  var c = C.new('cats', 2)
+  assert_equal('cats', c.str)
+  assert_equal(2, c.num)
+
+  c = C.newVals('dogs', 4)
+  assert_equal('dogs', c.str)
+  assert_equal(4, c.num)
+catch
+  assert_report($'Unexpected exception was caught: {v:exception}')
+endtry
+  enddef
+
+  Check()
+  END
+  v9.CheckScriptSuccess(lines)
+
+  lines =<< trim END
+  vim9script
+
+  class C
+this.str: string
+this.num: number
+def new(this.str, this.num)
+enddef
+  endclass
+
+  def Check()
+try
+  var c = C.new(1, 2)
+catch
+  assert_report($'Unexpected exception was caught: {v:exception}')
+endtry
+  enddef
+
+  Check()
+  END
+  v9.CheckScriptFailure(lines, 'E1013:')
+
+  lines =<< trim END
+  vim9script
+
+  class C
+this.str: string
+this.num: number
+def newVals(this.str, this.num)
+enddef
+  endclass
+
+  def Check()
+try
+  var c = C.newVals('dogs', 'apes')
+catch
+  assert_report($'Unexpected exception was caught: {v:exception}')
+endtry
+  enddef
+
+  Check()
+  END
+  v9.CheckScriptFailure(lines, 'E1013:')
+enddef
+
 def Test_class_object_member_inits()
   var lines =<< trim END
   vim9script
diff --git a/src/version.c b/src/version.c
index de1d6e01f..0d898692b 100644
--- a/src/version.c
+++ b/src/version.c
@@ -695,6 +695,8 @@ static char *(features[]) =
 
 static int included_patches[] =
 {   /* Add new patch number below this line */
+/**/
+1724,
 /**/
 1723,
 /**/
diff --git a/src/vim9expr.c b/src/vim9expr.c
index d600cb0ae..db4cee1b1 100644
--- a/src/vim9expr.c
+++ b/src/vim9expr.c
@@ -358,8 +358,8 @@ compile_class_object_index(cctx_T *cctx, char_u **arg, 
type_T *type)
 
if (type->tt_type == VAR_OBJECT
 && (cl->class_flags & (CLASS_INTERFACE | CLASS_EXTENDED)))
-   return generate_CALL(cctx, ufunc, cl, fi, argcount);
-   return generate_CALL(cctx, ufunc, NULL, 0, argcount);
+   return generate_CALL(cctx, ufunc, cl, fi, type, argcount);
+   return generate_CALL(cctx, ufunc, NULL, 0, type, argcount);
 }
 
 if (type->tt_type == VAR_OBJECT)
@@ -932,6 +932,7 @@ compile_call(
 inthas_g_namespace;
 ca_special_T special_fn;
 imported_T *import;
+type_T *type;
 
 if (varlen >= sizeof(namebuf))
 {
@@ -1015,6 +1016,7 @@ compile_call(
 if (compile_arguments(arg, cctx, , special_fn) == FAIL)
goto theend;
 
+type = get_decl_type_on_stack(cctx, 1);
 is_autoload = vim_strchr(name, AUTOLOAD_CHAR) != NULL;
 if (ASCII_ISLOWER(*name) && name[1] != ':' && !is_autoload)
 {
@@ -1032,8 +1034,6 @@ compile_call(
 
if (STRCMP(name, "add") == 0 && argcount == 2)
{
-   type_T  *type = get_decl_type_on_stack(cctx, 

Re: Bug in :vmap

[Gary Johnson]

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 (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
> 
> When the "normal" command is executed Vim is still in Visual mode.  In
> that mode "gv" is an error.  I'm not sure how an error is handled in
> this specific situation, but a flag may be set that causes what follows
> to work differently.
> 
> > 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.
> 
> That is unexpected, ":silent" should not suppress the error, only
> ":silent!" should have that effect.  I currently don't have time to look
> into this.  Best is to avoid the error caused by "gv", hopefully then
> your problems won't occur.

The gv doesn't generate an error message and without it, my function
doesn't yank anything.

I now have a version of my actual function that behaves as I 

Re: Bug in :vmap

[Bram Moolenaar]

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

When the "normal" command is executed Vim is still in Visual mode.  In
that mode "gv" is an error.  I'm not sure how an error is handled in
this specific situation, but a flag may be set that causes what follows
to work differently.

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

That is unexpected, ":silent" should not suppress the error, only
":silent!" should have that effect.  I currently don't have time to look
into this.  Best is to avoid the error caused by "gv", hopefully then
your problems won't occur.

-- 
hundred-and-one symptoms of being an internet addict:
193. You ask your girlfriend to drive home so you can sit back with
 your PDA and download the information to your laptop

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS 

Re: Bug in :vmap

[Gary Johnson]

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: Bug in :vmap

[Bram Moolenaar]

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

-- 
hundred-and-one symptoms of being an internet addict:
178. You look for an icon to double-click to open your bedroom window.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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/20230615174529.46E361C0D56%40moolenaar.net.

Re: Bug in :vmap

[Gary Johnson]

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.

Re: Bug in :vmap

[Bram Moolenaar]

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

-- 
If Microsoft would build a car...
... The airbag system would ask "are you SURE?" before deploying.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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/20230615153522.738AB1C0D56%40moolenaar.net.

Bug in :vmap

[Gary Johnson]

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: Bug in Vim window height calculation with 'winfixheight'

[Bram Moolenaar]

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
> > >  :setlocal winfixheight
> > >
> > > 3. Open another horizontally split window and close it:
> > >
> > >:botright new
> > >:close
> > >
> > > Repeat step 3 few times. You will notice that every time the window is
> > > closed, the height of the window with the 'winfixheight' option will in=
> crease.
> > > I expected that the height of this window will remain the same.
> > >
> > > This problem is not seen if instead of two windows at the top, only one
> > > window is used in the above steps.
> > >
> > > I see the above problem using Vim 7.2.
> >
> > I'll add it to the todo list.
> >
> 
> I am not able to reproduce this issue with the latest Vim.  So the
> following item can be
> removed from the todo list:
> 
> opening/closing window causes other window with 'winfixheight' to change
> height.  Also happens when there is another window in the frame, if it's not
> very high. (Yegappan Lakshmanan, 2010 Jul 22, Michael Peeters, 2010 Jul 22)

OK, I'll remove the paragraph.

-- 
The sooner you fall behind, the more time you'll have to catch up.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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/20230529190021.C117E1C0F36%40moolenaar.net.

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

[Yegappan Lakshmanan]

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 'winfixheight' option:
> >
> >  :botright 5new
> >  :setlocal winfixheight
> >
> > 3. Open another horizontally split window and close it:
> >
> >:botright new
> >:close
> >
> > Repeat step 3 few times. You will notice that every time the window is
> > closed, the height of the window with the 'winfixheight' option will 
> > increase.
> > I expected that the height of this window will remain the same.
> >
> > This problem is not seen if instead of two windows at the top, only one
> > window is used in the above steps.
> >
> > I see the above problem using Vim 7.2.
>
> I'll add it to the todo list.
>

I am not able to reproduce this issue with the latest Vim.  So the
following item can be
removed from the todo list:

opening/closing window causes other window with 'winfixheight' to change
height.  Also happens when there is another window in the frame, if it's not
very high. (Yegappan Lakshmanan, 2010 Jul 22, Michael Peeters, 2010 Jul 22)

Regards,
Yegappan

-- 
-- 
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/CAAW7x7mZNBzPjGzP9i0nyK62ARLrvaCCfyTvnQT0K_%3D7PV6rSw%40mail.gmail.com.

[vim/vim] Possible bug

[Kang Chen]

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" 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/CANE%2BtVqt9vpQ4gKGxcDSCnR_OarW0bmwJQ%3D%2BogwduwBDMOap%3Dg%40mail.gmail.com.

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

[Gary Johnson]

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: Bug in patch 9.0.0907 causes E1312 in autocmd

[Matt Martini]

Gary,

I (and others) are having the same issue with 
*vim-nerdtree-tabs <https://github.com/jistr/vim-nerdtree-tabs>. *
It is fully described here: issue #102 
<https://github.com/jistr/vim-nerdtree-tabs/issues/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



On Wednesday, December 14, 2022 at 4:54:37 PM UTC-5 Gary Johnson wrote:

> 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

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

[Gary Johnson]

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 can probably find another way.
> > 
>

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

[Bram Moolenaar]

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

At some point I thought I should drop auto commands completely, because
it's just getting too complicated and too many crashes have had to be
fixed.  And there are probably a few more 

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

[Gary Johnson]

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.

Re: Bug in patch 9.0.0907 causes E1312 in autocmd

[Bram Moolenaar]

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.

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?

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.


-- 
The psychic said, "God bless you."  I said, "I didn't sneeze."  She
looked deep into my eyes and said, "You will, eventually."  And, damn
if she wasn't right.  Two days later, I sneezed.  --Ellen Degeneres

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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/20221214131333.BE5FA1C0CF1%40moolenaar.net.

Bug in patch 9.0.0907 causes E1312 in autocmd

[Gary Johnson]

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.

BUG: Dead keys with spurious character

[Cosmic Chaos]

Hi there! My name is Leonardo Alvaro from Mexico, and I've been a Vim user
for almost a year now... I started my journey with Vim 8.2 for Windows 10
and it was quite a struggle to get everything working as I wanted, so after
I had some basic understanding I moved to NeoVim. That's when I started
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 was
trying to type normally with the Spanish keyboard layout. I was so
disconcerted by this that I decided it would be a fairly worthwhile bug
report.

Also, in my search to overcome this issue I discovered the 'keymap'
functionality and I found that the spanish-qwerty layout was missing, so I
made one that matches precisely the behavior of the standard Latin American
keyboard layout. I attached that file to this email.

And now, here's the little report I wrote for the bug. I hope everything's
clear enough.

--

BUG: Dead keys with spurious character

NOTES:
* MS-Windows 64-bit console version exclusive issue
* It has been tested with the following keyboard layouts:
- Latin American

DESCRIPTION:

An additional spurious character is added when a dead key
combination is tried.

With the Latin American keyboard layout:
Dead keys: [´¨]
Spurious characters: [;:]

For the sake of an example, here's the contrast between the
expected and the obtained output when typing 'linguistics' in
Spanish:
Expected: lingüística
Obtained: ling:ü;ística

To make it even clearer here's a table contrasting the keyboard
input, the obtained output, and the expected output:

KEYBOAD INPUT   OBTAINED  EXPECTED
--- - -
´;´´
´´  ;´´   ´´
´a´e´i´o´u´ ;á;é;í;ó;úáéíóú
´A´E´I´O´U´ ;Á;É;Í;Ó;ÚÁÉÍÓÚ
¨:¨¨
¨¨  :¨¨   ¨¨
¨u¨U:ü:Ü  üÜ

* Even though it may seem so, they are not composite characters,
they all form part of the extended ASCII.

--

In fact, I have more bugs to report, and even a typo in the documentation,
but I don't want to bloat this email with a bunch of unrelated issues.

-- 
-- 
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/CANTPnjMSQuYfWiWVxWEgH3CDatxRBXjKTAQKjhruFzTMm2cJ_A%40mail.gmail.com.


spanish-qwerty.vim
Description: Binary data

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

[Bram Moolenaar]

> 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 some, but the main problem is that the behavior of the
libraries with all the different environments is hardly predictable.
Is there a way to simulate actual key presses?  And know the expected
result with various keyboard layouts and other settings?

It also appears that problems are reported (long) after a change was
made.  Before patch 8.2.4807 was included I asked if it looked OK.  But
several problems were reported later.

I have no knowledge of "best practices" of this MS-Windows code.  And it
seems various people only understand parts of it.  I have no idea if
rolling back 8.2.4807 gives us a better starting point or it's better to
fixe any problems introduced by it.

-- 
Never enter the boss's office unless it's absolutely necessary.  Every boss
saves one corner of the desk for useless assignments that are doled out like
Halloween candy to each visitor.
(Scott Adams - The Dilbert principle)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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/20220625131357.E95C31C4808%40moolenaar.net.

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

[N V]

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 included quite a while ago. Rolling it back now does not 
> appear to be a good solution.
> It appears 8.2.5157 is the one causing most problems now. Then there are a 
> few remaining issues to be fixed.
>
> —
> Reply to this email directly, view it on GitHub 
> .
>
> You are receiving this because you are subscribed to this thread.Message 
> ID: 
>

-- 
-- 
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/564f049e-89da-4c11-bfcf-7d25cf633306n%40googlegroups.com.

netrw formatting bug and improvement and documentation improvement

[Mark Waggoner]

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 didn't go the the effort to compute how wide it needed to be in 
   the patch below, bit it will make it align better much of the time.   
   - Finally, I added a little bit to the netrw documentation to make the 
   g:netrw_dynamic_maxfilenamelen setting easier to find.


 --- runtime/autoload/netrw.vim2021-10-13 16:55:56.217948000 -0700
+++ local/share/vim/vim82/autoload/netrw.vim2022-03-21 
11:08:02.071576000 -0700
@@ -12174,34 +12174,34 @@
 fun! s:NetrwHumanReadable(sz)
 "  call Dfunc("s:NetrwHumanReadable(sz=".a:sz.") type=".type(a:sz)." 
style=".g:netrw_sizestyle )
 
-  if g:netrw_sizestyle == 'h'
+  if g:netrw_sizestyle ==# 'h'
if a:sz >= 10 
-let sz = printf("%.1f",a:sz/10.0)."g"
+let sz = printf("%4.1f",a:sz/10.0)."g"
elseif a:sz >= 1000
-let sz = printf("%d",a:sz/100)."m"
+let sz = printf("%4d",a:sz/100)."m"
elseif a:sz >= 100
-let sz = printf("%.1f",a:sz/100.0)."m"
+let sz = printf("%4.1f",a:sz/100.0)."m"
elseif a:sz >= 1
-let sz = printf("%d",a:sz/1000)."k"
+let sz = printf("%4d",a:sz/1000)."k"
elseif a:sz >= 1000
-let sz = printf("%.1f",a:sz/1000.0)."k"
+let sz = printf("%4.1f",a:sz/1000.0)."k"
else
-let sz= a:sz
+let sz= printf("%4d",a:sz) . " "
endif
 
-  elseif g:netrw_sizestyle == 'H'
+  elseif g:netrw_sizestyle ==# 'H'
if a:sz >= 1073741824
-let sz = printf("%.1f",a:sz/1073741824.0)."G"
+let sz = printf("%4.1f",a:sz/1073741824.0)."G"
elseif a:sz >= 10485760
-let sz = printf("%d",a:sz/1048576)."M"
+let sz = printf("%4d",a:sz/1048576)."M"
elseif a:sz >= 1048576
-let sz = printf("%.1f",a:sz/1048576.0)."M"
+let sz = printf("%4.1f",a:sz/1048576.0)."M"
elseif a:sz >= 10240
-let sz = printf("%d",a:sz/1024)."K"
+let sz = printf("%4d",a:sz/1024)."K"
elseif a:sz >= 1024
-let sz = printf("%.1f",a:sz/1024.0)."K"
+let sz = printf("%4.1f",a:sz/1024.0)."K"
else
-let sz= a:sz
+let sz= printf("%4d",a:sz) . " "
endif
 
   else
--- runtime/doc/pi_netrw.txt2022-03-21 11:12:31.791377000 -0700
+++ local/share/vim/vim82/doc/pi_netrw.txt2022-03-21 
11:24:25.756314000 -0700
@@ -1401,6 +1401,7 @@
 <
 Associated setting variables: |g:netrw_liststyle| |g:netrw_maxfilenamelen|
   |g:netrw_timefmt|   |g:netrw_list_cmd|
+  |g:netrw_dynamic_maxfilenamelen|
 
 CHANGE FILE PERMISSION   
 *netrw-gp* {{{2
 
@@ -2880,7 +2881,8 @@
 If your screen is wider, and you have file
 or directory names longer than 32 bytes,
 you may set this option to keep listings
-columnar.
+columnar. 
+Also see |g:netrw_dynamic_maxfilenamelen|
 
   *g:netrw_mkdir_cmd*command for making a remote directory
 via ssh  (also see |g:netrw_remote_mkdir|)

-- 
-- 
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/7b8d675f-c392-41a4-8754-abc44d14ca1dn%40googlegroups.com.

Re: Strange cut-n-paste bug?

[Christian Brabandt]

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 Dec 12, compiled Jun 12 2020 22:02:10)
> MS-Windows 64-bit GUI version with OLE support
> Included patches: 1-967  Compiled by appveyor-at-APPVYR-WIN
> 
> How to reproduce error:
> 
> Move to line 11 col 1
> Type "a5dd (to delete 5 lines and store them in "a)
> Move to line 17 col 1
> Type "bY (to copy line to "b)
> Move to line 19 col 1
> Type "BY (to append line to "b)
> Move to line 10 col 1
> Type 5dd (to cut lines 10, 16-19 into unnamed register)
> Move to line 6 col 1
> Type p (to paste those 5 lines in unnamed register between the lines 6&7)
> 
> Fails! Instead of pasting the 5 lines from unnamed register, it pastes the
> two lines from "b
> 
> 
> Given The following text (part of a WNBA boxscore with numbers added to col 
> 1):
> 
> -- save me to disk (I'm using Unix file fmt on 64-bit 
> Doze 10 --
> 
> 1
> 2 
> 3
> 4
> 5 
> 6
> 7
> 8 
> 9
> 10 aaa 4.
> 11 Game Dbl-Figures Leaders:
> 12 Player Pts FG% 3P% FT% RB AS BL ST TO PF EFF
> 13 b 12 (50 /0 /67 )/ 7/ 3/ 0/ 2/ 3/ 4/+15
> 14 cc 12 (57 /67 /100)/ 2/ 1/ 1/ 0/ 1/ 3/+12
> 15 ddd 10 (63 /0 /0 )/ 1/ 3/ 0/ 3/ 5/ 3/ +9
> 16 4 5-15 0-3 2-2 5-12 1-1 3-4 33.3 0.0 100 41.7 100 75 12 14
> 17 F 23-55 2-10 9-11 23-52 3-13 26-29 41.8 20 81.8 44.2 23.1 89.7 57 75
> 18 4 3 6 3 2 3 3 4 3 3 7 3 1 4 6 -1 -1 +2 -1 -2
> 19 F 13 19 5 10 4 17 22 9 14 32 13 4 20 17 -1 -13 -4 -3 -3 +5
> 
> -- end test file 
> ---
> 
> I doubt it matters, but I'm in the left window of a vertically even split 161 
> char window (80 & 80) for 55 lines.

Strange, I can reproduce.

I'll have a closer look soon.


Best,
Christian
-- 
Leben heißt, sich wandeln; und vollkommen sein heißt, sich oft
gewandelt haben.
-- John Henry Newman

-- 
-- 
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/20210913150704.GA2593739%40256bit.org.

Strange cut-n-paste bug?

[$Bill]

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)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-967  Compiled by appveyor-at-APPVYR-WIN

How to reproduce error:

Move to line 11 col 1
Type "a5dd (to delete 5 lines and store them in "a)
Move to line 17 col 1
Type "bY (to copy line to "b)
Move to line 19 col 1
Type "BY (to append line to "b)
Move to line 10 col 1
Type 5dd (to cut lines 10, 16-19 into unnamed register)
Move to line 6 col 1
Type p (to paste those 5 lines in unnamed register between the lines 6&7)

Fails! Instead of pasting the 5 lines from unnamed register, it pastes the
two lines from "b


Given The following text (part of a WNBA boxscore with numbers added to col 
1):

-- save me to disk (I'm using Unix file fmt on 
64-bit Doze 10 --

1
2 
3
4
5 
6
7
8 
9
10 aaa 4.
11 Game Dbl-Figures Leaders:
12 Player Pts FG% 3P% FT% RB AS BL ST TO PF EFF
13 b 12 (50 /0 /67 )/ 7/ 3/ 0/ 2/ 3/ 4/+15
14 cc 12 (57 /67 /100)/ 2/ 1/ 1/ 0/ 1/ 3/+12
15 ddd 10 (63 /0 /0 )/ 1/ 3/ 0/ 3/ 5/ 3/ +9
16 4 5-15 0-3 2-2 5-12 1-1 3-4 33.3 0.0 100 41.7 100 75 12 14
17 F 23-55 2-10 9-11 23-52 3-13 26-29 41.8 20 81.8 44.2 23.1 89.7 57 75
18 4 3 6 3 2 3 3 4 3 3 7 3 1 4 6 -1 -1 +2 -1 -2
19 F 13 19 5 10 4 17 22 9 14 32 13 4 20 17 -1 -13 -4 -3 -3 +5

-- end test file 
---

I doubt it matters, but I'm in the left window of a vertically even split 
161 char window (80 & 80) for 55 lines.

TIA, Bill



-- 
-- 
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/0d83cf2a-1322-4eaa-be01-497ba8f94c2dn%40googlegroups.com.

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

[Christ van Willegen]

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
> && curwin->w_p_wrap
> && curwin->w_width != 0
> && wcol >= (colnr_T)width)
> {
> if (wcol / width > (colnr_T)csize / width)
> }
>
> The variable width is used as a divisor but its value can be zero because:
>
>1. curwin->w_width may be zero, since the code explicitly checks that 
> curwin->w_width
>!= 0
>
>
Since this is checked in the if statement, it can't be 0.


>1. The function win_col_off(curwin) may return zero, refer to the code
>here
>
> 
>.
>
>
If it returns 0, width would be non zero, or curwin->w_width would be 0,
and this is checked.

So, the code path you describe can't lead to a divide by 0.

If curwin->w_width is a non zero value, _and_ the call to
win_col_off(curwin) returns the same value, then width can become 0. I do
not have the code here to check if this is possible...

Christ van Willegen

-- 
-- 
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/CA%2BOt1OxVKUwDv6afCSsiKk%3Ds-mJN2z%3Dstd%3DxaAVQSTB-q8Fv3g%40mail.gmail.com.

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

[justrajdeep]

Thanks Tony.
On Friday, May 28, 2021 at 6:30:27 AM UTC-4 Tony Mechelynck wrote:

> On Fri, May 28, 2021 at 12:55 AM justrajdeep  wrote:
> >
> > Hi
> >
> > I have a file and a soft link to it
> >
> >
> > ls -ltr $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv
> > lrwxrwxrwx 1 ramondal gfx11 85 May 27 10:21 
> $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv -> 
> $ROOT/src/verif/glx/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv
> >
> > i open the symlink file using gvim
> >
> > gvim -u $VIM_HOME/share/vim/vim82/vimrc_example.vim 
> $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv
> >
> > delete the buffer
> >
> > :bd
> >
> > Then 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 8.2.1523
> >
> > Thanks in advance :)
>
> IIUC you fell upon a documented but little known quirk of Vim, namely,
> :bdelete does not delete everything about a buffer; if you want to
> forget everything (but maybe more than you want), use :bwipeout
>
> See
> :help :bdelete
> :help :bwipeout
>
> Best regards,
> Tony.
>

-- 
-- 
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/0d0aa254-d866-4c3c-8bbc-cf9006f6b8cfn%40googlegroups.com.

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

[Tony Mechelynck]

On Fri, May 28, 2021 at 12:55 AM justrajdeep  wrote:
>
> Hi
>
> I have a file and a soft link to it
>
>
> ls -ltr $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv
> lrwxrwxrwx 1 ramondal gfx11 85 May 27 10:21 
> $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv -> 
> $ROOT/src/verif/glx/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv
>
> i open the symlink file using gvim
>
> gvim -u $VIM_HOME/share/vim/vim82/vimrc_example.vim 
> $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv
>
> delete the buffer
>
> :bd
>
> Then 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 8.2.1523
>
> Thanks in advance :)

IIUC you fell upon a documented but little known quirk of Vim, namely,
:bdelete does not delete everything about a buffer; if you want to
forget everything (but maybe more than you want), use :bwipeout

See
:help :bdelete
:help :bwipeout

Best regards,
Tony.

-- 
-- 
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/CAJkCKXsDkN42wCoY%2B2NtyrPubAn-XxDjO8m8b6n4kOXWC9RSbw%40mail.gmail.com.

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

[justrajdeep]

Hi

I have a file and a soft link to it

 
*ls -ltr $OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv*
*lrwxrwxrwx 1 ramondal gfx11 85 May 27 10:21 
$OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv -> 
$ROOT/src/verif/glx/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv*

i open the symlink file using gvim

*gvim -u $VIM_HOME/share/vim/vim82/vimrc_example.vim 
$OUT/src/verif/gl2cc/gl2cc_top/tb/gl2cc_top_tb_pkg.sv*

delete the buffer 

*:bd*

Then 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 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 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/6038d3a6-42d2-47ac-8153-ffbfbc773160n%40googlegroups.com.

Re: Bug in vim script 'comments'?

[Bram Moolenaar]

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 'comments' option was changed from this:
> 
> setlocal com=sO:\"\ -,mO:\"\ \ ,eO:\"\",:\"
> 
> to this:
> 
> setlocal com=sO:\"\ -,mO:\"\ \ ,sO:#\ -,mO:#\ \ ,eO:##,:\",:#
> 
> It appears that the purpose was to add # as a comment leader for
> Vim9, but the change also removed the end string of the original
> three-piece comment definition for the " comment leader.
>
> The problem this causes is that when entering a comment containing
> an indented line that contains a ", the comment leader is not
> automatically inserted at the start of the next line.  Here is an
> example, with 'filetype' set to "vim".
> 
> " When these lines are ended by pressing ,
> " a " is automatically inserted at the start of
> " each next line.  This is good.
> "
> " This line is indented.  Pressing  here
> " also automatically starts this line with ".
> But because of that second " in the line above, this line
> did not start with a ".  The comment was terminated.  This
> is bad.
> 
> The attached patch should fix the problem.  The patch was made
> against Vim 8.2.2519.

Thanks for reporting, I'll include the fix.


-- 
TALL KNIGHT: When you have found the shrubbery, then you must cut down the
 mightiest tree in the forest ... with a herring.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202102200730.11K7UeBG2911280%40masaka.moolenaar.net.

Bug in vim script 'comments'?

[Gary Johnson]

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=sO:\"\ -,mO:\"\ \ ,eO:\"\",:\"

to this:

setlocal com=sO:\"\ -,mO:\"\ \ ,sO:#\ -,mO:#\ \ ,eO:##,:\",:#

It appears that the purpose was to add # as a comment leader for
Vim9, but the change also removed the end string of the original
three-piece comment definition for the " comment leader.

The problem this causes is that when entering a comment containing
an indented line that contains a ", the comment leader is not
automatically inserted at the start of the next line.  Here is an
example, with 'filetype' set to "vim".

" When these lines are ended by pressing ,
" a " is automatically inserted at the start of
" each next line.  This is good.
"
" This line is indented.  Pressing  here
" also automatically starts this line with ".
But because of that second " in the line above, this line
did not start with a ".  The comment was terminated.  This
is bad.

The attached patch should fix the problem.  The patch was made
against Vim 8.2.2519.

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/20210219233255.GC10301%40phoenix.
diff --git a/runtime/ftplugin/vim.vim b/runtime/ftplugin/vim.vim
index 5106e86ae..72eaca648 100644
--- a/runtime/ftplugin/vim.vim
+++ b/runtime/ftplugin/vim.vim
@@ -54,7 +54,7 @@ if "\n" .. getline(1, 10)->join("\n") =~# '\n\s*vim9\%[script]\>'
   " Comments starts with # in Vim9 script
   setlocal commentstring=#%s
 else
-  setlocal com=sO:\"\ -,mO:\"\ \ ,:\"
+  setlocal com=sO:\"\ -,mO:\"\ \ ,eO:\"\",:\"
   " Comments starts with a double quote in legacy script
   setlocal commentstring=\"%s
 endif

Re: Bug in :sh introduced at 8.2.1833

[Gary Johnson]

On 2020-12-08, Bram Moolenaar wrote:
> 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 offending commit.
> > 
> > $ git bisect bad
> > 204ade6bcb85f48f56e52e040d1ebf40548d92be is the first bad commit
> > commit 204ade6bcb85f48f56e52e040d1ebf40548d92be
> > Author: Bram Moolenaar 
> > Date:   Sun Oct 11 14:58:46 2020 +0200
> > 
> > patch 8.2.1833: when reading from stdin dup() is called twice
> > 
> > Problem:When reading from stdin dup() is called twice.
> > Solution:   Remove the dup() in main.c. (Ken Takata, closes #7110)
> > 
> >  src/main.c| 15 +--
> >  src/version.c |  2 ++
> >  2 files changed, 7 insertions(+), 10 deletions(-)
> > 
> > The operating system I'm using is Ubuntu 20.04.1 LTS.
> > 
> > 
> > More information:
> > 
> > If before executing :sh, you set the 'shell' to /bin/cat, then
> > executing :sh will cause cat to report the following error.
> > 
> > /bin/cat: -: Bad file descriptor
> > /bin/cat: closing standard input: Bad file descriptor
> > 
> > This problem also occurs when one of vim's arguments is a bash
> > process substitution.  That's been a problem for a while.
> > 
> > My workaround is to detect the problematic conditions and then set
> > 'shell' to a script containing the following.
> > 
> > #!/bin/bash
> > exec < /dev/tty
> > exec $SHELL "$@"
> 
> I can reproduce the problem.  I don't understand why it happens, the
> close(0)/dup(2) in readfile() is executed.  Somehow it needs 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 other, related bug in which

$vim -N -u NONE <(ls)
:sh

exhibits the same problem, that is, :sh immediately returns, and
thought I might learn something from that bug that helps fix them
both.

I found that the problem does not exist in an old version of vim,
7.2.330, I still had around.  I did another git bisect search and
found:

$ git bisect bad
f71d7b9ee5ceba75f70c30845332ddd728fd16c6 is the first bad commit
commit f71d7b9ee5ceba75f70c30845332ddd728fd16c6
Author: Bram Moolenaar 
Date:   Tue Aug 9 22:14:05 2016 +0200

patch 7.4.2189
Problem:Cannot detect encoding in a fifo.
Solution:   Extend the stdin way of detecting encoding to fifo.  Add a 
test
for detecting encoding on stdin and fifo. (Ken Takata)

 src/Makefile  |   1 +
 src/buffer.c  | 130 
++
 src/fileio.c  |  14 ++--
 src/testdir/Make_all.mak  |   1 +
 src/testdir/test_startup_utf8.vim |  64 +++
 src/version.c |   2 +
 src/vim.h |   3 +-
 7 files changed, 168 insertions(+), 47 deletions(-)
 create mode 100644 src/testdir/test_startup_utf8.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/20201209183610.GD3161%40phoenix.

Re: Bug in :sh introduced at 8.2.1833

[Bram Moolenaar]

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 offending commit.
> 
> $ git bisect bad
> 204ade6bcb85f48f56e52e040d1ebf40548d92be is the first bad commit
> commit 204ade6bcb85f48f56e52e040d1ebf40548d92be
> Author: Bram Moolenaar 
> Date:   Sun Oct 11 14:58:46 2020 +0200
> 
> patch 8.2.1833: when reading from stdin dup() is called twice
> 
> Problem:When reading from stdin dup() is called twice.
> Solution:   Remove the dup() in main.c. (Ken Takata, closes #7110)
> 
>  src/main.c| 15 +--
>  src/version.c |  2 ++
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> The operating system I'm using is Ubuntu 20.04.1 LTS.
> 
> 
> More information:
> 
> If before executing :sh, you set the 'shell' to /bin/cat, then
> executing :sh will cause cat to report the following error.
> 
> /bin/cat: -: Bad file descriptor
> /bin/cat: closing standard input: Bad file descriptor
> 
> This problem also occurs when one of vim's arguments is a bash
> process substitution.  That's been a problem for a while.
> 
> My workaround is to detect the problematic conditions and then set
> 'shell' to a script containing the following.
> 
> #!/bin/bash
> exec < /dev/tty
> exec $SHELL "$@"

I can reproduce the problem.  I don't understand why it happens, the
close(0)/dup(2) in readfile() is executed.  Somehow it needs to be done
again.

I'll remove the patch for now.  Perhaps someone can debug why this is
needed.

-- 
It is illegal for anyone to give lighted cigars to dogs, cats, and other
domesticated animal kept as pets.
[real standing law in Illinois, United States of America]

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202012081836.0B8Iaq791704662%40masaka.moolenaar.net.

Bug in :sh introduced at 8.2.1833

[Gary Johnson]

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
204ade6bcb85f48f56e52e040d1ebf40548d92be is the first bad commit
commit 204ade6bcb85f48f56e52e040d1ebf40548d92be
Author: Bram Moolenaar 
Date:   Sun Oct 11 14:58:46 2020 +0200

patch 8.2.1833: when reading from stdin dup() is called twice

Problem:When reading from stdin dup() is called twice.
Solution:   Remove the dup() in main.c. (Ken Takata, closes #7110)

 src/main.c| 15 +--
 src/version.c |  2 ++
 2 files changed, 7 insertions(+), 10 deletions(-)

The operating system I'm using is Ubuntu 20.04.1 LTS.


More information:

If before executing :sh, you set the 'shell' to /bin/cat, then
executing :sh will cause cat to report the following error.

/bin/cat: -: Bad file descriptor
/bin/cat: closing standard input: Bad file descriptor

This problem also occurs when one of vim's arguments is a bash
process substitution.  That's been a problem for a while.

My workaround is to detect the problematic conditions and then set
'shell' to a script containing the following.

#!/bin/bash
exec < /dev/tty
exec $SHELL "$@"

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/20201208063804.GC3161%40phoenix.

Re: Vim bug

[Christian Brabandt]

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, uncomment the following line.
> #DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x06# disables all the APIs 
> deprecated before Qt 6.0.0
> 
> SOURCES += \
>AudioData.cpp \
>Lector.cpp \
>Main.cpp \
>Melodia.cpp
> 
> RESOURCES += \
>Resources.qrc
> 
> # Additional import path used to resolve QML modules in Qt Creator's code 
> model
> QML_IMPORT_PATH =
> 
> # Additional import path used to resolve QML modules just for Qt Quick 
> Designer
> QML_DESIGNER_IMPORT_PATH =
> 
> # Default rules for deployment.
> qnx: target.path = /tmp/$${TARGET}/bin
> else: unix:!android: target.path = /opt/$${TARGET}/bin
> !isEmpty(target.path): INSTALLS += target
> 
> HEADERS += \
>AudioData.h \
>Lector.h \
>Main.h \
>Melodia.h \
>tsf.h
> 
> ANDROID_ABIS = armeabi-v7a

Do you reproduce this with `vim --clean`?

Might want to put an image of what is wrong somewhere. 


Best,
Christian
-- 
Gott hat die Armut nicht erschaffen. Er erschuf nur uns.
-- Mutter Teresa

-- 
-- 
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/20201118203003.GE4980%40256bit.org.

Vim bug

[Abraham Santos]

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 += QT_DISABLE_DEPRECATED_BEFORE=0x06# disables all the 
APIs deprecated before Qt 6.0.0 

SOURCES += \ 
   AudioData.cpp \ 
   Lector.cpp \ 
   Main.cpp \ 
   Melodia.cpp 

RESOURCES += \ 
   Resources.qrc 

# Additional import path used to resolve QML modules in Qt Creator's code 
model 
QML_IMPORT_PATH = 

# Additional import path used to resolve QML modules just for Qt Quick 
Designer 
QML_DESIGNER_IMPORT_PATH = 

# Default rules for deployment. 
qnx: target.path = /tmp/$${TARGET}/bin 
else: unix:!android: target.path = /opt/$${TARGET}/bin 
!isEmpty(target.path): INSTALLS += target 

HEADERS += \ 
   AudioData.h \ 
   Lector.h \ 
   Main.h \ 
   Melodia.h \ 
   tsf.h 

ANDROID_ABIS = armeabi-v7a

-- 
-- 
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/1ac94884-0613-42ce-9ab1-acab3fc6cdafn%40googlegroups.com.

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

[Yegappan Lakshmanan]

Hi,

On Sat, Oct 24, 2020 at 8:15 AM Jason Franklin  wrote:

> Greetings:
>
> I have discovered that the pattern matching in try/catch blocks does not
> conform to my expectations.
>
> Try this example:
>
> try
> echoerr 'foo bar baz'
> catch /foo/
> echo 'caught'
> endtry
>
> The string "caught" is printed, as I would expect.
>
> Now try this:
>
> 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 surprised me.
>
>
The exception that is thrown is "Vim(echoerr):foo bar baz". So if you want
to
match the beginning of the exception string, then you need to
use /^Vim(echoerr):foo/

- Yegappan

-- 
-- 
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/CAAW7x7np3u%3D8SqdnruAiei6kwnrZHJEeS1tH%3DnkzzU_Wau3qDw%40mail.gmail.com.

Possible bug in pattern processing for try/catch blocks

[Jason Franklin]

Greetings:

I have discovered that the pattern matching in try/catch blocks does not
conform to my expectations.

Try this example:

try
echoerr 'foo bar baz'
catch /foo/
echo 'caught'
endtry

The string "caught" is printed, as I would expect.

Now try this:

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

-- 
Jason Franklin

-- 
-- 
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/dabc1bf3b549ab0503dc26ebdd97c0c30fd733bb.camel%40elitemail.org.

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

[Bram Moolenaar]

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 accepted.
> 
> To reproduce...
> 
>   - latest vim build as of this writing (v8.2.1145)
>   - gnome-terminal (Ubuntu 18.04) or konsole (Debian 10)
> 
>   1. VIMRUNTIME=../runtime ./vim --clean
>   2. :set hidden
>   3. itest
>   4. :e buffer.c  (or some other file...)
>   5. :confirm wq
>   6. Now type "c.."
> 
> Brandon discovered that the reason for this is that the do_dialog()
> function is not always executed when the terminal is in raw mode, like
> one would expect.  Sometimes, this function is executed in cooked mode,
> which results in this undesirable behavior.
> 
> Specifically, the problem is observable in the debugger at the select()
> call in the RealWaitForChar() function in os_unix.c.  Cooked mode causes
> this function to wait for a line feed character.
> 
> Two patches are attached to fix this bug.
> 
>   1. test.diff - formal demonstration of bug with a test
>   2. fix.diff - causes do_dialog() to set correct mode (saves/restores)
> 
> Email me with any questions.

Thanks.  I'm not sure why Vim is in cooked mode here.  Anyway, the test
shows that it happens.

Let me use the opportunity to cleanup those tests a bit.

-- 
"You're fired." (1980)
"You're laid off." (1985)
"You're downsized." (1990)
"You're rightsized." (1992)
(Scott Adams - The Dilbert principle)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202007061923.066JNMLQ896023%40masaka.moolenaar.net.

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

[Franklin, Jason]

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 vim build as of this writing (v8.2.1145)
  - gnome-terminal (Ubuntu 18.04) or konsole (Debian 10)

  1. VIMRUNTIME=../runtime ./vim --clean
  2. :set hidden
  3. itest
  4. :e buffer.c  (or some other file...)
  5. :confirm wq
  6. Now type "c.."

Brandon discovered that the reason for this is that the do_dialog()
function is not always executed when the terminal is in raw mode, like
one would expect.  Sometimes, this function is executed in cooked mode,
which results in this undesirable behavior.

Specifically, the problem is observable in the debugger at the select()
call in the RealWaitForChar() function in os_unix.c.  Cooked mode causes
this function to wait for a line feed character.

Two patches are attached to fix this bug.

  1. test.diff - formal demonstration of bug with a test
  2. fix.diff - causes do_dialog() to set correct mode (saves/restores)

Email me with any questions.

Thanks!

-- 
Jason Franklin

-- 
-- 
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/af23d726-e98b-80d8-6287-33a64f3a8d13%40quoininc.com.
diff --git a/src/testdir/test_excmd.vim b/src/testdir/test_excmd.vim
index 2428e9d02..615e232da 100644
--- a/src/testdir/test_excmd.vim
+++ b/src/testdir/test_excmd.vim
@@ -269,6 +269,39 @@ func Test_confirm_cmd_cancel()
   call StopVimInTerminal(buf)
 endfunc
 
+" It was discovered that ":confirm" prompts are sometimes displayed with the
+" terminal in cooked mode.  Thus, a "\" char is required to dismiss the
+" prompt.  This test verifies that a "\" character is NOT required to
+" respond to a prompt from the ":conf q" and ":conf wq" commands.
+func Test_confirm_q_wq()
+  CheckNotGui
+  CheckRunVimInTerminal
+
+  call writefile(['foo'], 'foo')
+
+  let buf = RunVimInTerminal('', {'rows': 20})
+  call term_sendkeys(buf, ":set hidden nomore\n")
+  call term_sendkeys(buf, ":call setline(1, 'abc')\n")
+  call term_sendkeys(buf, ":edit foo\n")
+  call term_sendkeys(buf, ":confirm q\n")
+  call WaitForAssert({-> assert_match('^\[Y\]es, (N)o, (C)ancel: *$',
+\ term_getline(buf, 20))}, 1000)
+  call term_sendkeys(buf, 'C')
+  call WaitForAssert({-> assert_notmatch('^\[Y\]es, (N)o, (C)ancel: C*$',
+\ term_getline(buf, 20))}, 1000)
+
+  call term_sendkeys(buf, ":edit foo\n")
+  call term_sendkeys(buf, ":confirm wq\n")
+  call WaitForAssert({-> assert_match('^\[Y\]es, (N)o, (C)ancel: *$',
+\ term_getline(buf, 20))}, 1000)
+  call term_sendkeys(buf, 'C')
+  call WaitForAssert({-> assert_notmatch('^\[Y\]es, (N)o, (C)ancel: C*$',
+\ term_getline(buf, 20))}, 1000)
+  call StopVimInTerminal(buf)
+
+  call delete('foo')
+endfunc
+
 " Test for the :print command
 func Test_print_cmd()
   call assert_fails('print', 'E749:')
diff --git a/src/message.c b/src/message.c
index 006e648fe..57eae68a8 100644
--- a/src/message.c
+++ b/src/message.c
@@ -3652,6 +3652,7 @@ do_dialog(
 char_u	*hotkeys;
 int		c;
 int		i;
+tmode_T save_tmode;
 
 #ifndef NO_CONSOLE
 // Don't output anything in silent mode ("ex -s")
@@ -3683,6 +3684,10 @@ do_dialog(
 State = CONFIRM;
 setmouse();
 
+// Ensure that the terminal is in raw mode when a dialog is presented.
+save_tmode = cur_tmode;
+settmode(TMODE_RAW);
+
 /*
  * Since we wait for a keypress, don't make the
  * user press RETURN as well afterwards.
@@ -3743,6 +3748,7 @@ do_dialog(
 	vim_free(hotkeys);
 }
 
+settmode(save_tmode);
 State = oldState;
 setmouse();
 --no_wait_return;

Re: Fwd: Bug tracking for vim-perl

[Tony Mechelynck]

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 maintainer address should be changed. The syntax and indent
> > perl.vim scripts, as well as all three perl6.vim scripts, already
> > include the "new" reporting address.
>
> I already see the github URL there.  Only with "http" instead of
> "https".

Ah, yes: under "Bugs/requests", but I set the "Maintainer" as CC and
got the mentioned rebuff. The ftplugin begins as follows:

" Vim filetype plugin file
" Language:  Perl
" Maintainer:vim-perl 
" Homepage:  http://github.com/vim-perl/vim-perl
" Bugs/requests: http://github.com/vim-perl/vim-perl/issues
" Last Change:   2015-02-09

Looks like the so-called "Maintainer" has gone AWOL. (The most recent
post on that Google Group is from September 2017.)

> I only see the compiler plugin use another header, but I think that's
> indeed from someone else.
>
> --
> DENNIS: Look,  strange women lying on their backs in ponds handing out
> swords ... that's no basis for a system of government.  Supreme
> executive power derives from a mandate from the masses, not from some
> farcical aquatic ceremony.
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///

Best regards,
Tony.

-- 
-- 
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/CAJkCKXu5wXGcgmakhsxJBxAsL4ovimooSAhDR5iLE7xHb-2qxQ%40mail.gmail.com.

[bug] Bad highlighting from syntax/man.vim

[Franklin, Jason]

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 case of "man last")...

LAST, LASTB(1)   User Commands   LAST, LASTB(1)

... will still be highlighted correctly.  Same goes for the footer.

diff --git a/runtime/syntax/man.vim b/runtime/syntax/man.vim
index 77675c5d2..5bdba8621 100644
--- a/runtime/syntax/man.vim
+++ b/runtime/syntax/man.vim
@@ -3,7 +3,7 @@
 " Maintainer:  SungHyun Nam 
 " Previous Maintainer: Gautam H. Mudunuri 
 " Version Info:
-" Last Change: 2015 Nov 24
+" Last Change: 2020 Apr 15

 " Additional highlighting by Johannes Tanzler :
 "  * manSubHeading
@@ -18,8 +18,11 @@ endif
 runtime! syntax/ctrlh.vim

 syn case ignore
+
+syn match manHeader '\%1l.*'
+exe 'syn match manFooter ''\%' . line('$') . 'l.*'''
+
 syn match  manReference   "\f\+([1-9][a-z]\=)"
-syn match  manTitle  "^\f\+([0-9]\+[a-z]\=).*"
 syn match  manSectionHeading  "^[a-z][a-z -]*[a-z]$"
 syn match  manSubHeading  "^\s\{3\}[a-z][a-z -]*[a-z]$"
 syn match  manOptionDesc  "^\s*[+-][a-z0-9]\S*"
@@ -36,7 +39,9 @@ endif
 " Define the default highlighting.
 " Only when an item doesn't have highlighting yet

-hi def link manTitle   Title
+hi def link manHeader Title
+hi def link manFooter PreProc
+
 hi def link manSectionHeading  Statement
 hi def link manOptionDesc  Constant
 hi def link manLongOptionDesc  Constant


Thanks!

-- 
Jason Franklin

-- 
-- 
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/6bce33f3-ed9c-351a-19f0-720a1eed6897%40quoininc.com.

Re: Fwd: Bug tracking for vim-perl

[Bram Moolenaar]

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 scripts, as well as all three perl6.vim scripts, already
> include the "new" reporting address.

I already see the github URL there.  Only with "http" instead of
"https".
I only see the compiler plugin use another header, but I think that's
indeed from someone else.

-- 
DENNIS: Look,  strange women lying on their backs in ponds handing out
swords ... that's no basis for a system of government.  Supreme
executive power derives from a mandate from the masses, not from some
farcical aquatic ceremony.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202004151906.03FJ60hF013954%40masaka.moolenaar.net.

Fwd: Bug tracking for vim-perl

[Tony Mechelynck]

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 scripts, as well as 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 at
https://github.com/vim-perl/vim-perl

-- 
-- 
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/CAJkCKXtx6Ebx9VXTzUBymDfjuwM6AVA8wMVnVB7qbeGJcvSruQ%40mail.gmail.com.

[bug] The :Man command overwrites the unnamed register

[Franklin, Jason]

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
+++ b/runtime/ftplugin/man.vim
@@ -189,7 +189,7 @@ func GetPage(cmdmods, ...)
   setl buftype=nofile noswapfile

   setl fdc=0 ma nofen nonu nornu
-  silent exec "norm! 1GdG"
+  %delete _
   let unsetwidth = 0
   if empty($MANWIDTH)
 let $MANWIDTH = winwidth(0)
@@ -213,10 +213,10 @@ func GetPage(cmdmods, ...)
   endif
   " Remove blank lines from top and bottom.
   while line('$') > 1 && getline(1) =~ '^\s*$'
-silent keepj norm! ggdd
+1delete _
   endwhile
   while line('$') > 1 && getline('$') =~ '^\s*$'
-silent keepj norm! Gdd
+$delete _
   endwhile
   1
   setl ft=man nomod
diff --git a/src/testdir/test_man.vim b/src/testdir/test_man.vim
index 9de8cb474..b2fe460d6 100644
--- a/src/testdir/test_man.vim
+++ b/src/testdir/test_man.vim
@@ -111,3 +111,21 @@ func Test_local_options()
   %bw!
   set foldcolumn& number&
 endfunc
+
+" Check that the unnamed register is not overwritten.
+func Test_keep_unnamed_register()
+  %bw!
+
+  let @" = '---'
+
+  let wincnt = winnr('$')
+  Man vim
+  if wincnt == winnr('$')
+" Vim manual page cannot be found.
+return
+  endif
+
+  call assert_equal('---', @")
+
+  %bw!
+endfunc


-- 
Jason Franklin

-- 
-- 
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/4a08c73a-70c8-61de-dd86-5a660f575405%40quoininc.com.

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

[Mike Williams]

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 comment. Not a typical coding 
convention but perfectly valid.


> > Am 27.02.2020 um 21:53 schrieb Bogdan Barbu  >:
> > 
> > 
> > Try the following:
> > /* */ #include 
> > or
> > /*
> > */ #include 
> > 
> > The directive #include will not be highlighted.
> > 
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub, or unsubscribe.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> 
> .
>

-- 
-- 
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/afbadad9-9ab4-4f78-b519-4cc19a9ae2fa%40googlegroups.com.

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

[Bram Moolenaar]

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
> > to the main loop.
> 
> Thanks, Bram.
> 
> I looked at the NeoVim code to see how they avoid this UI problem. Their
> solution was to do two maketitle() calls (I think, ultimately, two
> redraws after startup), which I think is not correct.

It's an easy way out to just redraw more often, which doesn't show any
problems but will make Vim slower.
 
> So, it might be that the char_avail() code should be reviewed to
> actually fix the problem.  I just don't know exactly how it "should"
> work, if it's even broken at all.

It's probably not broken at all.  But when a code is parsed that doesn't
have any effect to the user, especially a terminal reply for number of
colors, default background, etc., it may loop at a low level and not go
back when the buffer becomes empty, and the redraw only happens at a
higher level.  It does return K_IGNORE in some cases, perhaps it should
more often.

-- 
How To Keep A Healthy Level Of Insanity:
15. Five days in advance, tell your friends you can't attend their
party because you're not in the mood.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202002032159.013LxKqI014275%40masaka.moolenaar.net.

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

[Franklin, Jason]

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.

I looked at the NeoVim code to see how they avoid this UI problem. Their
solution was to do two maketitle() calls (I think, ultimately, two
redraws after startup), which I think is not correct.

So, it might be that the char_avail() code should be reviewed to
actually fix the problem.  I just don't know exactly how it "should"
work, if it's even broken at all.

-- 
Jason Franklin

-- 
-- 
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/a0441101-8793-e8de-5cf7-fa8e0e42c717%40quoininc.com.


signature.asc
Description: OpenPGP digital signature

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

[Bram Moolenaar]

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
> --- a/src/main.c
> +++ b/src/main.c
> @@ -893,11 +893,11 @@ vim_main2(void)
>  }
>  #endif
>  
> +do_redraw = TRUE;
> +
>  TIME_MSG("before starting main loop");
>  
> -/*
> - * Call the main command loop.  This never returns.
> - */
> +// Call the main command loop.  This never returns.
>  main_loop(FALSE, FALSE);
>  
>  #endif // NO_VIM_MAIN
> 
> 
> The key is that stuff_empty() should be TRUE when Vim starts up (I think).  
> So, we have the condition 
> 
> else if (do_redraw || stuff_empty())
> 
> in main.c on line 1268.  Since this evaluates to TRUE, we proceed with the 
> redrawing.  Finally,
> we set do_redraw to FALSE later in this block.  Thus, we do all of the 
> drawing on start up and we
> set do_redraw to FALSE as if it was never set before.  The fact that 
> main_loop() doesn't return
> means that we don't break anything.
> 
> This seems to fix my issue without breaking anything else.  However, I 
> can't see all of the
> other possible problems.
> 
> Bram, is this reasonable?

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.

-- 
How To Keep A Healthy Level Of Insanity:
11. Specify that your drive-through order is "to go".

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202002032030.013KU4cM024011%40masaka.moolenaar.net.

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

[Jason Franklin]

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 +893,11 @@ vim_main2(void)
 }
 #endif
 
+do_redraw = TRUE;
+
 TIME_MSG("before starting main loop");
 
-/*
- * Call the main command loop.  This never returns.
- */
+// Call the main command loop.  This never returns.
 main_loop(FALSE, FALSE);
 
 #endif // NO_VIM_MAIN


The key is that stuff_empty() should be TRUE when Vim starts up (I think).  
So, we have
the condition 

else if (do_redraw || stuff_empty())

in main.c on line 1268.  Since this evaluates to TRUE, we proceed with the 
redrawing.  Finally,
we set do_redraw to FALSE later in this block.  Thus, we do all of the 
drawing on start up and we
set do_redraw to FALSE as if it was never set before.  The fact that 
main_loop() doesn't return
means that we don't break anything.

This seems to fix my issue without breaking anything else.  However, I 
can't see all of the
other possible problems.

Bram, is this reasonable?

-- 
Jason Franklin

-- 
-- 
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/186179fe-4d12-45b9-87cb-42d5558b2ad4%40googlegroups.com.

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

[Franklin, Jason]

On 1/31/20 3:15 PM, Bram Moolenaar wrote:
>> The command is:
>>
>>   VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp lz title'
>>
>> I have confirmed this on multiple machines already.
>>
>> Can someone else please confirm this?
> 
> I tried a few 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 different?  See below...

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 29 2020 10:46:03)
Included patches: 1-172
Compiled by jfrankli@qipb7lnca
Huge version without GUI.  Features included (+) or not (-):
+acl   -farsi -mouse_sysmouse-tag_old_static
+arabic+file_in_path  +mouse_urxvt   -tag_any_white
+autocmd   +find_in_path  +mouse_xterm   -tcl
+autochdir +float +multi_byte+termguicolors
-autoservername+folding   +multi_lang+terminal
-balloon_eval  -footer-mzscheme  +terminfo
+balloon_eval_term +fork()+netbeans_intg +termresponse
-browse+gettext   +num64 +textobjects
++builtin_terms-hangul_input  +packages  +textprop
+byte_offset   +iconv +path_extra+timers
+channel   +insert_expand -perl  +title
+cindent   +job   +persistent_undo   -toolbar
-clientserver  +jumplist  +popupwin  +user_commands
-clipboard +keymap+postscript+vartabs
+cmdline_compl +lambda+printer   +vertsplit
+cmdline_hist  +langmap   +profile   +virtualedit
+cmdline_info  +libcall   -python+visual
+comments  +linebreak -python3   +visualextra
+conceal   +lispindent+quickfix  +viminfo
+cryptv+listcmds  +reltime   +vreplace
+cscope+localmap  +rightleft +wildignore
+cursorbind-lua   -ruby  +wildmenu
+cursorshape   +menu  +scrollbind+windows
+dialog_con+mksession +signs +writebackup
+diff  +modify_fname  +smartindent   -X11
+digraphs  +mouse -sound -xfontset
-dnd   -mouseshape+spell -xim
-ebcdic+mouse_dec +startuptime   -xpm
+emacs_tags-mouse_gpm +statusline-xsmp
+eval  -mouse_jsbterm -sun_workshop  -xterm_clipboard
+ex_extra  +mouse_netterm +syntax-xterm_save
+extra_search  +mouse_sgr +tag_binary
   system vimrc file: "$VIM/vimrc"
 user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
  user exrc file: "$HOME/.exrc"
   defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -Og -ggdb -g3
Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim-lm
-ltinfo -lnsl  -ldl

-- 
Jason Franklin

-- 
-- 
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/cd6174fa-6640-0c3a-f459-f035167b28de%40quoininc.com.


signature.asc
Description: OpenPGP digital signature

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

[Bram Moolenaar]

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 tried using *specifically* xterm?  I'm using xterm installed
> from the xterm package on Debian 10.1.

I'm using xterm.
 
> > You could try to set $TERM to different values.
> 
> I'm not sure what value might work???
> 
> I've tried several, with the default being TERM=xterm.  None change the
> behavior.  Screenshots of xterm before the command, after the command,
> and after a keypress are attached.
> 
> The command is:
> 
>   VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp lz title'
> 
> I have confirmed this on multiple machines already.
> 
> Can someone else please confirm this?

I tried a few more times and finally noticed it once.  Must be a race
condition.

-- 
Computers are useless. They can only give you answers.
-- Pablo Picasso

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202001312015.00VKFIWt021656%40masaka.moolenaar.net.

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

[Bram Moolenaar]

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 \
> --cmd 'set nocp lz title laststatus=2'
> 
> 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.

You could try to set $TERM to different values.

-- 
hundred-and-one symptoms of being an internet addict:
23. You can't call your mother... she doesn't have VOIP

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202001301853.00UIrMRO029514%40masaka.moolenaar.net.

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

[Franklin, Jason]

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'

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.

-- 
Jason Franklin

-- 
-- 
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/3be0bc07-72fe-a2d4-3f82-42817e8ad62f%40quoininc.com.


signature.asc
Description: OpenPGP digital signature

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

[Bram Moolenaar]

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 builtin terminals:
> > 
> > VIMRUNTIME=../runtime ./vim -u NONE -N --cmd ':set term=builtin_ansi'
> 
> I gave this a shot, and it definitely didn't solve the problem.
> 
> I think the real solution here is to make sure that maketitle() can do
> its work at start up regardless of the result of char_avail().  Is that
> reasonable?  More work may be necessary to really get it right, though
> (see the following note).
> 
> N.B.:
> 
> I need to note here that the title string is not the only user interface
> element that is broken by this problem.  Try the following:
> 
>   VIMRUNTIME=../runtime ./vim -u NONE \
> --cmd 'set nocp lz title laststatus=2'
> 
> You will see that even the status line is blocked at startup.  The
> screen will redraw when a key is pressed (e.g., "l").  However, this
> looks really bad and happens with any basic vimrc file that sets these
> options.
> 
> Again, this happens in: xterm, konsole, and gnome-terminal.

I don't see any problem.  Window title is updated and status line shows
properly.

-- 
When a fly lands on the ceiling, does it do a half roll or
a half loop?

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202001301514.00UFEChE018705%40masaka.moolenaar.net.

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

[Franklin, Jason]

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:
> 
> VIMRUNTIME=../runtime ./vim -u NONE -N --cmd ':set term=builtin_ansi'

I gave this a shot, and it definitely didn't solve the problem.

I think the real solution here is to make sure that maketitle() can do
its work at start up regardless of the result of char_avail().  Is that
reasonable?  More work may be necessary to really get it right, though
(see the following note).

N.B.:

I need to note here that the title string is not the only user interface
element that is broken by this problem.  Try the following:

  VIMRUNTIME=../runtime ./vim -u NONE \
--cmd 'set nocp lz title laststatus=2'

You will see that even the status line is blocked at startup.  The
screen will redraw when a key is pressed (e.g., "l").  However, this
looks really bad and happens with any basic vimrc file that sets these
options.

Again, this happens in: xterm, konsole, and gnome-terminal.

-- 
Jason Franklin

-- 
-- 
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/2cd84b2a-6e4e-606d-0012-be587a2cabfd%40quoininc.com.


signature.asc
Description: OpenPGP digital signature

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

[Christian Brabandt]

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 here.
> 
> I'm not sure how to go about setting t_RV to an empty string. I tried the 
> following:
> 
>   VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp t_RV= lz title'

Yes, that should be correct. There are a couple of other terminal 
properties, that Vim queries on startup, like terminal version (t_TV), 
cursor position (t_u7), terminal foreground/background color (t_RF, 
t_RB), terminal cursor blinking (t_RC) and cursor style (t_RS), possibly 
more, that I couldn't find out easily.

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:

VIMRUNTIME=../runtime ./vim -u NONE -N --cmd ':set term=builtin_ansi'

Best,
Christian
-- 
Wie man sein Kind nicht nennen sollte: 
  Immo Bilie 

-- 
-- 
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/20200130130243.GC803%40256bit.org.

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

[Jason Franklin]

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 
two reasons that I can tell:

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

I'm not sure how to go about setting t_RV to an empty string. I tried the 
following:

  VIMRUNTIME=../runtime ./vim -u NONE --cmd 'set nocp t_RV= lz title'

with no success.

-- 
Jason Franklin

-- 
-- 
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/4b616adf-9118-45da-a44e-8b3f0d1b7462%40googlegroups.com.

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

[Bram Moolenaar]

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. note that the title string is not drawn, also, possibly, the cursor is 
> not
>in its proper place
> 
> Further, this works if "set nocp lz title" is done in a special vimrc file
> instead of on the command line.
> 
> I have investigated this issue, and I observed that, when maketitle() is
> called, it calls the redrawing() function to see if it needs to do its
> business to update the title.  The redrawing() function returns false on the
> first call, and the reason is that char_avail() returns TRUE.  I can't
> figure out why char_avail() would return true when Vim is just starging up
> and no keys have been pressed.
> 
> Currently, the redrawing() function is a bit difficult to read, the current
> version is reproduced below:
> 
> /*
>  * Return TRUE if redrawing should currently be done.
>  */
> int
> redrawing(void)
> {
> #ifdef FEAT_EVAL
> if (disable_redraw_for_testing)
> return 0;
> else
> #endif
> return ((!RedrawingDisabled
> #ifdef FEAT_EVAL
> || ignore_redraw_flag_for_testing
> #endif
> ) && !(p_lz && char_avail() && !KeyTyped && !do_redraw));
> }
> 
> I have refactored this function for readability.  The new function is here:
> 
> /*
>  * Return TRUE if redrawing should currently be done.
>  */
> int
> redrawing(void)
> {
> #ifdef FEAT_EVAL
> if (disable_redraw_for_testing)
> return FALSE;
> #endif
> 
> if (RedrawingDisabled
> #ifdef FEAT_EVAL
> && !ignore_redraw_flag_for_testing
> #endif
>)
> return FALSE;
> 
> return !p_lz || !char_avail() || KeyTyped || do_redraw;
> }
> 
> Using early return here makes the function easier to understand, in my
> opinion.
> 
> Anyway, the debugger tells me that the reason redrawing() returns FALSE on
> the first call to maketitle() is because char_avail() returns TRUE.  Why
> would this be the case with my "./vim" command above?

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.

-- 
hundred-and-one symptoms of being an internet addict:
7. You finally do take that vacation, but only after buying a USB modem
   and a laptop.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/202001292027.00TKRrnC002204%40masaka.moolenaar.net.

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

[Jason Franklin]

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, the cursor is 
not
   in its proper place

Further, this works if "set nocp lz title" is done in a special vimrc file
instead of on the command line.

I have investigated this issue, and I observed that, when maketitle() is
called, it calls the redrawing() function to see if it needs to do its
business to update the title.  The redrawing() function returns false on the
first call, and the reason is that char_avail() returns TRUE.  I can't
figure out why char_avail() would return true when Vim is just starging up
and no keys have been pressed.

Currently, the redrawing() function is a bit difficult to read, the current
version is reproduced below:

/*
 * Return TRUE if redrawing should currently be done.
 */
int
redrawing(void)
{
#ifdef FEAT_EVAL
if (disable_redraw_for_testing)
return 0;
else
#endif
return ((!RedrawingDisabled
#ifdef FEAT_EVAL
|| ignore_redraw_flag_for_testing
#endif
) && !(p_lz && char_avail() && !KeyTyped && !do_redraw));
}

I have refactored this function for readability.  The new function is here:

/*
 * Return TRUE if redrawing should currently be done.
 */
int
redrawing(void)
{
#ifdef FEAT_EVAL
if (disable_redraw_for_testing)
return FALSE;
#endif

if (RedrawingDisabled
#ifdef FEAT_EVAL
&& !ignore_redraw_flag_for_testing
#endif
   )
return FALSE;

return !p_lz || !char_avail() || KeyTyped || do_redraw;
}

Using early return here makes the function easier to understand, in my
opinion.

Anyway, the debugger tells me that the reason redrawing() returns FALSE on
the first call to maketitle() is because char_avail() returns TRUE.  Why
would this be the case with my "./vim" command above?

Thanks,
Jason Franklin

-- 
-- 
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/60085c3c-3ae8-4dce-9125-511080ee8287%40googlegroups.com.

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

[Christian Brabandt]

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 files.
> valgrind.log
> 
> Ah, it only works with javascript enabled. WTF!?
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> 
> -- 
> -- 
> 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/vim/vim/issues/5410/569536280%40github.com.

-- 
-- 
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/3DECECCB-5970-466A-BE3A-6B61C63758F3%40256bit.org.

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

[Bram Moolenaar]

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.vim uses :silent! instead of :unlet!.  The 
> latter is preferable because it doesn't leave behind an unnecessary 
> v:errmsg.
> 
> Patch follows:

Thanks!

-- 
Eagles may soar, but weasels don't get sucked into jet engines.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/201912102112.xBALCPA8029073%40masaka.moolenaar.net.

[BUG] v:errmsg is set when opening gVim

[Jason Franklin]

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 leave behind an unnecessary 
v:errmsg.

Patch follows:

diff --git a/runtime/delmenu.vim b/runtime/delmenu.vim
index 137218264..d4cb5cf30 100644
--- a/runtime/delmenu.vim
+++ b/runtime/delmenu.vim
@@ -7,25 +7,26 @@
 aunmenu *
 tlunmenu *

-silent! unlet did_install_default_menus
-silent! unlet did_install_syntax_menu
-if exists("did_menu_trans")
+unlet! g:did_install_default_menus
+unlet! g:did_install_syntax_menu
+
+if exists('g:did_menu_trans')
   menutrans clear
-  unlet did_menu_trans
+  unlet g:did_menu_trans
 endif

-silent! unlet find_help_dialog
+unlet! g:find_help_dialog

-silent! unlet menutrans_help_dialog
-silent! unlet menutrans_path_dialog
-silent! unlet menutrans_tags_dialog
-silent! unlet menutrans_textwidth_dialog
-silent! unlet menutrans_fileformat_dialog
-silent! unlet menutrans_fileformat_choices
-silent! unlet menutrans_no_file
-silent! unlet menutrans_set_lang_to
-silent! unlet menutrans_spell_change_ARG_to
-silent! unlet menutrans_spell_add_ARG_to_word_list
-silent! unlet menutrans_spell_ignore_ARG
+unlet! g:menutrans_fileformat_choices
+unlet! g:menutrans_fileformat_dialog
+unlet! g:menutrans_help_dialog
+unlet! g:menutrans_no_file
+unlet! g:menutrans_path_dialog
+unlet! g:menutrans_set_lang_to
+unlet! g:menutrans_spell_add_ARG_to_word_list
+unlet! g:menutrans_spell_change_ARG_to
+unlet! g:menutrans_spell_ignore_ARG
+unlet! g:menutrans_tags_dialog
+unlet! g:menutrans_textwidth_dialog

 " vim: set sw=2 :
diff --git a/runtime/menu.vim b/runtime/menu.vim
index 8a98d49a1..4b893e6fc 100644
--- a/runtime/menu.vim
+++ b/runtime/menu.vim
@@ -702,9 +702,9 @@ func! s:BMShow(...)

   " remove old menu, if exists; keep one entry to avoid a torn off menu to
   " disappear.
-  silent! unmenu 
+  try | unmenu  | catch | endtry
   exe 'noremenu ' . g:bmenu_priority . ".1  l"
-  silent! unmenu! 
+  try | unmenu!  | catch | endtry

   " create new menu; set 'cpo' to include the 
   let cpo_save = 
diff --git a/src/testdir/test_menu.vim b/src/testdir/test_menu.vim
index efbb982b0..50155fe28 100644
--- a/src/testdir/test_menu.vim
+++ b/src/testdir/test_menu.vim
@@ -10,7 +10,14 @@ func Test_load_menu()
 call assert_report('error while loading menus: ' . v:exception)
   endtry
   call assert_match('browse confirm w', execute(':menu File.Save'))
+
+  let v:errmsg = ''
+
+  doautocmd LoadBufferMenu VimEnter
+  call assert_true(empty(v:errmsg), v:errmsg)
+
   source $VIMRUNTIME/delmenu.vim
+  call assert_true(empty(v:errmsg), v:errmsg)
 endfunc

 func Test_translate_menu()


-- 
Jason Franklin

-- 
-- 
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/91eafbc4-419f-4814-9f82-eab024bc5c8f%40googlegroups.com.

Odd display bug with gVim under Windows

[Christian J. Robinson]

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 or more of the 
unicode character 0x2028 called "line separator". (The attached file 
has four of them.)


- Christian

--
Christian J. Robinson  -- https://christianrobinson.name/
Reading what people write on desks can teach you a lot.abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ



x



abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ

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

[Bram Moolenaar]

> 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
> 
> And see also this Ubuntu bug I went to report again today, having forgotten 
> about the first bug
> because nobody ever responded to it:
> 
> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1852927
> 
> Since the Ubuntu folks don't seem to know what to do about this, I'm bringing 
> it here; apparently
> this list serves as the vim bug tracker.
> 
> Basically, if you mount a directory over SSH on an Ubuntu desktop, by entering
> "ssh://whatever.hostname" in the Nautilus address bar, and then try to edit 
> files there with either
> GVim (by opening them from Nautilus) or normal console vim (by doing a "cd
> /run/user/1000/gvfs/sftp:host=your.server/path/to/directory/" and then "vim 
> file.txt"), vim can't
> save the file. It just says:
> 
> "/run/user/1000/gvfs/sftp:host=your.server/path/to/directory/file.txt: E212: 
> Can't open file for
> writing"
> 
> Nano doesn't have this problem. Bash can send command output to the file. Vim 
> doesn't even have
> trouble creating and writing to the swap file. But as soon as I ":w", I get 
> the error, and I can't
> save my work.
> 
> This works fine if I build 7.4.1689 from source.
> 
> Did anyone touch file writing between then and the current version? Is there 
> some kind of extended
> log I could obtain that might explain exactly where opening the file for 
> writing goes wrong? Does
> vim want to pass some weird open flags now or something?

Wasn't this already reported, with the observation that it happens when
the group-writable bit of the permissions is not set?
Might be related to 8.0.1300, which fixes a problem with using looser
permissions when writing a file.


-- 
>From "know your smileys":
 <|-) Chinese
 <|-( Chinese and doesn't like these kind of jokes

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/201911202208.xAKM8veg004634%40masaka.moolenaar.net.

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

[interfect]

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

And see also this Ubuntu bug I went to report again today, having forgotten 
about the first bug
because nobody ever responded to it:

https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1852927

Since the Ubuntu folks don't seem to know what to do about this, I'm bringing 
it here; apparently
this list serves as the vim bug tracker.

Basically, if you mount a directory over SSH on an Ubuntu desktop, by entering
"ssh://whatever.hostname" in the Nautilus address bar, and then try to edit 
files there with either
GVim (by opening them from Nautilus) or normal console vim (by doing a "cd
/run/user/1000/gvfs/sftp:host=your.server/path/to/directory/" and then "vim 
file.txt"), vim can't
save the file. It just says:

"/run/user/1000/gvfs/sftp:host=your.server/path/to/directory/file.txt: E212: 
Can't open file for
writing"

Nano doesn't have this problem. Bash can send command output to the file. Vim 
doesn't even have
trouble creating and writing to the swap file. But as soon as I ":w", I get the 
error, and I can't
save my work.

This works fine if I build 7.4.1689 from source.

Did anyone touch file writing between then and the current version? Is there 
some kind of extended
log I could obtain that might explain exactly where opening the file for 
writing goes wrong? Does
vim want to pass some weird open flags now or something?

Please help!
-Adam

-- 
-- 
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/0e0619936512b901855407b848ecc9c1%40gmail.com.

Re: strange vim-airline bug

[Bram Moolenaar]

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 
> that presses 'r' the statusline switches to 'REPLACE' mode, which is 
> wrong. However the next time you press 'r', it won't switch to 
> 'REPLACE'.  However I see this behaviour only on Windows gvim, not in 
> the terminal.
> 
> The whole mode, is always updated every time the statusline is 
> re-evaluated, by throwing a function airline#check_mode into the 
> statusline.
> 
> What this function does essentially is check `mode(1)` and update the 
> string that will be displayed (and if the mode changes, it might as well 
> update a couple of highlighting groups).
> 
> Now, I did debug this a bit and the thing is, that apparently `mode(1)` 
> keeps returning `R`, even so, it should return 'n' after pressing `r`. I 
> am a bit at loss at why this happens and I looked at the source f_mode() 
> but don't see what would cause this. In nv_replace I see that sometimes 
> the State will be updated to `REPLACE` for the 'r' command and I guess 
> this might be the cause for that, perhaps because it recursively forces 
> a screen update, but I am wondering why I only see this with gvim and
> I don't see this behaviour with a `vim --clean -c'set stl=%{mode(1)}'`.
> 
> Anybody has an idea how to "fix" this behaviour? However, I am not sure 
> it is worth the trouble at all.

AFAIK mode() will return "R" when the user just typed "r".  It's not
really replace mode, but it's in the state similar to replace mode.

However, it may be different if CURSOR_SHAPE is not defined.  I suppose
that's a bit inconsistent.  We can change that.

-- 
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
site address in print or on TV, even though you've never had heart
problems before.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/201910311858.x9VIw6QB017753%40masaka.moolenaar.net.

strange vim-airline bug

[Christian Brabandt]

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 to 'REPLACE' mode, which is 
wrong. However the next time you press 'r', it won't switch to 
'REPLACE'.  However I see this behaviour only on Windows gvim, not in 
the terminal.

The whole mode, is always updated every time the statusline is 
re-evaluated, by throwing a function airline#check_mode into the 
statusline.

What this function does essentially is check `mode(1)` and update the 
string that will be displayed (and if the mode changes, it might as well 
update a couple of highlighting groups).

Now, I did debug this a bit and the thing is, that apparently `mode(1)` 
keeps returning `R`, even so, it should return 'n' after pressing `r`. I 
am a bit at loss at why this happens and I looked at the source f_mode() 
but don't see what would cause this. In nv_replace I see that sometimes 
the State will be updated to `REPLACE` for the 'r' command and I guess 
this might be the cause for that, perhaps because it recursively forces 
a screen update, but I am wondering why I only see this with gvim and
I don't see this behaviour with a `vim --clean -c'set stl=%{mode(1)}'`.

Anybody has an idea how to "fix" this behaviour? However, I am not sure 
it is worth the trouble at all.

Best,
Christian
-- 
Als ich die Lust zur Sinnnlichkeit entdeckte, habe ich an Gott zu
glauben aufgehört. Denn er stahl mir die Erde.
-- Simone de Beauvoir

-- 
-- 
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/20191031091912.GM24930%40256bit.org.

Re: Bug of vim script

[Tony Mechelynck]

Gotcha! In a function, a:b means "the argument named b". However,
c[a:b] is an error even outside a function.

c[a:b] is an error because a: is a known namespace (function arguments)
c[b,d] is an error because b is a known namespace (buffer variables)
c[x:y] is not an error, even with 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:
> >
> > 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]
>
> Hm, the help defines an expr8 of that type as expr8[expr1a : expr1b]
> (with spaces around the colon) then proceeds to give examples, all of
> which have only empty or numeric indices without spaces around the
> colon.
>
> Looks like spaces are better (less confusing for the Vim parser,
> maybe) whenever the index is _other_ than empty or purely numeric.
>
> Bram: Bug or feature?
>
>
> Best regards,
> Tony.

-- 
-- 
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/CAJkCKXvA5cCqP102NMrQJQ3TtY-NxhWPdvyzh0SsrA19gbgiPw%40mail.gmail.com.

Bug of vim script

[John Little]

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 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/32ea159e-10d0-4559-a3ef-f37dc078d3ee%40googlegroups.com.

Re: Bug of vim script

[Tony Mechelynck]

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(), you will get error, Undefined variable: a:b
>
> of cause this can be avoided by changing the last line to echo c[a : b]

Hm, the help defines an expr8 of that type as expr8[expr1a : expr1b]
(with spaces around the colon) then proceeds to give examples, all of
which have only empty or numeric indices without spaces around the
colon.

Looks like spaces are better (less confusing for the Vim parser,
maybe) whenever the index is _other_ than empty or purely numeric.

Bram: Bug or feature?


Best regards,
Tony.

-- 
-- 
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/CAJkCKXsuLmkGRk6X%2BVJ8cD0bUdH%3DqrYs7Y%3DE4d2s1uoGWXjz5A%40mail.gmail.com.

Bug of vim script

[Shidong Wang]

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]



--
Best regards,
wsdjeg

-- 
-- 
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/SG2PR03MB489309927D7094DEBDC7FF3FD48D0%40SG2PR03MB4893.apcprd03.prod.outlook.com.

Re: Peculiar bug with title string (simple repro)

[Tom M]

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 Vim is fully loaded up.
> 
> That is, when the VimEnter autocommands take too long with 'lz' set, the 
> title string is not updated. Obviously, this is not a command anyone
> would run.  However, my config has several VimEnter autocommands from
> plugins, and the title string is never loaded up for me when I start vim.
> 
> Let me know if you can repro!

FWIW, I am currently at Vim version 8.1.885 and I can reproduce it.

Tom

-- 
-- 
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/7d46072d-8611-4797-aec5-46cc8226b79f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Peculiar bug with title string (simple repro)

[Jason Franklin]

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 'lz' set, the 
title string is not updated. Obviously, this is not a command anyone
would run.  However, my config has several VimEnter autocommands from
plugins, and the title string is never loaded up for me when I start vim.

Let me know if you can repro!

-- 
-- 
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/28686c4e-c6c9-44ae-b38f-57d6fdab1d34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jason Franklin]

 > 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 buffer hangs
around.

> In that case it's obvious the order will change.  I think we only need
> to care about saving a session, exit and opening Vim with the same
> session.  It should be functionally in the same state then.

This sounds perfect going forward.  Makes good sense to me.

Thanks,
Jason

-- 
-- 
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/CAG%3DmhmM4O-x0E%2BFv%2BetHULPcATcrXt6JkH2ND401BuC27QKM0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bram Moolenaar]

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 test.txt
> 
> Notice that you're now editing buffer #2.  This breaks the previous
> patch I submitted to avoid extra empty buffers when loading a session.

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.

Not sure if there is any difference in using ":argadd" instead of
":badd".  The loop over all buffers near the end of makeopens() could be
done much earlier.  Or perhaps it needs to be done twice.

> Also, consider the case where several buffers are open and the user opens
> a session with :so Session.vim.  Then, cycling through the buffers won't
> work anyway because there will be several buffers open from before the
> session was loaded.

In that case it's obvious the order will change.  I think we only need
to care about saving a session, exit and opening Vim with the same
session.  It should be functionally in the same state then.

> I'm unable to come up with perfect solutions to these issues at this time.
> 
> However, the patch under discussion here seems obviously correct to me. The
> test here does a nice job of proving that the fix works, and should pass in
> all future changes to the session code to fix any of the other issues named
> here.

OK, I'll check it out.

-- 
The Feynman problem solving Algorithm:
1) Write down the problem
2) Think real hard
3) Write down the answer

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/201905222029.x4MKTc8l001098%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.

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

[Jason Franklin]

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 editing buffer #2.  This breaks the previous
patch I submitted to avoid extra empty buffers when loading a session.

Also, consider the case where several buffers are open and the user opens
a session with :so Session.vim.  Then, cycling through the buffers won't
work anyway because there will be several buffers open from before the
session was loaded.

I'm unable to come up with perfect solutions to these issues at this time.

However, the patch under discussion here seems obviously correct to me. The
test here does a nice job of proving that the fix works, and should pass in
all future changes to the session code to fix any of the other issues named
here.

-- Jason

-- 
-- 
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/b2eac877-ed07-48fa-88d6-b300eb58655b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bram Moolenaar]

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 understanding that buffer numbers are simply id
> > numbers and shouldn't be relied upon for anything other than referencing
> > a particular buffer.  The fact that the order changed shouldn't matter.
> > I'm not opposed to fixing this... I just don't get why it would be
> > important since the point of a session is to restore the views on all
> > of the files you were editing when the session was saved.
> > 
> > Am I wrong about this?
> 
> That's what I was thinking about. I am not sure that a session 
> guarantees, that buffer numbers stay stable. Perhaps that should be 
> mentioned in the documentation if one can expect it or not.

If a user is relying on the ":bnext" behavior then it matters.  E.g. if
you edit a bunch of files in sequence you can do ":brewind" and then
":bnext" to go through the same files again.

> I did have a look at fixing this, but my attempts could not make 
> guarantee exactly this. So I am actually sympathetic with closing this 
> issue, but wasn't sure.

It's tricky to get exactly the right behavior.  Perhaps using :argadd
works to create the buffers without actually opening them or any other
side effects.  Then later reset the argument list.

-- 
hundred-and-one symptoms of being an internet addict:
3. Your bookmark takes 15 minutes to scroll from top to bottom.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/201905211855.x4LIt4Ss008117%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.

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

[Tony Mechelynck]

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 are simply id
> numbers and shouldn't be relied upon for anything other than referencing
> a particular buffer.  The fact that the order changed shouldn't matter.
> I'm not opposed to fixing this... I just don't get why it would be
> important since the point of a session is to restore the views on all
> of the files you were editing when the session was saved.
>
> Am I wrong about this?

Buffer numbers are attributed in sequence from 1 upwarts to all
buffers including "hidden" and "unlisted" buffers — to all buffers
opened for editing or displaying, that is, but not to sourced scripts.
These numbers are attributed to the corresponding buffer when it is
first opened during a session; the full list can be seen with the
":ls!" command (without the exclamation mark the so-called unlisted
buffers would be omitted even though they still have an associated
buffer number). Numbers of wiped buffers are voided but not made
available for reuse during the same session; OTOH the :bdel command
clears the buffer text but retains the buffer metadata and makes the
buffer "unlisted", retaining its buffer number. So buffer numbers are
usually not kept from one session to the next. Whan can be relied upon
between saving a session and restarting it is the full-path-name of
the editfile and AFAIK that's what :mksession uses.

I don't know much about the workings of :mksession because the
generated session scripts usually do much more than I need; I start
vim as "gvim -S" but with a handwritten ~/Session.vim, so I have full
control over what it does (and doesn't do); the :scriptnames command
tells me that this script is sourced at the very end of an otherwise
completely normal startup, at the VimEnter event or extremely near it
AFAICT.

Best regards,
Tony.

-- 
-- 
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/CAJkCKXs7i5f08mY6U7eLJFvJYU9R3d3%3D5TeRXH8S1AFHNjiFSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Brabandt]

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 simply id
> numbers and shouldn't be relied upon for anything other than referencing
> a particular buffer.  The fact that the order changed shouldn't matter.
> I'm not opposed to fixing this... I just don't get why it would be
> important since the point of a session is to restore the views on all
> of the files you were editing when the session was saved.
> 
> Am I wrong about this?

That's what I was thinking about. I am not sure that a session 
guarantees, that buffer numbers stay stable. Perhaps that should be 
mentioned in the documentation if one can expect it or not.

I did have a look at fixing this, but my attempts could not make 
guarantee exactly this. So I am actually sympathetic with closing this 
issue, but wasn't sure.

Mit freundlichen Grüßen
Christian
-- 
Es gibt zwei Arten von Menschen: Solche die Glück haben und solche wie mich.

-- 
-- 
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/20190521133916.GO2769%40256bit.org.
For more options, visit https://groups.google.com/d/optout.

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

[Jason Franklin]

> 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 other than referencing
a particular buffer.  The fact that the order changed shouldn't matter.
I'm not opposed to fixing this... I just don't get why it would be
important since the point of a session is to restore the views on all
of the files you were editing when the session was saved.

Am I wrong about this?

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/32ced40b-b1dc-4510-8767-7255998e2ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Brabandt]

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?

Best,
Christian
-- 
Deine Seelenruhe läßt sich stören durch des Pöbels Stimme, die nie
recht urtreilt, nie die Dinge bei ihrem rechten Namen nennt?
-- Francesco Petrarca (Gespräche über die Weltverachtung)

-- 
-- 
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/20190521094630.GN2769%40256bit.org.
For more options, visit https://groups.google.com/d/optout.

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

[Jason Franklin]

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
--- a/src/testdir/test_mksession.vim
+++ b/src/testdir/test_mksession.vim
@@ -307,7 +307,6 @@ endfunc

 endif

-
 func Test_mksession_blank_windows()
   split
   split
@@ -323,6 +322,35 @@ func Test_mksession_blank_windows()
   call delete('Xtest_mks.out')
 endfunc

+func Test_mksession_tab_curwin()
+  only | tabonly
+
+  " tab with 2 windows
+  split
+  2 wincmd w
+  tabnew
+
+  " tab with 3 windows
+  split | split
+  3 wincmd w
+  tabnew
+
+  " tab with 4 windows
+  split | split | split
+  3 wincmd w
+  tabnew
+
+  mksession! Xtest_mks.out
+  source Xtest_mks.out
+  call assert_equal(2, tabpagewinnr(1))
+  call assert_equal(3, tabpagewinnr(2))
+  call assert_equal(3, tabpagewinnr(3))
+  call assert_equal(1, tabpagewinnr(4))
+  call delete('Xtest_mks.out')
+
+  %bw!
+endfunc
+
 if has('terminal')

 func Test_mksession_terminal_shell()


The patch below fixes the problem and cleans up some of the code a bit.


diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 16f5059..3c41b3d 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -9727,6 +9727,7 @@ makeopens(
 win_T  *edited_win = NULL;
 inttabnr;
 intrestore_stal = FALSE;
+win_T  *tab_curwin;
 win_T  *tab_firstwin;
 frame_T*tab_topframe;
 intcur_arg_idx = 0;
@@ -9842,7 +9843,8 @@ makeopens(
  * Don't use goto_tabpage(), it may change directory and trigger
  * autocommands.
  */
-tab_firstwin = firstwin;   /* first window in tab page "tabnr" */
+tab_curwin   = curwin; // current window in tab page "tabnr"
+tab_firstwin = firstwin;   // first window in tab page "tabnr"
 tab_topframe = topframe;
 if ((ssop_flags & SSOP_TABPAGES))
 {
@@ -9866,20 +9868,15 @@ makeopens(
{
tp = find_tabpage(tabnr);

+   // done all tab pages
if (tp == NULL)
-   break;  /* done all tab pages */
-   if (tp == curtab)
-   {
-   tab_firstwin = firstwin;
-   tab_topframe = topframe;
-   }
-   else
-   {
-   tab_firstwin = tp->tp_firstwin;
-   tab_topframe = tp->tp_topframe;
-   }
-   if (tabnr > 1)
-   need_tabnext = TRUE;
+   break;
+
+   tab_curwin   = (tp == curtab) ? curwin   : tp->tp_curwin;
+   tab_firstwin = (tp == curtab) ? firstwin : tp->tp_firstwin;
+   tab_topframe = (tp == curtab) ? topframe : tp->tp_topframe;
+
+   need_tabnext = (tabnr > 1);
}

/*
@@ -9938,7 +9935,7 @@ makeopens(
++nr;
else
restore_size = FALSE;
-   if (curwin == wp)
+   if (tab_curwin == wp)
cnr = nr;
}


Thanks,
Jason Franklin

-- 
-- 
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/f35df5fb-12d3-4d52-997f-2cdb0b4809ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bram Moolenaar]

Jason Franklin wrote:

> To reproduce:
> 
> $ ./vim --clean  # at latest commit on master
> 
> :set hidden shortmess+=F
> :e file1
> :e file2
> " Notice, no messages are output, as expected.
> :bn
> :bp
> " Notice fileinfo messages are output.
> 
> The main problem appears to be in the enter_buffer() function:
> 
> /* Make sure the buffer is loaded. */
> if (curbuf->b_ml.ml_mfp == NULL)/* need to load the file */
> {
> /* If there is no filetype, allow for detecting one.  Esp. useful for
>  * ":ball" used in a autocommand.  If there already is a filetype we
>  * might prefer to keep it. */
> if (*curbuf->b_p_ft == NUL)
> did_filetype = FALSE;
> 
> open_buffer(FALSE, NULL, 0);
> }
> else
> {
> if (!msg_silent)
> need_fileinfo = TRUE;   /* display file info after redraw */
> (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
> 
> When 'nohidden', the first path is executed (we have to load
> the buffer).  When 'hidden' is set, the "else" is executed, and so
> we rely on msg_silent to avoid the fileinfo message.  However, msg_silent
> is not reliably set for shortmess+=F in all scenarios.
> 
> Thus, I recommend the following patch:
> 
> diff --git a/src/buffer.c b/src/buffer.c
> index e825a99..08595a9 100644
> --- a/src/buffer.c
> +++ b/src/buffer.c
> @@ -1742,9 +1742,9 @@ enter_buffer(buf_T *buf)
>  }
>  else
>  {
> -   if (!msg_silent)
> -   need_fileinfo = TRUE;   /* display file info after redraw */
> -   (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
> +   if (!msg_silent && !shortmess(SHM_FILEINFO))
> +   need_fileinfo = TRUE;
> +   (void)buf_check_timestamp(curbuf, FALSE);
> curwin->w_topline = 1;
>  #ifdef FEAT_DIFF
> curwin->w_topfill = 0;
> 
> This fixes the problem with :bn/:bp, and all of the tests still pass.

Thanks, that looks OK.

> At this point, I also want to point out a problem with the existing test,
> reproduced below:
> 
> func Test_shortmess_F2()
>   e file1
>   e file2
>   call assert_match('file1', execute('bn', ''))
>   call assert_match('file2', execute('bn', ''))
>   set shortmess+=F
>   call assert_true(empty(execute('bn', '')))
>   call assert_true(empty(execute('bn', '')))
>   set hidden
>   call assert_true(empty(execute('bn', '')))
>   call assert_true(empty(execute('bn', '')))
>   set nohidden
>   call assert_true(empty(execute('bn', '')))
>   call assert_true(empty(execute('bn', '')))
>   set shortmess&
>   call assert_match('file1', execute('bn', ''))
>   call assert_match('file2', execute('bn', ''))
>   bwipe
>   bwipe
> endfunc
> 
> This test is correct, meaning it should pass for the commands to be considered
> working properly.  The question is: Why doesn't this test catch 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.
> :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 printed immediately.  Is my understanding correct here?

You cannot get this message from execute(), because it only happens in
the main loop, after commands have been executed.  I think the only way
is to check whether the need_fileinfo flag is set.  And that only works
if we add a function for that.

-- 
"Beware of bugs in the above code; I have only proved
it correct, not tried it." -- Donald Knuth

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_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/201905161830.x4GIU5OI021535%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.

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

[Jason Franklin]

To reproduce:

$ ./vim --clean  # at latest commit on master

:set hidden shortmess+=F
:e file1
:e file2
" Notice, no messages are output, as expected.
:bn
:bp
" Notice fileinfo messages are output.

The main problem appears to be in the enter_buffer() function:

/* Make sure the buffer is loaded. */
if (curbuf->b_ml.ml_mfp == NULL)/* need to load the file */
{
/* If there is no filetype, allow for detecting one.  Esp. useful for
 * ":ball" used in a autocommand.  If there already is a filetype we
 * might prefer to keep it. */
if (*curbuf->b_p_ft == NUL)
did_filetype = FALSE;

open_buffer(FALSE, NULL, 0);
}
else
{
if (!msg_silent)
need_fileinfo = TRUE;   /* display file info after redraw */
(void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */

When 'nohidden', the first path is executed (we have to load
the buffer).  When 'hidden' is set, the "else" is executed, and so
we rely on msg_silent to avoid the fileinfo message.  However, msg_silent
is not reliably set for shortmess+=F in all scenarios.

Thus, I recommend the following patch:

diff --git a/src/buffer.c b/src/buffer.c
index e825a99..08595a9 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1742,9 +1742,9 @@ enter_buffer(buf_T *buf)
 }
 else
 {
-   if (!msg_silent)
-   need_fileinfo = TRUE;   /* display file info after redraw */
-   (void)buf_check_timestamp(curbuf, FALSE); /* check if file changed */
+   if (!msg_silent && !shortmess(SHM_FILEINFO))
+   need_fileinfo = TRUE;
+   (void)buf_check_timestamp(curbuf, FALSE);
curwin->w_topline = 1;
 #ifdef FEAT_DIFF
curwin->w_topfill = 0;

This fixes the problem with :bn/:bp, and all of the tests still pass.

At this point, I also want to point out a problem with the existing test,
reproduced below:

func Test_shortmess_F2()
  e file1
  e file2
  call assert_match('file1', execute('bn', ''))
  call assert_match('file2', execute('bn', ''))
  set shortmess+=F
  call assert_true(empty(execute('bn', '')))
  call assert_true(empty(execute('bn', '')))
  set hidden
  call assert_true(empty(execute('bn', '')))
  call assert_true(empty(execute('bn', '')))
  set nohidden
  call assert_true(empty(execute('bn', '')))
  call assert_true(empty(execute('bn', '')))
  set shortmess&
  call assert_match('file1', execute('bn', ''))
  call assert_match('file2', execute('bn', ''))
  bwipe
  bwipe
endfunc

This test is correct, meaning it should pass for the commands to be considered
working properly.  The question is: Why doesn't this test catch 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.
: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 printed immediately.  Is my understanding correct here?

Thanks,
Jason Franklin

-- 
-- 
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/50b36ba4-ddfa-4a14-acae-dd8aa062e72f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Gary Johnson]

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.  Could there be a difference if compiled with gcc?
> > 
> > This works for me, too, using the latest Windows gvim that I had on
> > hand, 8.1.1006, installed from
> > https://github.com/vim/vim-win32-installer/releases and run as
> > 
> > gvim -N -u NONE -i NONE
> > 
> > on a Windows 10 system.
> 
> I just installed a clean vim from
> https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1052 (using 
> the 64 bit installer).

I just installed that version from your URL above and ran the
64-bit installer.  Tested using the gvim instance that pops up when
you tell the installer to show the README.txt.  Same results:
echo expand("$PATH") works fine.  Also tried single-quotes.

> running
> 
> gvim.exe --clean -c ":echo expand('$PATH')" returns just '$PATH'
> 
> could that be any shell settings?
> 
> ,
> |   shell=C:\WINDOWS\system32\cmd.exe
> |   shellcmdflag=/c
> |   shellpipe=>%s 2>&1
> |   shellquote=
> |   shellredir=>%s 2>&1
> | noshellslash
> |   shelltemp
> | Last set from c:\Program Files\Vim\vim81\defaults.vim line 26
> `

I don't see any difference between those settings and mine.

Is a puzzlement.

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.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Brabandt]

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

> You could try using system('echo %random%'), but it's likely slower.

This works at least. Still wondering, why expand() does not appear to be 
working for me correctly. Never noticed it and I believe in the past, it 
has worked for me. Hm..

Best,
Christian
-- 
Altwiedermus, der
  Jemand, der sich bei jeder Gelegenheit an herumstehende Klaviere setzt
  und "Alle meine Entchen" spielt.
-- Douglas Adams, John Lloyd, Sven Böttcher ("Der tiefere Sinn 
des Labenz")

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Christian Brabandt]

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?
> 
> This works for me, too, using the latest Windows gvim that I had on
> hand, 8.1.1006, installed from
> https://github.com/vim/vim-win32-installer/releases and run as
> 
> gvim -N -u NONE -i NONE
> 
> on a Windows 10 system.

I just installed a clean vim from
https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1052 (using 
the 64 bit installer).

running

gvim.exe --clean -c ":echo expand('$PATH')" returns just '$PATH'

could that be any shell settings?

,
|   shell=C:\WINDOWS\system32\cmd.exe
|   shellcmdflag=/c
|   shellpipe=>%s 2>&1
|   shellquote=
|   shellredir=>%s 2>&1
| noshellslash
|   shelltemp
|   Last set from c:\Program Files\Vim\vim81\defaults.vim line 26
`


Best,
Christian
-- 
Weiß ich, womit du dich beschäftigst, so weiß ich, was aus dir
werden kann.
-- Johann Wolfgang von Goethe

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bram Moolenaar]

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 have cmd.exe return a pseudo random number by using 
> %random%. However it looks like vim on windows cannot expand environment 
> variables.

expand() wasn't made for expanding environment variables.  Why not use
$PATH directly?

Not sure if $random works, might be something built into cmd.exe.  You
could try using system('echo %random%'), but it's likely slower.

-- 
"Microsoft is like Coke.  It's a secret formula, all the money is from
distribution, and their goal is to get Coke everywhere.  Open source is like
selling water.  There are water companies like Perrier and Poland Spring, but
you're competing with something that's free."   -- Carl Howe


 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.