Re: Commit: patch 9.1.0432: Ancient XPM preprocessor hack may cause build errors

[Tony Mechelynck]

On Wed, May 22, 2024 at 5:00 PM Christian Brabandt  wrote:
>
> patch 9.1.0432: Ancient XPM preprocessor hack may cause build errors
>
> Commit: 
> https://github.com/vim/vim/commit/5090f838bbcd3a13433d9fe20a94f3ce6b796eb1
> Author: Drew Vogel 
> Date:   Wed May 22 16:51:53 2024 +0200
>
> patch 9.1.0432: Ancient XPM preprocessor hack may cause build errors
>
> Problem:  Ancient XPM preprocessor hack may cause build errors.
> Solution: Simplify XPM includes and get rid of complicated #ifdef magic
>   (Drew Vogel).
>
> closes: #14816
>
> Signed-off-by: Drew Vogel 
> Signed-off-by: Christian Brabandt 
> [...]

Compiler warnings in gcc 13.2.1.20240509 in Tiny and Normal, both with
Motif GUI. Not in Tiny without GUI and not in Huge with GTK3 GUI :

gui_x11.c: In function ‘gui_mch_init’:
gui_x11.c:1372:36: warning: initialization of ‘char **’ from
incompatible pointer type ‘const char **’
[-Wincompatible-pointer-types]
 1372 | static char **magick = vim32x32;
  |^~~~
gui_x11.c:1391:24: warning: assignment to ‘char **’ from incompatible
pointer type ‘const char **’ [-Wincompatible-pointer-types]
 1391 | magick = vim48x48;
  |^
gui_x11.c:1393:24: warning: assignment to ‘char **’ from incompatible
pointer type ‘const char **’ [-Wincompatible-pointer-types]
 1393 | magick = vim32x32;
  |^
gui_x11.c:1395:24: warning: assignment to ‘char **’ from incompatible
pointer type ‘const char **’ [-Wincompatible-pointer-types]
 1395 | magick = vim16x16;
  |^


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/CAJkCKXujgxbrkVmE-3Av3Py6pjUSgk2Gth%3DtmpF2aqEE6%2BNT0A%40mail.gmail.com.

Re: bwipeout "%" fails with E94 in vim9script

[Tony Mechelynck]

On Tue, May 14, 2024 at 4:10 AM Michael Soyka  wrote:
>
> Chris,
>
> Thank you for the explanation but I don't think it explains everything.
> See below.
>
> On 05/13/2024 4:15 PM, Christian Brabandt wrote:
> > On Mo, 13 Mai 2024, Michael Soyka wrote:
> >
> >> Yes, your are right- the bwipeout command succeeds without the double
> >> quotes in vim9script.  Thanks for the solution!
> >>
> >> Given that, what feature of vim9script causes the error when double
> >> quotes are used?  In legacy vimscript, it doesn't matter if double
> >> quotes are present or not.  Perhaps this should be added to
> >> vim9-differences documentation.
> > [...]
> >>  bwipeout "%"
> > There is a slight difference here. Remember that `"` is the comment
> > character in legacy Vim Script, so what Vim actually sees and runs is:
> >
> >  :bwipeout
> Yes, I completely overlooked the end-of-line comment possibility and
> your explanation makes perfect sense.  When in doubt, RTFM!
> >
> > On Vim9 Script, I think it sees the whole argument "%" and expands to
> > the current buffer name. So by coincidence it behaves the same, but just
> > because :bw will wipe the current buffer if no argument has been given.
>
> Actually, if I disassemble the Vim9-script function (what I should have
> done earlier), what I see is :
>
>  EXEC bwipeout "%"
>
> and, if executed according to legacy rules, would be equivalent to 'EXEC
> bwipeout' and that should succeed but instead it fails with error E94.
> On the other hand, if it substitutes the buffer name, that should also
> succeed but it fails with E94.

I think (but actually I don't write Vim9 scripts myself yet so this is
pure untested theory) that at this point Vim, under Vim9 rules, looks
for a buffer actually named "%" with two double-quotes and a
percent-sign between them, i.e. the equivalent of something like
(IIUC)

   :legacy bwipeout \"\%\"

…and of course it doesn't find it.

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/CAJkCKXsB%3D%2BWooQ-iwSz0znt50qgwVV70%3DY04XBm%3DXiVoyDjgHw%40mail.gmail.com.

Re: Commit: patch 9.1.0409: too many strlen() calls in the regexp engine

[Tony Mechelynck]

On Sun, May 12, 2024 at 12:15 AM Christian Brabandt  wrote:
>
> patch 9.1.0409: too many strlen() calls in the regexp engine
>
> Commit: 
> https://github.com/vim/vim/commit/82792db6315f7c7b0e299cdde1566f2932a463f8
> Author: John Marriott 
> Date:   Sun May 12 00:07:17 2024 +0200
>
> patch 9.1.0409: too many strlen() calls in the regexp engine
>
> Problem:  too many strlen() calls in the regexp engine
> Solution: refactor code to retrieve strlen differently, make use
>   of bsearch() for getting the character class
>   (John Marriott)
>
> closes: #14648
>
> Signed-off-by: John Marriott 
> Signed-off-by: Christian Brabandt 
>
[...]

Warning in gcc 13.2.1 (openSUSE) in all builds from Huge to Tiny in
regexp.c line 645:

regexp.c: In function ‘skip_regexp_ex’:
regexp.c:645:25: warning: ‘startplen’ may be used uninitialized
[-Wmaybe-uninitialized]
  645 | size_t  startplen;
  | ^

An executable is produced.

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

Re: [SOLVED] Re: Commit: patch 9.1.0297: Patch 9.1.0296 causes too many issues

[Tony Mechelynck]

On Thu, Apr 11, 2024 at 3:21 AM Tony Mechelynck
 wrote:
>
> On Wed, Apr 10, 2024 at 4:30 PM Christian Brabandt  wrote:
> >
> > patch 9.1.0297: Patch 9.1.0296 causes too many issues
> >
> > Commit: 
> > https://github.com/vim/vim/commit/c97f4d61cde24030f2f7d2318e1b409a0ccc3e43
> > Author: Christian Brabandt 
> > Date:   Wed Apr 10 16:18:15 2024 +0200
> >
> > patch 9.1.0297: Patch 9.1.0296 causes too many issues
> >
> > Problem:  Patch 9.1.0296 causes too many issues
> >   (Tony Mechelynck, @chdiza, CI)
> > Solution: Back out the change for now
> […]
>
> After this patch, the many errors I got when opening CSS (or HTML)
> files have disappeared.
>
> Thanks Christian !
> Tony.

P.S. And yes, 'regexpengine' is set to 1 in my vimrc.

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/CAJkCKXvLUGtV6nTG%3Dzqb3S6iL8zA_3GW6ScE0Y%3DYT0c-ZCcd_Q%40mail.gmail.com.

[SOLVED] Re: Commit: patch 9.1.0297: Patch 9.1.0296 causes too many issues

[Tony Mechelynck]

On Wed, Apr 10, 2024 at 4:30 PM Christian Brabandt  wrote:
>
> patch 9.1.0297: Patch 9.1.0296 causes too many issues
>
> Commit: 
> https://github.com/vim/vim/commit/c97f4d61cde24030f2f7d2318e1b409a0ccc3e43
> Author: Christian Brabandt 
> Date:   Wed Apr 10 16:18:15 2024 +0200
>
> patch 9.1.0297: Patch 9.1.0296 causes too many issues
>
> Problem:  Patch 9.1.0296 causes too many issues
>   (Tony Mechelynck, @chdiza, CI)
> Solution: Back out the change for now
[…]

After this patch, the many errors I got when opening CSS (or HTML)
files have disappeared.

Thanks Christian !
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/CAJkCKXvcF%2BqjY6Gi%2B2R%3D%3DyN2yzW71j30zQ4yO0jjcozfjx_BhA%40mail.gmail.com.

CSS syntax suddenly produces lots of errors

[Tony Mechelynck]

Suddenly when opening a CSS file in Vim (or when opening an HTML file,
because HTML syntax invokes CSS syntax), I see a huge lot of errors.
This is at patchlevel 9.1.296 or earlier. I didn't see it a few days
ago but I'm not sure at which changeset it appeared.

I'm copying below what I saw while opening one HTLM file :

"pub/public/nb_au/nbau.contents.html"

"pub/public/nb_au/nbau.contents.html" 26L, 799B
Error detected while processing BufRead Autocommands for
"*.html"..function dist#ft#FThtml[13]..FileType Autocommands for
"*"..Syntax Autocommands for "*"..function 11_SynSet[25]..script
/usr/local/share/vim/vim91/syntax/html.vim[308]../usr/local/share/vim/vim91/syntax/css.vim:
line  129:
E409: Unknown group name:
cssValue.*,cssFunction,cssColor,cssStringQ,cssStringQQ oneline
E475: Invalid argument: cssMathGroup contained
matchgroup=cssMathParens start="(" end=")"
containedin=cssFunction,cssMathGroup
contains=cssCustomProp,cssValue.*,cssFunction,cssColor,cssStringQ,cssStringQQ
oneline
line  130:
E409: Unknown group name:
cssValue.*,cssFunction,cssURL,cssColor,cssStringQ,cssStringQQ oneline
E475: Invalid argument: cssFunction contained
matchgroup=cssFunctionName start="\<\(var\|calc\)\s*(" end=")"
contains=cssCustomProp,cssValue.*,cssFunction,cssURL,cssColor,cssStringQ,cssStringQQ
oneline
line  453:
E409: Unknown group name:
css.*Prop,cssComment,cssValue.*,cssColor,cssURL,cssImportant,cssCustomProp,cssError,cssStringQ,cssStringQQ,cssFunction,cssUnicodeEscape,cssVendor,cssDefinition,cssHacks,cssNoise
fold
E475: Invalid argument: cssDefinition transparent matchgroup=cssBraces
start='{' end='}'
contains=cssTagName,cssAttributeSelector,cssClassName,cssIdentifier,cssAtRule,cssAttrRegion,css.*Prop,cssComment,cssValue.*,cssColor,cssURL,cssImportant,cssCustomProp,cssError,cssStringQ,cssStringQQ,cssFunction,cssUnicodeEscape,cssVendor,cssDefinition,cssHacks,cssNoise
fold
line  498:
E409: Unknown group name:
css.*Attr,cssColor,cssImportant,cssValue.*,cssFunction,cssString.*,cssURL,cssComment,cssUnicodeEscape,cssVendor,cssError,cssAttrComma,cssNoise
E475: Invalid argument: cssAttrRegion start=/:/
end=/\ze\(;\|)\|}\|{\)/ contained
contains=cssPseudoClassId,css.*Attr,cssColor,cssImportant,cssValue.*,cssFunction,cssString.*,cssURL,cssComment,cssUnicodeEscape,cssVendor,cssError,cssAttrComma,cssNoise
line  502:
E409: Unknown group name:
css.*Prop,css.*Attr,cssColor,cssImportant,cssValue.*,cssFunction,cssString.*,cssURL,cssComment,cssUnicodeEscape,cssVendor,cssError,cssAttrComma,cssNoise
E475: Invalid argument: cssAttrRegion start=/transition\s*:/
end=/\ze\(;\|)\|}\)/ contained
contains=css.*Prop,css.*Attr,cssColor,cssImportant,cssValue.*,cssFunction,cssString.*,cssURL,cssComment,cssUnicodeEscape,cssVendor,cssError,cssAttrComma,cssNoise
line  527:
E409: Unknown group name:
css.*Prop,cssValue.*,cssVendor,cssAtKeyword,cssComment
nextgroup=cssDefinition
E475: Invalid argument: cssAtRule start=/@supports\>/ end=/\ze{/
skipwhite skipnl
contains=cssAtRuleLogical,cssAttrRegion,css.*Prop,cssValue.*,cssVendor,cssAtKeyword,cssComment
nextgroup=cssDefinition
Error detected while processing BufRead Autocommands for
"*.html"..function dist#ft#FThtml[13]..FileType Autocommands for
"*"..Syntax Autocommands for "*"..function 11_SynSet[25]..script
/usr/local/share/vim/vim91/syntax/html.vim:
line  312:
E409: Unknown group name:
css.*Attr,css.*Prop,cssComment,cssLength,cssColor,cssURL,cssImportant,cssError,cssString,@htmlPreproc
E475: Invalid argument: htmlCssDefinition matchgroup=htmlArg
start='style="' keepend matchgroup=htmlString end='"'
contains=css.*Attr,css.*Prop,cssComment,cssLength,cssColor,cssURL,cssImportant,cssError,cssString,@htmlPreproc


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

Patchlevel 283 mistakenly tagged v9.1.0282 on Mercurial

[Tony Mechelynck]

Patchlevel 283 (csid 67dc61280eba) was mistakenly tagged v9.1.0282 on
Mercurial, depriving changeset 3d1e6800e2a8 of its legitimate tag.

I don't know which tags, if any, are set on the git repository.

Patch numbers in src/version.c are OK.

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/CAJkCKXuqiub0K99s5YHBGZp3Eqc9rT0e%3DuuJ-XxeaU_8sRrF8g%40mail.gmail.com.

Compile warning in insexpand.c with +eval after applying patches 9.1.189-190

[Tony Mechelynck]

For instance in Normal build :

In function ‘get_complete_info’,
inlined from ‘f_complete_info’ at insexpand.c:3175:5:
insexpand.c:3123:31: warning: ‘li’ may be used uninitialized
[-Wmaybe-uninitialized]
 3123 | ret = list_append_dict(li, di);
  |   ^~~~
insexpand.c: In function ‘f_complete_info’:
insexpand.c:3095:22: note: ‘li’ was declared here
 3095 | list_T  *li;
  |  ^~

Happens also in Huge but not in Tiny. This warning does not prevent linking.
gcc version is 13.2.1 20240206 [revision
67ac78caf31f7cb3202177e6428a46d829b70f23]


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

Re: Commit: runtime(mswin): revert back the check for clipboard_working support

[Tony Mechelynck]

On Wed, Mar 13, 2024 at 4:45 PM Christian Brabandt  wrote:
>
> runtime(mswin): revert back the check for clipboard_working support
>
> Commit: 
> https://github.com/vim/vim/commit/760f664213dea9a300454992ba1589f4601d622f
> Author: Christian Brabandt 
> Date:   Wed Mar 13 16:38:16 2024 +0100
[…]

The mswin.vim script currently defines Ctrl-V and Shift-Insert in
Command-line mode but not Insert mode if has("clipboard") is found
true, but in Insert but not Command-line if it is found false. Is that
normal ?

Shouldnt cmap and inoremap be replaced by either map! or noremap! at
lines 43-44 and 60-61 of mswin.vim ?

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/CAJkCKXvYrqZyi%3DXBLgyVtoVWVeKN-z0cBb96n7ZeT9CHq6SBqA%40mail.gmail.com.

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: Proposal/Discussion on decoupling clipboard functionality from X11

[Tony Mechelynck]

On Sat, Feb 10, 2024 at 1:15 AM Luca Saccarola
 wrote:
>
>
> Ok, so option two for a possible solution is not really an option.
> Thanks for letting me know.
>
> But in your reply you aren't even acknowledge the first possible
> solution witch I think solve a legitimate problem in vim's usability,
> not to mention that this approach could unlock clipboard functionality
> even on a tty via tmux.
>
> -- Luca Saccarola

Well, I never found it really hard to compile Vim. It just takes a
little getting used to. I used to have a HowTo page about it — two,
actually, one for Unix/Linux and one for Windows — but my ISP took
down my user site, saying "Our engineers will gladly design a user
site for you". I thought I had saved the contents somewhere, but alas,
at the moment I cant't find it back, or I would have attached the
Linux page to this message.

My "smallest" Vim — named vi — is compiled with -x11 and -clipboard,
but that doesn't mean that I can't copy what it displays to the
clipboard: when running in a konsole terminal, I can use the
terminal's clipboard facilities transparently to vi (for instance,
select an area with the mouse ( which copies the selected area to the
XTERM_SELECTION i.e. the "* of my clipboard-enabled gvim) then
Ctrl-Shift-C will make konsole copy the selected area to the clipboard
(i.e. gvim's "+ register)). I'm not sure if konsole can paste into vi
and I think it cannot cut from it though.

If gpm is installed *and* your Vim instance is compiled with
+mouse_gpm, you can use the mouse to move the cursor in Vim in the
Linux console (which has no access to X11, remember) and even to
select text within Vim (and yank, put or delete it within that single
Vim instance if you hit Ctrl-O if necessary to switch from -SELECT- to
-VISUAL-) but I think you cannot paste into or from other programs.

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

Re: Proposal/Discussion on decoupling clipboard functionality from X11

[Tony Mechelynck]

On Fri, Feb 9, 2024 at 8:20 PM  wrote:
>
> Hi all,
> I would like to make a proposal for decoupling the clipboard
> functionality from X11.
>
> I've study the code base for some time but I still need some help on
> where and how exactly do this.
>
> The problem
> ===
>
> Currently in vim, on Linux, rely on X11 to interact with the system
> clipboard. This come with the limitation that vim needs to be compiled
> agaist X11. This means that the base vim package, in most distribution,
> as no way to interact with the system clipboard which is a really nice,
> sometimes essential, feature to have.
>
> If a normal user wants to have this feature they need to compile vim,
> which is not something that everyone is comfortable doing, or install
> gvim, which a lot of users don't want to have it installed.
>
> Also if you currently on wayland and use the `xterm_clipboard` feature
> the startup time is significantly higher due to the start of an xwaland
> instance on vim startup.
>
> Possible solutions
> ==
>
> 1. Rely on external tools
>
> This is what neovim does with his 'providers' [1] mechanism.
> Basically they call at runtime external tools to interact with the
> system
> clipboard (e.g. 'xclip' on Linux X11 or'pbcopy' on OSX).
>
> Advantages:
> - Low cost in maintenance and in adding support for new operating
> systems,
>   since every OS either has a CLI clipboard utility already built-in or
>   available to download.
> - It makes trivial to support more niche or esoteric setups, since you
>   can provide a simple variable to tell vim what commands to call
>   (example from neovim's implementation):
>
> let g:clipboard = {
>   \ 'name': 'myClipboard',
>   \ 'copy': {
>   \ '+': ['tmux', 'load-buffer', '-'],
>   \ '*': ['tmux', 'load-buffer', '-'],
>   \ },
>   \ 'paste': {
>   \ '+': ['tmux', 'save-buffer', '-'],
>   \ '*': ['tmux', 'save-buffer', '-'],
>   \ },
>   \ 'cache_enabled': 1,
>   \ }
>
> Disadvantages:
> - The user needs, in the worst case scenario, to install an additional
>   package (but it is better than the current experience)
> - There may be some performance penalties [2].
>
> 2. Create our own implementation for dealing with the system clipboard
>without rely on X11
>
> Advantages:
> - The user is ready to go without needing to install anything
> - There shouldn't be a big performance loss
>
> Disadvantages:
> - Maintenance in theory will be more difficult since I assume is not an
>   easy task to support all vim's targets while still support some
>   more esoteric/less common setups.
>
> Recap
> =
>
> I'm personally in favor of the neovim approach (the first one) but I
> would like to have some feedback on this.
>
> [1]: https://neovim.io/doc/user/provider.html#provider
> [2]: https://github.com/neovim/neovim/issues/11804
>

AFAIK on Unix/Linux (as opposed to Windows) the cliboard is a
functionality of X11/Wayland/etc. If you boot up without X11 (or
equivalent), for example at init runlevel 3 or equivalent, there is no
clipboard at all. Similarly, if you log in to a Linux text console
(i.e. after hitting one of Ctrl-Alt-F1 to Ctrl-Alt-F6) you have no
graphical display and no clipboard, even if X11 is otherwise running
(usually on tty7). So on Unix-like systems, you cannot access the
system clipboard without ultimately relying on X11 (or on an X11
substitute such as Wayland) because the clipboard is a function of the
[graphical] display manager. If X11 (or Wayland or…) is not running,
no one has access to a clipboard. If you are logged in to a Linux text
console with no access to the display manager, you have no access to
the clipboard (even if some other user on the same computer has one
because (s)he's logged in to X11).

Morality: T'aint broke, so don' fix it.

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/CAJkCKXuPYtMX92fsy-owjghf3Yo6pnkx4XSqLi7L%3DfdNms1Aaw%40mail.gmail.com.

[FIXED]: gcc still complains about use of uninitialized var

[Tony Mechelynck]

On Wed, Jan 31, 2024 at 10:30 PM Christian Brabandt  wrote:
>
> patch 9.1.0067: gcc still complains about use of uninitialized var
>
> Commit: 
> https://github.com/vim/vim/commit/e1cd1fda6990d612bd8f27d78f4f5d747c2dc537
> Author: Christian Brabandt 
> Date:   Wed Jan 31 22:10:50 2024 +0100
>
> patch 9.1.0067: gcc still complains about use of uninitialized var
>
> Problem:  gcc still complains about use of uninitialized var
>   ((Tony Mechelynck, after 9.1.0064/9.1.0066))
> Solution: This time init the correct variable
>
> Signed-off-by: Christian Brabandt 
[…]

The warning has now disappeared.

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

Re: Commit: patch 9.1.0066: gcc complains about use of uninitialized var

[Tony Mechelynck]

On Wed, Jan 31, 2024 at 8:45 PM Christian Brabandt  wrote:
>
> patch 9.1.0066: gcc complains about use of uninitialized var
>
> Commit: 
> https://github.com/vim/vim/commit/f2fb7dd3d3bb94fc51347c25d2829bb0a80c8719
> Author: Christian Brabandt 
> Date:   Wed Jan 31 20:29:07 2024 +0100
>
> patch 9.1.0066: gcc complains about use of uninitialized var
>
> Problem:  gcc complains about use of uninitialized var
>   (Tony Mechelynck, after 9.1.0064)
> Solution: initialize button to silence gcc
>
> Signed-off-by: Christian Brabandt 
>
After applying this patch (and all before, and changes to Filelist and
runtime/indent/racket.vim after it) I still see the following :

gui_gtk_x11.c: In function ‘scroll_event’:
gui_gtk_x11.c:2135:9: warning: ‘button’ may be used uninitialized
[-Wmaybe-uninitialized]
 2135 | gui_send_mouse_event(button, (int)event->x, (int)event->y,
  | ^~
 2136 | FALSE, vim_modifiers);
  | ~
gui_gtk_x11.c:2059:13: note: ‘button’ was declared here
 2059 | int button;
  | ^~

(The problematic line is line 2059, not line 1988. I checked my
previous email, and there too it was line 2059. GTK2 vs GTK3 ? Or
something else ?)

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/CAJkCKXs2E%3DJudd_LPzYcsV_bSV-Vnd1vzeE9d-Yrc7HPdU73eA%40mail.gmail.com.

Warning in gui_gtk_x11.c at changeset hg:d15d40bf532b — git:8fecb472c4a3f0f1ea364422424c56d1e0771b3e

[Tony Mechelynck]

gui_gtk_x11.c: In function ‘scroll_event’:
gui_gtk_x11.c:2135:9: warning: ‘button’ may be used uninitialized
[-Wmaybe-uninitialized]
 2135 | gui_send_mouse_event(button, (int)event->x, (int)event->y,
  | ^~
 2136 | FALSE, vim_modifiers);
  | ~
gui_gtk_x11.c:2059:13: note: ‘button’ was declared here
 2059 | int button;
  | ^~


Of course, this module is only included when building with +gui_gtk.
FWIW : Compiler used :
linux-tuxedo:~/.build/vim/vim-hg # gcc --version
gcc (SUSE Linux) 13.2.1 20240125 [revision
fc7d87e0ffadca49bec29b2107c1efd0da6b6ded]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



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/CAJkCKXsWa3Ev2NL9uJTYG9OS-GWB9W%2BedQo-_9UZ-gA%3DYBim5g%40mail.gmail.com.

Re: "around word" doesn't behave consistently due to white space, why?

[Tony Mechelynck]

On Fri, Jan 19, 2024 at 5:50 PM Gary Johnson  wrote:
>
> On 2024-01-16, Britton Kerin wrote:
> > The sequence 'vaw' (visual around word is how I think of it) does
> > weird things depending on white space:
> >
> >   * 'vaw' while on 'a' in 'foo bar' selects ' bar' (space followed by bar)
> >
> >   * 'vaw' while on 'a' in 'foo bar ' (with trailing space) selects
> > 'bar ' (bar followed by space)
> >
> > Why?
> >
> > I could understand (though not exact agree with the policy) if spaces
> > are being viewed as part of particular words in this context, but I
> > don't see why adding a space after bar causes the one before it to not
> > be selected.
>
> I can't find where this is documented, but Vim defines "a word", for
> most purposes, as a sequence of word characters followed by white
> space.  That definition can't hold at the end of the line, so the
> developers were left with a choice of including the preceding white
> space or not including any white space.  The choice to include the
> preceding white space is pragmatic.
>
> If you want to cut a word from one place and paste it somewhere
> else, it is convenient for that cut to include white space so that
> you don't have to remove it separately from the cut location nor add
> it separately to the paste location.  There is no following white
> space at the end of a line, so the preceding white space is included
> instead.  Also, if you delete a word at the end of a line,
> presumably you don't want to leave white space at the end of that
> line.
>
> That logic is also applied in other situations where a sequence of
> word characters is followed by a non-word character such as
> a closing parenthesis.
>
> Regards,
> Gary

It is documented under ":help aw" (aw, i.e. "a word" being the
"motion" applied after v sets characterwise visual). «Leading or
trailing white space is included, but not counted.» IOW, white space
is included on one side (but not both). If Vim doesn't find white
space where it looks for it first (after the word IIUC) then it looks
on the other side.

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

Wrong Mercurial tag and description patchno

[Tony Mechelynck]

The following is in error:

| o  changeset:   36588:730a3ddebdd2
| |  tag: v9.0.2175
| |  user:Christian Brabandt 
| |  date:Tue Dec 19 20:15:06 2023 +0100
| |  files:   src/optionstr.c src/version.c
| |  description:
| |  patch 9.0.2175: Compile error with Motif UI + mouse support
| |
| |  Commit: 
https://github.com/vim/vim/commit/18d0d29b420543efd4938619d821df7b67988de5
| |  Author: Ken Takata 
| |  Date:   Tue Dec 19 20:12:29 2023 +0100
| |
| |  patch 9.0.2175: Compile error with Motif UI + mouse support
| |
| |  Problem:  Compile error with Motif UI + mouse support (after v9.0.1262)
| |  Solution: Use correct oldval option pointer
| |
| |  Fix compilation error introduced by 9.0.1262 and found in #13704.
| |
| |  closes: #13726
| |
| |  Signed-off-by: Ken Takata 
| |  Signed-off-by: Christian Brabandt 
| |
| |

In fact, the src/version.c change of this changeset adds patch number
2176, not 2175. Alas, Mercurial descriptions being frozen forever, it
is too late to change the wrong description, but perhaps tag v9.0.2175
can be restored to where it belongs (at changeset
180f49745076e9878bd575130c9534d6e5e33ff1) and then the above changeset
tagged as v9.0.2176, maybe with a custom commit message (with
something like

hg tag -m 'Added tag v9.0.2176 for changeset
730a3ddebdd22e641f61581054a2009c2ebc044d previously wrongly tagged as
9.0.2175' -r 730a3ddebdd22e64 v9.0.2176

, or something similar, as the "hg tag" command). From the "hg help
tag" screen it is not clear to me whether this command (with its -r
parameter) would fail without the -f command-line switch.

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

Re: Mercurial "Connection refused" for "hg in" on http://hg.256bit.org/vim

[Tony Mechelynck]

On Mon, Dec 18, 2023 at 9:23 AM Christian Brabandt  wrote:
>
>
> On So, 17 Dez 2023, Tony Mechelynck wrote:
>
> > linux-tuxedo:~/.build/vim/vim-hg # hg paths
> > bitbucket = https://bitbucket.org/vim-mirror/vim
> > default = http://hg.256bit.org/vim
> > osdn = https://hg.osdn.net/view/vim/vim
> > linux-tuxedo:~/.build/vim/vim-hg # hg in || echo 'exit status' $? ; date
> > abort: error: Connection refused
> > exit status 255
> > Sun 17 Dec 10:13:26 CET 2023
> >
> > If my "default" pull repository has become invalid, please tell me.
>
> The server went down yesterday (until someone noticed it and rebooted
> it). I wasn't close to a PC to investigate but it should be back by now
> (otherwise I couldn't answer :))
>
> Thanks,
> Christian

Yeah, it came back up at some point between yesterday (Sunday)
14:51:40 CET and today (Monday) 00:57:33 CET. I hadn't missed anything
("no changes found"). I thought  it was you who had put it right and
didn't feel the need to mention it. Maybe I should have.

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/CAJkCKXvDR13O8aO9-Cz9oC9%3DnaWZm4bS%3D6EOGyL3ao2srr38qA%40mail.gmail.com.

Re: After applying patches 9.0.2168 to 9.0.2173 : warning -Wmaybe-uninitialized in vim9cmds.c (not in Tiny)

[Tony Mechelynck]

On Sun, Dec 17, 2023 at 3:26 AM Yegappan Lakshmanan  wrote:
>
> Hi Tony,
>
> On Sat, Dec 16, 2023 at 3:50 PM Tony Mechelynck 
>  wrote:
>>
>> vim9cmds.c: In function ‘compile_defer’:
>> vim9cmds.c:2051:18: warning: ‘type’ may be used uninitialized
>> [-Wmaybe-uninitialized]
>>  2051 | else if (check_func_args_from_type(cctx, type, argcount, 
>> TRUE,
>>   |  
>> ^
>>  2052 | arg_start) == FAIL)
>>   | ~~
>> vim9cmds.c:2003:18: note: ‘type’ was declared here
>>  2003 | type_T  *type;
>>   |  ^~~~
>>
>
> Which environment and compiler are you using? I don't see this warning.  
> "type" is
> initialized at line 2027 and used at line 2051.  We can initialize "type" to 
> NULL at line 2003.
> But I don't think this is necessary.
>
> Regards,
> Yegappan
>
I am using gcc 13.2.1 20231130 on openSUSE Tumbleweed, and I see this
on all +eval configurations. For instance my "normal" build is defined
as follows:

export CONF_OPT_GUI='--enable-gui=motif'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_SODIUM='--enable-libsodium'
export CONF_OPT_FEAT='--with-features=normal'
export CONF_ARGS2='--with-vim-name=vim-normal'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'

I also compile two different "huge" builds (which get the same error)
and two different "tiny" builds (which don't).

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

After applying patches 9.0.2168 to 9.0.2173 : warning -Wmaybe-uninitialized in vim9cmds.c (not in Tiny)

[Tony Mechelynck]

vim9cmds.c: In function ‘compile_defer’:
vim9cmds.c:2051:18: warning: ‘type’ may be used uninitialized
[-Wmaybe-uninitialized]
 2051 | else if (check_func_args_from_type(cctx, type, argcount, TRUE,
  |  ^
 2052 | arg_start) == FAIL)
  | ~~
vim9cmds.c:2003:18: note: ‘type’ was declared here
 2003 | type_T  *type;
  |  ^~~~


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

Re: Missing tags (again) on Mercurial

[Tony Mechelynck]

On Tue, Dec 12, 2023 at 8:41 AM Christian Brabandt  wrote:
>
>
> On Di, 12 Dez 2023, Tony Mechelynck wrote:
>
> > Something has gone wrong again.
> >
> > Remember: tags v9.0.2140 to v9.0.2142 had gone missing, but tags
> > v9.0.2143 to v9.0.2155 had been set correctly. Well, now tags
> > v9.0.2156 to v9.0.2158 have gone missing again.
> >
> > This concerns only the Mercurial .hgtags metadata (and I don't know
> > about any git metadata). In all cases the src/version.c contains the
> > full list of patch numbers.
>
> Fixed. Not sure why this happened, the script did not receive a tag when
> processing the git revision. This could happen, if I push out a new
> patch, then the hg-bridge runs and a few moments later the tag is
> pushed. However, this shouldn't happen 3 times in a row, so it's a bit
> mysterious.

IOW, a race condition between the git commit and the hg fetch (or
whatever it is called). Let's hope your fix catches it in the future.
I'll keep eyes peeled in any case.
>
> I added some extra logic to parse the subject line in addition when this
> happens again.
>
> Thanks,
> Christian

My pleasure,
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/CAJkCKXu0Hz8SaRH5TGWjmkNVdVy4P%3DVrcoegwb9ZVkcJFy6O4g%40mail.gmail.com.

Missing tags (again) on Mercurial

[Tony Mechelynck]

Something has gone wrong again.

Remember: tags v9.0.2140 to v9.0.2142 had gone missing, but tags
v9.0.2143 to v9.0.2155 had been set correctly. Well, now tags
v9.0.2156 to v9.0.2158 have gone missing again.

This concerns only the Mercurial .hgtags metadata (and I don't know
about any git metadata). In all cases the src/version.c contains the
full list of patch numbers.

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/CAJkCKXuUWnkxNUhnXhq5fkvKamTyEriNOhnX%2BRX-Jq3LReOEzg%40mail.gmail.com.

Missing tags in the latest batch of Mercurial changesets

[Tony Mechelynck]

I added the following to my Mercurial clone of the Vim distribution.
The changeset ID at the top of each new changeset may be different
from those you will get if and when you add them:

@  changeset:   36508:24a1f9015465
|  tag: tip
|  user:Tony Mechelynck 
|  date:Sun Dec 10 18:15:34 2023 +0100
|  files:   .hgtags
|  description:
|  Added tag v9.0.2142 for changeset 6e4c686b6b5b
|
|
o  changeset:   36507:fb3800f61a38
|  user:Tony Mechelynck 
|  date:Sun Dec 10 18:14:29 2023 +0100
|  files:   .hgtags
|  description:
|  Added tag v9.0.2141 for changeset 3b8089d550eb
|
|
o  changeset:   36506:3c72ab43c66d
|  user:Tony Mechelynck 
|  date:Sun Dec 10 18:13:22 2023 +0100
|  files:   .hgtags
|  description:
|  Added tag v9.0.2140 for changeset 242b964d6269
|
|

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

--- 
You received this message because you are subscribed to the Google 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/CAJkCKXuff5M6B6FRPEhWPTQbUSVgtTYUc9uc-bOHzuxFb3xBcA%40mail.gmail.com.

Re: Problem in vim-enahanced rpm for ALMALINUX8 causing segmentation fault.

[Tony Mechelynck]

On Wed, Nov 15, 2023 at 6:55 PM Tony Mechelynck
 wrote:
>
> On Tue, Oct 31, 2023 at 1:53 PM varun bali  wrote:
> >
> > Hi,
> >
> > We are facing segmentation fault in vim-enhanced rpm, when we are opening 
> > two or more files simultaneously from vim on same server, then if we reboot 
> > the system vim generates core/crashes. Attaching gdb log for same and core 
> > file for same.
> > STEPS to reproduce:
> > 1) open any two files simultaneously on same server using two diffrent 
> > terminals of same system.
> > 2) Open another 3rd terminal and do a restart there,
> > 3) After restart when system is up we see vim core is generated by 
> > vim-enhanced rpm for ALMALINUX8.
> >
> >
> > Regards,
> >
> > Varun Bali
>
> I agree that crashes should never happen; however, halting (or
> rebooting) the machine regularly while Vim (and some other programs
> including, among others, Firefox, Thunderbird and SeaMonkey) are left
> running is courting disaster.
>
> The following applies to Linux; similar procedures apply /mutatis
> mutandis/ to other platforms:
> Before you close down the system (other than by an unforeseen citywide
> power mains blackout) I recommend to:
> - quit any running instance of Vim or gvim by :qa or :xa
> - quit any running browser or mailer, usually by Ctrl-Q
> - quit any "risky" GUI, I don't have an exhaustive list of them
> - exit (log out of) any Linux console (normally it's Ctrl-Alt-F1 to
> Ctrl-Alt-F6, come back by Ctrl-Alt-F7)

-- P.S. Sometimes Ctrl-Alt-F7 is an X11 login form and Ctrl-Alt-F8 is
your GUI display session.

> - wait 5 minutes, or at least until "ps -A |less" lists no browser,
> mailer or (g)vim instance
> *Then* you can safely trigger a system shutdown or reboot.
>
> 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/CAJkCKXtMH%3DriT2u%3DS9XzRb_%2BV9ozPDotgpDg7QdqvSiqCh_7YQ%40mail.gmail.com.

Re: Problem in vim-enahanced rpm for ALMALINUX8 causing segmentation fault.

[Tony Mechelynck]

On Tue, Oct 31, 2023 at 1:53 PM varun bali  wrote:
>
> Hi,
>
> We are facing segmentation fault in vim-enhanced rpm, when we are opening two 
> or more files simultaneously from vim on same server, then if we reboot the 
> system vim generates core/crashes. Attaching gdb log for same and core file 
> for same.
> STEPS to reproduce:
> 1) open any two files simultaneously on same server using two diffrent 
> terminals of same system.
> 2) Open another 3rd terminal and do a restart there,
> 3) After restart when system is up we see vim core is generated by 
> vim-enhanced rpm for ALMALINUX8.
>
>
> Regards,
>
> Varun Bali

I agree that crashes should never happen; however, halting (or
rebooting) the machine regularly while Vim (and some other programs
including, among others, Firefox, Thunderbird and SeaMonkey) are left
running is courting disaster.

The following applies to Linux; similar procedures apply /mutatis
mutandis/ to other platforms:
Before you close down the system (other than by an unforeseen citywide
power mains blackout) I recommend to:
- quit any running instance of Vim or gvim by :qa or :xa
- quit any running browser or mailer, usually by Ctrl-Q
- quit any "risky" GUI, I don't have an exhaustive list of them
- exit (log out of) any Linux console (normally it's Ctrl-Alt-F1 to
Ctrl-Alt-F6, come back by Ctrl-Alt-F7)
- wait 5 minutes, or at least until "ps -A |less" lists no browser,
mailer or (g)vim instance
*Then* you can safely trigger a system shutdown or reboot.

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

Build failure in vim9class.c in +eval builds after updating source to 9.0.2086

[Tony Mechelynck]

For example in Normal build:

In file included from vim.h:570,
 from vim9class.c:15:
vim9class.c: In function ‘ex_class’:
vim9class.c:1563:24: error:
‘e_abstract_must_be_followed_by_def_or_static’ undeclared (first use
in this function); did you mean ‘e_abstract_must_be_followed_by_def’?
 1563 | emsg(_(e_abstract_must_be_followed_by_def_or_static));
  |^~~~
vim9class.c:1563:22: note: in expansion of macro ‘_’
 1563 | emsg(_(e_abstract_must_be_followed_by_def_or_static));
  |  ^
vim9class.c:1563:24: note: each undeclared identifier is reported only
once for each function it appears in
 1563 | emsg(_(e_abstract_must_be_followed_by_def_or_static));
  |^~~~
vim9class.c:1563:22: note: in expansion of macro ‘_’
 1563 | emsg(_(e_abstract_must_be_followed_by_def_or_static));
  |  ^
make: *** [Makefile:3510: objects/vim9class.o] Error 1
make: *** Waiting for unfinished jobs
exit status 2



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/CAJkCKXuhxV3_T62Vg1t2X36%3DRtOmMKVSqZ74V7h7LZY_QLm-zg%40mail.gmail.com.

Re: Commit: patch 9.0.2050: Vim9: crash with deferred function call and exception

[Tony Mechelynck]

On Thu, Oct 19, 2023 at 11:00 AM Christian Brabandt  wrote:
>
> patch 9.0.2050: Vim9: crash with deferred function call and exception
[...]

This patch lacks a change to src/version.c so when running the
executable, :intro and :version both say it is patchlevel 2049. The
repository tags are OK 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/CAJkCKXu00mm_vFSbRnv-nT1MpDKw_HqaRJkCymUpDuFsYP91gQ%40mail.gmail.com.

Re: [vim/vim] vim.org should redirect to www.vim.org (Issue #11259)

[Tony Mechelynck]

On Sun, Oct 2, 2022 at 7:52 PM Martin Tournoij 
wrote:

> This has been mentioned several times, but the maintainer of the DNS
> records says it doesn't work. I forgot the details.
> Fortunately several browsers handle this if you type "vim.org".
>
> Neither Firefox not Chromium on my system do this.
>
> I'm pretty sure this can be made to work, one way or the other, even if
> it's just pointing vim.org to a simple HTML page with a meta refresh tag.
>
IIRC, on Firefox and SeaMonkey it is a preference. In SeaMonkey
2.53.18b1pre for Linux64 it is «Edit → Preferences → Browser → Location Bar
→ Unknown Locations → [x] Add "www." and ".com" to the location if a web
page is not found». In Firefox Nightly 120.0a1 I tried to find it but
couldn't; but after typing vim.org followed by  in the Location bar
it said:

We can’t connect to the server at vim.org. Did you mean to go to www.vim.org
?

so it is just one click to get to the Vim homepage.

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/CAJkCKXvxEGG%2BmwAfZpTRJ8O9J9GnJRWnHQE3dGdnJVXr-%3Dse7g%40mail.gmail.com.

Compile warning -Wmaybe-uninitialized about xxd (in gcc 13.2.1) for all featuresets of Vim

[Tony Mechelynck]

cd xxd; CC="gcc" CFLAGS=" -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1" LDFLAGS="-L/usr/local/lib -Wl,--as-needed" \
make -f Makefile
make[1]: Entering directory '/root/.build/vim/vim-hg/src/shadow-tiny/xxd'
gcc  -O2 -fno-strength-reduce -Wall -Wno-deprecated-declarations
-D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -L/usr/local/lib
-Wl,--as-needed -DUNIX -o xxd xxd.c
In function ‘huntype’,
inlined from ‘main’ at xxd.c:919:16:
xxd.c:427:18: warning: ‘bt’ may be used uninitialized [-Wmaybe-uninitialized]
  427 |   if (bt < 0)
  |  ^
xxd.c: In function ‘main’:
xxd.c:367:55: note: ‘bt’ was declared here
  367 |   int c, ign_garb = 1, n1 = -1, n2 = 0, n3, p = cols, bt, b =
0, bcnt = 0;
  |   ^~
make[1]: Leaving directory '/root/.build/vim/vim-hg/src/shadow-tiny/xxd'


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/CAJkCKXu7yktniKuaz0Uv-JTwvvxdFicvoSnWk0zpkrAp%3DTNUSg%40mail.gmail.com.

Re: Warning message -Wunused-function at optionstr.c:901 in Normal and Tiny after applying patches up to 9.0.1989

[Tony Mechelynck]

Oops... to 9.0.1991.

On Thu, Oct 5, 2023 at 9:16 PM Tony Mechelynck
 wrote:
>
> gcc -c -I.   -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce
> -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=1  -o objects/optionstr.o optionstr.c
> optionstr.c:902:1: warning: ‘expand_set_opt_callback’ defined but not
> used [-Wunused-function]
>   902 | expand_set_opt_callback(
>   | ^~~
>
> 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/CAJkCKXvb87YA8CpWQK6xx9Xavng3H8f%2BMx2-ACG81p94Lu-Sdg%40mail.gmail.com.

Warning message -Wunused-function at optionstr.c:901 in Normal and Tiny after applying patches up to 9.0.1989

[Tony Mechelynck]

gcc -c -I.   -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1  -o objects/optionstr.o optionstr.c
optionstr.c:902:1: warning: ‘expand_set_opt_callback’ defined but not
used [-Wunused-function]
  902 | expand_set_opt_callback(
  | ^~~

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/CAJkCKXv8oo-48kZngfr%3DmSp2xezx44mA5ZkuxTzgTALtJ75ZKg%40mail.gmail.com.

Re: Moving the Vim Homepage on 26.09.2023

[Tony Mechelynck]

P.S. I also tried with Firefox instead of SeaMonkey, with the same (lack 
of) results.

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/b6904108-1301-48cc-b0ac-1898c4ad0dd0n%40googlegroups.com.

Re: Moving the Vim Homepage on 26.09.2023

[Tony Mechelynck]

On Tue, Sep 26, 2023 at 10:05 PM Christian Brabandt  wrote:
>
> Dear all,
> the homepage has been moved to our new provider wavestack. It should be
> much more stable and performant again.
>
> There may still be some problems with the old php code, so if you notice
> anything, please let me know and I'll fix it.
>
> Best,
> Christian
> --
> The fancy is indeed no other than a mode of memory emancipated from the order
> of space and time.  -- Samuel Taylor Coleridge
>
This is Tony Mechelynck and I'm using the mail interface because the
Google Groups interface lets me neither paste from the clipboard nor
attach a text file.

Indeed, when I browse to https://www.vim.org/ the ShowIP extension to
SeaMonkey tells me that I am at 31.172.117.18 which is the correct new
IP. The Vim Tips wiki, at vim.fandom.org, is also (as expected) still
accessible. However when I follow a link to a script, for instance
https://www.vim.org/scripts/script.php?script_id=2822 (a link found at
https://vim.fandom.com/wiki/Showing_the_ASCII_value_of_the_current_character)
which is supposed to be the page for the unicode.vim plugin, all I get
is a blank page (NOT Error 404) which (again according to ShowIP) is
supposed to come from 31.172.117.18. I have tried other script IDs, as
well as searched for scripts directly from the vim.org homepage,
always with the same (lack of) result.

Has the scripts database all gone to never-never land ? Or else, what
did I do wrong ?

FWIW, I am using a fiber connection in Brussels, Belgium, and at the moment,
* "systemctl status wicked" tells me
● wicked.service - wicked managed network interfaces
 Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled;
preset: disabled)
 Active: active (exited) since Wed 2023-09-27 00:00:12 CEST; 1h 54min ago
Process: 1267 ExecStart=/usr/sbin/wicked --systemd ifup all
(code=exited, status=0/SUCCESS)
   Main PID: 1267 (code=exited, status=0/SUCCESS)
CPU: 70ms

Sep 26 23:59:47 linux-tuxedo systemd[1]: Starting wicked managed
network interfaces...
Sep 27 00:00:12 linux-tuxedo wicked[1267]: lo  up
Sep 27 00:00:12 linux-tuxedo wicked[1267]: eth0up
Sep 27 00:00:12 linux-tuxedo systemd[1]: Finished wicked managed
network interfaces.
* "ifstatus eth0" tells me the following, which I don't understand
(except the first line saying that it is up):
eth0up
  link: #2, state up, mtu 1500
  type: ethernet, hwaddr f0:2f:74:1d:e9:8a
  config:   compat:suse:/etc/sysconfig/network/ifcfg-eth0
  leases:   ipv4 dhcp granted
  leases:   ipv6 dhcp granted, ipv6 auto granted
  addr: ipv6 2a02:a03f:64bb:3801:cfd8:dc79:7fe0:4d62/64 [auto]
  addr: ipv6 2a02:a03f:64bb:3801:f22f:74ff:fe1d:e98a/64 [auto]
  addr: ipv4 192.168.129.0/23 [dhcp]
  route:ipv4 default via 192.168.128.1 [dhcp]
  route:ipv6 default via fe80::6e3:1aff:febf:d672 metric 1024 proto ra
* If the above is only between my fibre modem and my computer, then I
have no access to the internal configuration of the modem.

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

Re: Updates on the Vim project

[Tony Mechelynck]

On Mon, Aug 28, 2023 at 9:11 PM Christian Brabandt  wrote:
>
>
> On Mo, 28 Aug 2023, Tony Mechelynck wrote:
>
> > Christian, do you have any recommendations for someone who would want
> > to continue porting the changes from git to Mercurial if you ever
> > decide to close your own Mercurial mirror, or is it not worth the
> > trouble unless this new Mercurial mirror is made public (for instance
> > by maintaining a git mirror, exporting each patch as a set of diffs,
> > and importing that to a Mercurial clone) ? (I used to have a user site
> > but my ISP has closed it for no other reason than "if you want to
> > continue having a user site after DD/MM/, get into contact with us
> > before that date and an engineer of ours will build it for you". — I
> > was perfectly happy with building it slowly but surely by FTP and I
> > prefer to mind my own business, thank you.)
>
> For a recommendation you mean what is required to set this up manually?

Yes, that's what I meant, as well as anything you might have about
warning me (or anyone) about any pitfalls you might have encountered
in the past and how to avoid them.
>
> It's currently a self-written shell script (attached)¹, that pulls the
> git mirror every 15 minutes and pushes each commit as new change to the
> mercurial repository. It used to work flawlessly (until I recently added
> pushing out mails). I reverted that part for now, let's see how well
> this works in the future. If it keeps running as good as it was in the
> past and doesn't cause any more issues, then it will just keep being
> updated.

Well, currently I run "hg in" approximately once an hour when I'm at
the computer, or not at all when I'm not; and when there is something
new, I update my clone then I compile, as a sanity test, five
different versions of Vim (they used to be huge, big, normal, small
and tiny; now that Bram has retired two of these they are huge with
GTK3 and as many features as I can, huge with GTK3 without interpreted
languages, normal with Motif and +sodium, tiny with Motif and tiny
with no GUI Sizes between 4.2 and 1.5 GB).

Thanks a lot for that script, I saved it where it won't get lost. I
think that I could understand it better with just a little study but
that it isn't really out of my mental reach.

A few days ago there were multiple heads in the "default" branch, as I
told you I think I found out how to make my clone easily usable and (I
think) compatible with your @256bit.org repo, in any case later
updates have come in with no problems. I ran "hg diff" between the
remote and the local and the only differences it found are the ones I
intentionally added in src/feature.h (add +xterm_save for which there
is no configure argument AFAIK) and in .hgignore (add runtime/doc/tags
at the very bottom, which means I have to either remove that file by
hand if there comes a change to it, or run manually "hg merge"
followed by "hg commit" if I forget).
>
> There is currently the following line commented out:
> ,
> | # echo "$patch" | hg import --bypass -
> `
> Perhaps there were some issues with backslashes or other strange stuff,
> that echo interpreted differently and caused those problems, did not
> want to experiment with this to cause more issues for users.
>
>
> ¹) I thought about adding helper scripts as an additional repository
> below the vim organization, so that basically everybody can run this on
> their own and does no longer require a central bridge. Also, it could be
> used for some help scripts (e.g. those famous scripts Bram used to
> verify runtime files updates).

It would be an idea, but then they would have to be documented, at
least with a lot of comments in the text (more than you would need
yourself) and maybe it would be too much toil for their use.
>
> Best,
> Christian

Best regards,
Tony.
> --
> What happened last night can happen again.

Yeah, that reminds me of the warning displayed in France below the
double St-Andrews cross at level crossings with double-track railway
lines:
"Un train peut en cacher un autre"
(i.e. One train can hide another one)

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

--- 
You received this message because you are subscribed to the Google 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/CAJkCKXv2KLsDkBeZtW2nNE98kyqQYL6m4WFd4ss3yg00LvygHw%40mail.gmail.com.

Re: Updates on the Vim project

[Tony Mechelynck]

On Mon, Aug 28, 2023 at 7:05 PM Christian Brabandt  wrote:
[…]
> I use git, because all the information can easily be found in the
> internet and it is still very actively developed and a lot of questions
> on how to use it have already been asked :).
>
> For mercurial I have to refresh my memories and the information on
> StackOverflow and similar seem slightly outdated.  And I just do not
> remember how to use it anymore :/
>
> But maybe it is just me...

Who knows ? For Mercurial I have preset command-lines for the commands
I use most, which are (for use with bash):
• hg in || echo "exit status" $? ; date
• hg --pager=yes --color=yes in || echo "exit status" $? ; date
• hg fetch --switch-parent || echo "exit status" $? ; date
• hg log -G -l 20
   (or some other number: number of changesets to display, starting
from most recent)
When the fetch fails at the merge phase, it may be for various reasons
so I check the stdout for a clue and generally I find it. Then I may
correct the problem and/or make the merge in several steps, each time
followed by
• hg commit -m "manual merge"
 or some other commit message
And when there is something I have forgotten, the online help is
almost as good as Vim's: for instance:
• tell me how to use the merge command
--- hg help merge
• tell me which extensions there are, and which one are installed
--- hg help extensions
etc.
>
> Thanks,
> Christian
> --
> Before you ask more questions, think about whether you really want to
> know the answers.
> -- Gene Wolfe, "The Claw of the Conciliator"

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/CAJkCKXu0abyaj_T3bU%3D1Rh6jPuRfnpipvOr2WU5-cmMjv%2Bv0XA%40mail.gmail.com.

Re: Updates on the Vim project

[Tony Mechelynck]

On Thu, Aug 24, 2023 at 4:17 PM Ernie Rael  wrote:
>
> On 23/08/24 2:44 AM, Tony Mechelynck wrote:
> > [...]
> > Well,  if the Mercurial mirror goes puff, I'll have to decide
> > either to fall back on the Vim from my distro (always somewhat behind,
> > currently 9.0.1632 and with a slightly different choice of features
> > than I would have chosen) or to start learning git seriously on a
> > fresh clone.
>
> Have you considered the "hg-git" extension? "hg-git" on PyPi. It's had a
> lot of work done in the last couple of years; it's in good shape,  with
> regular releases. Also the newer "evolve" extension is useful, I use it
> in favor of mq.
>
> -ernie

I have used the mq extension, and it is OK for the uses I have, but
since I don't do actual "development" I use it rarely, and mostly for
typos in helpfiles, which I could just as well (but maybe a little
less practically for the maintainer) mention in purely "human readable
text" such as:
in file runtime/doc/foobar.txt, at line 1234
   there is: azertyuiop wxcvbn
   there should be: qwertyuiop wxcvbn

About using Mercurial on a git repo, I see that there is a "git"
extension distributed with Mercurial, but disabled by default and
labeled as "EXPERIMENTAL" in capitals in the output of "hg help
extensions". OTOH the output of "hg --config extensions.git=  help
git" is extremely terse to the point that it seems only meant to make
people afraid of it.
If that hg-git extension you mention is so good, why haven't the
Mercurial maintainers adopted it ? I daresay I have cold feet about
it.

Christian, do you have any recommendations for someone who would want
to continue porting the changes from git to Mercurial if you ever
decide to close your own Mercurial mirror, or is it not worth the
trouble unless this new Mercurial mirror is made public (for instance
by maintaining a git mirror, exporting each patch as a set of diffs,
and importing that to a Mercurial clone) ? (I used to have a user site
but my ISP has closed it for no other reason than "if you want to
continue having a user site after DD/MM/, get into contact with us
before that date and an engineer of ours will build it for you". — I
was perfectly happy with building it slowly but surely by FTP and I
prefer to mind my own business, thank you.)


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

Re: Updates on the Vim project

[Tony Mechelynck]

On Wed, Aug 23, 2023 at 10:18 PM Christian Brabandt  wrote:
[...]
> For a similar reason and because of the mess I created with the
> mercurial mirror, I am thinking to retire the mercurial repository. I
> think it is pretty clear that nowadays git is the preferred VCS of
> choice for most programmers.

Ah, too bad. I never got around to really understand how git "thinks"
while I understand Mercurial well enough and, as with Vim, when I
forget something about Mercurial I find it easily and quickly in the
online help. Lately I used "hg help merge" to get out of the
above-mentioned "mess" and it seems more or less OK. If you retire the
Mercurial repository I shall have to scrap what I have and start again
from scratch with a fresh clone of the git master. I daresay I am not
enchanted with the prospect.

Well,  if the Mercurial mirror goes puff, I'll have to decide
either to fall back on the Vim from my distro (always somewhat behind,
currently 9.0.1632 and with a slightly different choice of features
than I would have chosen) or to start learning git seriously on a
fresh clone.

Best regards,
Tony


>
> Let me know, what you all think.
> __
> ¹) https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1
>
> Thanks,
> Christian
> --
> You are dishonest, but never to the point of hurting a friend.
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google 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/ZOZpf40nvrjjllpo%40256bit.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/CAJkCKXsugKURy-4x3gNaDVVaPDYbbnJeNd66Q%2B6yj4We-yY%3DkA%40mail.gmail.com.

Re: Commit: patch 9.0.1786: Vim9: need instanceof() function

[Tony Mechelynck]

On Thu, Aug 24, 2023 at 8:01 AM Christian Brabandt  wrote:
>
>
> On Do, 24 Aug 2023, Christian Brabandt wrote:
>
> >
> > On Mi, 23 Aug 2023, Tony Mechelynck wrote:
> >
> > > Discontinuous tagging again : notice the second line below.
> > >
> > > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Aug 23 2023 23:29:38)
> > > Included patches: 1-1783, 1786
> > > Compiled by antoine.mechely...@gmail.com
> > > Huge version with GTK3 GUI.  Features included (+) or not (-):
> > > [...]
> >
> > Yeah I noticed. hg refuses to sync the git patches
>
> But should be in sync now again

Well, once again I had to merge manually because of several heads. I
hope I ended up at the right place (i.e. with the right "current
directory") even if not by the canonical way (i.e. maybe I merged in a
different sequence). At least I arrived at a sequential "list of
patches" in version.c.

>
> Best,
> Christian
> --
> I don't do it for the money.
> -- Donald Trump, Art of the Deal
I don't do it, period.


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

Re: Commit: patch 9.0.1786: Vim9: need instanceof() function

[Tony Mechelynck]

On Wed, Aug 23, 2023 at 9:15 PM Christian Brabandt  wrote:
>
> patch 9.0.1786: Vim9: need instanceof() function
>
> Commit: 
> https://github.com/vim/vim/commit/afe0466fb1695fa8b9782eea8a8e9f9540d4cb85
> Author: LemonBoy 
> Date:   Wed Aug 23 21:08:11 2023 +0200
[...]

Discontinuous tagging again : notice the second line below.

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Aug 23 2023 23:29:38)
Included patches: 1-1783, 1786
Compiled by antoine.mechely...@gmail.com
Huge version with GTK3 GUI.  Features included (+) or not (-):
[...]

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

Re: Patch 9.0.1678

[Tony Mechelynck]

15 hours after Christian's message, the runtime/filetype.vim at
https://github.com/vim/vim/tree/master/runtime still seems not to have
been updated since patchlevel 9.0.1668 — and of course patch 1678
hasn't yet appeared on the Mercurial repository either, because it
gets its updates from the git master.

I wonder what went wrong.

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

Re: :tearoff command not available in Vim 9.0.1664 for Linux even when exists(':tearoff') == 2

[Tony Mechelynck]

On Mon, Jun 26, 2023 at 1:31 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > • In Normal gvim with Motif GUI in GUI mode, :echo exists(':tearoff')
> > gives 0 but menus can be teared off from the menu bar with the mouse
> > • In the same in Console mode, :echo exists(':tearoff') gives 2
> > • In Huge gvim with GTK3 GUI (where menus cannot be teared off with
> > the mouse), :echo exists(':tearoff') gives 2 even in the GUI.
> > • In all these cases, :tearoff PopUp (or with any other menu name)
> > gives error "E319: Sorry, the command is not available in this
> > version."
> >
> > In my humble opinion, E319 ought never to happen if a prior check with
> > exists(':command') has given 2.
>
> This is a special case: The command is in the list of supported
> commands, but it is only actually implemented for MS-Windows.
>
> > :help tear-off-menus says that tearoff menus are available with Motif
> > or GTK2 GUIs but not GTK3 version 3.4 or later and indeed, I can tear
> > off menus (but only with the mouse) in Motif gvim but not in GTK3
> > 3.24.38.
> >
> > • Maybe the Motif Vim should evaluate exists(':tearoff') to zero even
> > when not in GUI mode?
>
> Having exists() return non-zero for a command that doesn't work is
> misleading.  However, returning zero also isn't correct, since Vim does
> know about the command.

Hm… Vim does know about the command, but it is not implemented in the
current build. Similarly, Vim knows about the +python and +python3
features, and in a Vim built with -python -python3 the expressions
has('python') has('python3') both return 0 (which is what I expected)
but "echo exists(':python') exists(':python3') exists(':pythonx')"
returns 2 0 0 which I find even more misleading. I would have expected
them all to be "undefined" (and therefore zero, as mentioned at
builtin.txt line 2307) whenever they are excluded at compile-time in
the current Vim.

>  Currently the returned values are:
>
> 1  for match with start of a command
> 2  full match with a command
> 3  matches several user commands
>
> That doesn't leave room for a new value.  The best I can think of would
> be to return one:
>
> 1  for match with start of a command
>and full match with command that is
>not implemented
>
> Any better ideas?

I would have preferred 0 for "unknown, or not included in the current
build" similarly to how has() behaves, but the above is better than
nothing.
>
> > • Maybe the GTK3 GUI with GTK3 3.4 or later should evaluate
> > exists('tearoff') to zero in all cases?
> > • Maybe the help for :tearoff (which is in gui_w32.txt) should insist
> > on the fact that this command applies only to Windows?
>
> It won't hurt to state that explicitly.

OK. Maybe it could have been regarded as "implicit" but me too I
believe that saying it explicitly won't hurt.
>
> > • Or, contrariwise, maybe the :tearoff command should be extended to
> > Motif and GTK2 GUIs, which have tearoff menus (but only by mouse
> > AFAICT)?
>
> I do not know how to do that.  Perhaps there is a function for that, I
> haven't attempted finding it.

Well, at least we can tear off menus by mouse (but only in these two
GUIs and only in GUI mode). OK, leave that for "whoever whenever,
low-priority" then.
>
> --
> Google is kind of like Dr. Who's Tardis; it's weirder on the
> inside than on the outside...

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/CAJkCKXuzf%3D-Hxy2ouPLkF8_XYHMNkreNaYkW4WyUKe-PYgUy0g%40mail.gmail.com.

Re: After recent "Normalize line endings" changeset (448aef880252 Mercurial-only AFAICT) Make says file missing

[Tony Mechelynck]

On Mon, Jun 26, 2023 at 1:14 PM Christian Brabandt  wrote:
>
>
> On Mo, 26 Jun 2023, Tony Mechelynck wrote:
>
> > On Mon, Jun 26, 2023 at 12:10 PM Christian Brabandt  wrote:
> > >
> > >
> > > On Mo, 26 Jun 2023, Tony Mechelynck wrote:
> > >
> > > > At hg CSID 448aef880252 by Christian Brabandt: Problem detected at or
> > > > near src/Makefile line 1972. I believe there is a problem of some kind
> > > > with src/auto/config.mk or src/shadow/auto/config.mk. Neither plain
> > > > "make" nor "make reconfig" work. For the time being I have updated
> > > > back to previous changeset (hg CSID d110c049e688 by Bram Moolenaar)
> > > > then "make reconfig" works.
> > > >
> > > > Vim had come up unexpectedly with a 3-way diff in src/feature.h on a
> > > > line with one change by me when trying to merge 448aef880252 with my
> > > > (few) own changes. What was this changeset about? What exactly did it
> > > > change in all those files? Maybe I did some false maneuver.
> > >
> > > I am sorry if I caused this. I noticed today, that my local git worktree
> > > showed all files as using wrong line-endings. I don't know why and I
> > > tried fiddling with git config core.autocrlf true/false but neither
> > > worked.
> > >
> > > So I did git reset --hard to have a clean state but then of course hg
> > > noticed the change in the file endings and complained. So I quickly
> > > commited those changes there to not cause any issues when further
> > > patches are received.
> > >
> > > I have no idea why this happened and it was just my way to quickly fix
> > > an issue I noticed.
> > >
> > > Is there anything in particular I need to rollback or fix?
> >
> > I don't know. What were those "wrong line endings"? CR+LF, LF only,
> > something else ? If you (temporarily) go back one changeset (hg
> > d110c049e688, no that one has no git CSID listed, then hg
> > 9e28090dd246  git  590aae35575cbd74d80c41d87fc647f2812aad70) are line
> > endings OK?
> >
> > Another idea: After this massive change, can you compile Vim with no
> > problems from your hg repo?
> >
> > If I knew exactly what these "wrong line endings" were and "to what"
> > they were changed I would be better armed to fix my problems the way
> > they should.
>
> I don't know what happened. src/auto/configure had dos line endings and
> therefore the shell wasn't found. I think I managed to fix the git
> worktree and effectively reverted the hg commit as well. Please check
>
> Best,
> Christian

Maybe it was my fault after all. Thus time when the 3-way vimdiff came
up (with only one line different) I modified all 3 windows so they all
showed what I wanted then I exited by :xa — so no matter which one the
Mercurial merge picked it would be the "good" one.

I also fetched a few new changesets by Bram coming after your two huge
"line endings" changesets (updating to 9.0.1668). This time a simple
"make" called configure (with my preset environment variables,
different in each build-specific shadow directory and shell) then
apparently recompiled all modules, and all 5 builds proceeded to
normal end-of-job.

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

Re: After recent "Normalize line endings" changeset (448aef880252 Mercurial-only AFAICT) Make says file missing

[Tony Mechelynck]

On Mon, Jun 26, 2023 at 12:10 PM Christian Brabandt  wrote:
>
>
> On Mo, 26 Jun 2023, Tony Mechelynck wrote:
>
> > At hg CSID 448aef880252 by Christian Brabandt: Problem detected at or
> > near src/Makefile line 1972. I believe there is a problem of some kind
> > with src/auto/config.mk or src/shadow/auto/config.mk. Neither plain
> > "make" nor "make reconfig" work. For the time being I have updated
> > back to previous changeset (hg CSID d110c049e688 by Bram Moolenaar)
> > then "make reconfig" works.
> >
> > Vim had come up unexpectedly with a 3-way diff in src/feature.h on a
> > line with one change by me when trying to merge 448aef880252 with my
> > (few) own changes. What was this changeset about? What exactly did it
> > change in all those files? Maybe I did some false maneuver.
>
> I am sorry if I caused this. I noticed today, that my local git worktree
> showed all files as using wrong line-endings. I don't know why and I
> tried fiddling with git config core.autocrlf true/false but neither
> worked.
>
> So I did git reset --hard to have a clean state but then of course hg
> noticed the change in the file endings and complained. So I quickly
> commited those changes there to not cause any issues when further
> patches are received.
>
> I have no idea why this happened and it was just my way to quickly fix
> an issue I noticed.
>
> Is there anything in particular I need to rollback or fix?

I don't know. What were those "wrong line endings"? CR+LF, LF only,
something else ? If you (temporarily) go back one changeset (hg
d110c049e688, no that one has no git CSID listed, then hg
9e28090dd246  git  590aae35575cbd74d80c41d87fc647f2812aad70) are line
endings OK?

Another idea: After this massive change, can you compile Vim with no
problems from your hg repo?

If I knew exactly what these "wrong line endings" were and "to what"
they were changed I would be better armed to fix my problems the way
they should.

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

After recent "Normalize line endings" changeset (448aef880252 Mercurial-only AFAICT) Make says file missing

[Tony Mechelynck]

At hg CSID 448aef880252 by Christian Brabandt: Problem detected at or
near src/Makefile line 1972. I believe there is a problem of some kind
with src/auto/config.mk or src/shadow/auto/config.mk. Neither plain
"make" nor "make reconfig" work. For the time being I have updated
back to previous changeset (hg CSID d110c049e688 by Bram Moolenaar)
then "make reconfig" works.

Vim had come up unexpectedly with a 3-way diff in src/feature.h on a
line with one change by me when trying to merge 448aef880252 with my
(few) own changes. What was this changeset about? What exactly did it
change in all those files? Maybe I did some false maneuver.

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

:tearoff command not available in Vim 9.0.1664 for Linux even when exists(':tearoff') == 2

[Tony Mechelynck]

• In Normal gvim with Motif GUI in GUI mode, :echo exists(':tearoff')
gives 0 but menus can be teared off from the menu bar with the mouse
• In the same in Console mode, :echo exists(':tearoff') gives 2
• In Huge gvim with GTK3 GUI (where menus cannot be teared off with
the mouse), :echo exists(':tearoff') gives 2 even in the GUI.
• In all these cases, :tearoff PopUp (or with any other menu name)
gives error "E319: Sorry, the command is not available in this
version."

In my humble opinion, E319 ought never to happen if a prior check with
exists(':command') has given 2.

:help tear-off-menus says that tearoff menus are available with Motif
or GTK2 GUIs but not GTK3 version 3.4 or later and indeed, I can tear
off menus (but only with the mouse) in Motif gvim but not in GTK3
3.24.38.

• Maybe the Motif Vim should evaluate exists(':tearoff') to zero even
when not in GUI mode?
• Maybe the GTK3 GUI with GTK3 3.4 or later should evaluate
exists('tearoff') to zero in all cases?
• Maybe the help for :tearoff (which is in gui_w32.txt) should insist
on the fact that this command applies only to Windows?

• Or, contrariwise, maybe the :tearoff command should be extended to
Motif and GTK2 GUIs, which have tearoff menus (but only by mouse
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/CAJkCKXv8%2BALNFPYukMOkYUKYW3Jazn55ytQx4tA3nTweqVNmig%40mail.gmail.com.

Re: Patch 9.0.1638

[Tony Mechelynck]

On Sat, Jun 17, 2023 at 4:01 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.1638 (after 9.0.1637)
> Problem:crypt tests hang and cause memory errors
> Solution:   Move variable to start of function.
> Files:  src/fileio.c
[...]

This gives me a compiler warning in the Tiny build, as follows:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/fileio.o fileio.c
fileio.c: In function ‘readfile’:
fileio.c:221:17: warning: variable ‘eof’ set but not used
[-Wunused-but-set-variable]
  221 | int eof = FALSE;
  | ^~~


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/CAJkCKXuvvzPN6MOd%2BGgxz5pbcPoYE6z0ReM1x2h%3DxMg%3Ds3N2Kg%40mail.gmail.com.

Re: X11 requirements -- solved

[Tony Mechelynck]

On Thu, Jun 15, 2023 at 5:24 PM tooth pik  wrote:
>
> i thought i had exhausted google, but with yet another stab at it, in 
> vim.fandom.com i found reference to two packages i didn't have:  libxpm-dev 
> and libxt-dev
>
> i added both and boom, i again have a gui -- i don't know if i needed both of 
> them, but now it builds fine
>
> i apologize for the noise

I think you need them both, to go with the -lXpm -lXt arguments found
immediately before -lX11 on the gvim "Linking:" line.

Congratulations!
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/CAJkCKXt5O2HZLY4dYRjrooRWYebH9Tz5G4vcHMfScpKJCwysWg%40mail.gmail.com.

Re: X11 requirements list

[Tony Mechelynck]

On Thu, Jun 15, 2023 at 4:09 PM tooth pik  wrote:
>
> some months ago i managed to break gvim messing around doing i wish i 
> remembered what, probably something to do with getting nvidia drivers to work 
> on my system
>
> for me vim no longer builds with X11, vim builds fine but no gui
>
> is there somewhere a list of packages required for X11 to successfully link 
> into vim?  my system (currently opensuse 15.4, gtk3, kde) shows X11 as fine 
> itself, everything else seems fine, even the nvidia drivers are working up to 
> snuff
>
> all myconfig will tell me is it can't find X11
>
> any help will be appreciated
>
> tia
>
> toothpik

That's strange. On openSUSE Tumbleweed I can build the following
versions of Vim with no problem:
9.0.1633 (Huge or Normal) with GTK3 GUI
9.0.1633 (Tiny) with Motif GUI or with no GUI

Failure to build is usually due to a missing "development" package. I
suggest to use the YaST "System Management" subsystem to search for
the following packages, and install them if they aren't yet:
• libX11-devel
• gtk3-devel
• any additional packages suggested by YaST to make them work
Without the former you can't compile for X11; without the latter you
can't compile for GTK3 though you might be able to compile for another
GUI such as (for example) Motif.

If you still can't compile gvim with "make reconfig" (and the
appropriate environmrnt variables) once these packages are installed,
please come back here, pasting into your email the exact error
messages as printed by configure.

FYI, here is how I configure my "huge but not maximum" gvim by means
of environment variables; this allows me to leave the Makefile and the
src/Makefile unchanged from the Vim distribution. If you want to use
this script, you will have to edit it, at least to replace my name by
yours, and possibly to add or remove some configuration settings (for
the environment variable names, see the first part of the
src/Makefile):

# configuration settings for Vim
# this script is to be sourced (not executed) by the bash shell
# which is going to "make" Vim in the src directory
export CONF_OPT_GUI='--enable-gui=gtk3'
# the multibyte feature itself (+multi_byte) is now always enabled
export CONF_OPT_TERMINAL='--disable-terminal'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'


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/CAJkCKXs4xB9vvJ48S%2BQz3%3Df41rfiKnpDAq7xdUssyXQBtRUqSQ%40mail.gmail.com.

Re: Vim configured with both --with-features=normal and --enable-libsodium ends up with libsodium linked in but the +sodium feature disabled

[Tony Mechelynck]

On Mon, May 8, 2023 at 11:09 PM Bram Moolenaar  wrote:
[...]
> This is indeed strange.  The configure check for sodium defaults to only
> checking when using "huge" features.  That makes sense, it is something
> advanced, not always needed.  But in the src/feature.h file the
> FEAT_HUGE macro is checked again.  Thus when overriding the configure
> check to check for sodium also with "normal" features, it gets excluded
> there.  I don't see any reason for that.
>
> I'll make a patch to change this.  Let me know if I missed a situation
> where the existing logic did make sense.

After applying patch 1528, the procedure described earlier (with
--with-features=normal and also --enable-libsodium) does indeed build
a Normal Vim with +sodium compiled-in. Thanks!

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/CAJkCKXsF185LUBwEeTATiojuO%2B7MP%3DTvHFiG%2BRNH2cKNqsFq1Q%40mail.gmail.com.

Re: Same number different colors for ctermbg and ctermfg

[Tony Mechelynck]

On Thu, May 4, 2023 at 12:14 PM Enan Ajmain <3nan.ajm...@gmail.com> wrote:
>
> Hi,
>
> For the value 7, ctermfg and ctermbg gives different colors. 'ctermfg=7'
> gives non-bold white, which is expected.  But 'ctermbg=7' gives bold
> Black color.  I'm assuming there is a if-conditional somewhere that's
> causing this distinction.  If so, where is the conditional in the source
> code?  If not, why is this happening?
>
> P.S.  I'm on Windows.  I have a Linux laptop but haven't checked if this
> behavior is reproducible on that OS.
>
> --
> Enan

Try to explicitly remove bold, as follows:
:hi User1 cterm=NONE ctermbg=red ctermfg=7 gui=NONE guibg=#FF guifg=#77
:hi User2 cterm=NONE ctermbg=7 ctermfg=red gui=NONE guibg=#77 guifg=#FF
(Of course in order to see something we cannot set both ctermbg=7 and
ctermfg=7 on the same highlight group).
IIUC a Vim instance compiled with no GUI should ignore the gui= guibg=
guifg= settings but I don't like to define a highlight group with one
of cterm and gui colors and not the other.
You may replace User1 and User2 by whatever suits you, but if the
groups you set are already defined you may need (I'm not sure) to
clear them first with ":hi clear "; then set the highlight for
two regions with text to the two highlight groups so defined.
Does the problem disappear this way, with cterm=NONE prefixed to the
ctermbg and ctermfg settings?

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/CAJkCKXvhHbcoZK-%3Dw_AMBAUNyeq3g-wJDLYk4K3F3jnQKy0oBQ%40mail.gmail.com.

Re: Documentation update: How to set a font

[Tony Mechelynck]

On Sat, Apr 29, 2023 at 11:10 PM Bram Moolenaar  wrote:
[…]
> We don't support GTK 1 anymore, suggesting code in the help for not
> implemented functionality doesn't make much sense.

OK. Well, in that case we should test for "if has('gui_gtk')" (and not
gtk2) rather high in the list, suppress the comment about GTK1 but not
the "elseif has('x11')" and its XLFD which is for other X11 including
e.g. Motif; these come, of course, after GTK has been taken care of.

gui_kde has long lost any maintainer it ever had. Do we still support
Photon? IIRC, the 'guifont' for that platform resembles the one for
Windows but isn't identical. Yes, there is a whole *photon-fonts*
section in the help (in the os_qnx.txt helpfile).

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/CAJkCKXujEX%3D4JmHruTePeQme7ae-6MoWQdCMGpZDAAT9dS2muQ%40mail.gmail.com.

Re: Documentation update: How to set a font

[Tony Mechelynck]

 On Sat, Apr 29, 2023 at 7:02 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > Under *setting-guifont*, in file runtime/doc/gui.txt (or
> > $VIMRUNTIME/doc/gui.txt) line 1229
> >   there is
> > if has("gui_gtk2")
> >   there should be
> > if has("gui_gtk2") || has("gui_gtk3")
> > otherwise the 'guifont' option will be given a wrong font name
> > (selected by has("x11")) in gvim with GTK3 GUI.
>
> It should then be possible to just check for "gui_gtk", that is an "or"
> of "gui_gtk2" and "gui_gtk3".
>
> There is a comment just below this:
>
> " Also for GTK 1
>
> I don't think this exists anymore, and we don't need to cover everything
> in this example.  It's also misleading, since the check for "gui_gtk2"
> actually would also catch GTK 1.

Oh? It used not to.

In the past (quite some years ago), when I used GTK1 on Linux,
• has("gui_gtk") would catch any GTK version
* has("gui_gtk2") would catch only GTK2. The Vim help mentioned it as
experimental but it was less and less so as time passed, and IIRC at
some point that mention was removed.
• GTK3 didn't exist yet.

That's when I wrote a VimTip (the precursor to the *setting-guifont*
help entry) and posted it to vim.org. I didn't use has("gui_gtk")
because GTK1 needed to be treated differently than GTK2 so I tested
for GTK2 first (GTK3 didn't exist yet), then for a few others, then
for has("x11") meaning "other X11 including GTK1" and assumed Windows
in the bottom-most "else" branch. MacVim, when it was later developed,
needed an other …elseif… but I wasn't competent to write it.

Since then has("gui_gtk3") has been added. Its use is very similar to
that of GTK2 but there are differences (e.g. Gnome3 is included in
GTK3 but Gnome2 had to be specified to configure in addition to GTK2;
but the font settings are identical).

AFAIK 'guifont' for Motif still has to be an XLFD so if we can have
the obsolete GTK1 fall into that branch of the if … elseif … elseif …
else … endif, then why not?

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/CAJkCKXu56a%3Ds6%3DOwOzaf%2BV-vjC60nKub%2BJj2omhy2tMwPxUAMg%40mail.gmail.com.

Documentation update: How to set a font

[Tony Mechelynck]

Under *setting-guifont*, in file runtime/doc/gui.txt (or
$VIMRUNTIME/doc/gui.txt) line 1229
  there is
if has("gui_gtk2")
  there should be
if has("gui_gtk2") || has("gui_gtk3")
otherwise the 'guifont' option will be given a wrong font name
(selected by has("x11")) in gvim with GTK3 GUI.

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

Re: Compiler warnings in Vim with +eval and +gui_gtk after applying patches 1492 to 1496

[Tony Mechelynck]

On Sat, Apr 29, 2023 at 3:26 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > I'm including the full log because "make -j4" might display the
> > warnings otherwise than where they belong.
> >
> > linux-tuxedo:~/.build/vim/vim-hg/src/shadow-normal # (make -j4 || echo
> > 'exit status' $? ; date) 2>&1 |tee -a make.log
>
> [...]
>
> > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> > -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > -I/usr/include/harfbuzz -I/usr/include/freetype2
> > -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
> > -I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
> > -I/usr/include/wayland -I/usr/include/libxkbcommon
> > -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
> > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
> > -I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
> > -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
> > -D_FORTIFY_SOURCE=1-o objects/memline.o memline.c
>
> [...]
>
> > memline.c: In function ‘adjust_text_props_for_delete’:
> > memline.c:3667:43: warning: ‘this_props_len’ may be used uninitialized
> > [-Wmaybe-uninitialized]
> >  3667 | for (done_this = 0; done_this < this_props_len;
> >   | ~~^~~~
> > memline.c:3626:17: note: ‘this_props_len’ was declared here
> >  3626 | int this_props_len;
> >   | ^~
> > In file included from vim.h:244,
> >  from memline.c:45:
> > memline.c:3674:56: warning: ‘text’ may be used uninitialized
> > [-Wmaybe-uninitialized]
> >  3674 | mch_memmove(_this, text + textlen + done_this,
> > os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
> >   430 | # define mch_memmove(to, from, len) memmove((char *)(to),
> > (char *)(from), len)
> >   |
> > ^~~~
> > memline.c:3627:18: note: ‘text’ was declared here
> >  3627 | char_u  *text;
> >   |  ^~~~
> > memline.c:3674:56: warning: ‘textlen’ may be used uninitialized
> > [-Wmaybe-uninitialized]
> >  3674 | mch_memmove(_this, text + textlen + done_this,
> >   |^
> > os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
> >   430 | # define mch_memmove(to, from, len) memmove((char *)(to),
> > (char *)(from), len)
> >   |
> > ^~~~
> > memline.c:3628:17: note: ‘textlen’ was declared here
> >  3628 | size_t  textlen;
> >   | ^~~
>
> These warnings are all because the compiler doesn't recognize that the
> block after "if (!did_get_line)" is always executed, since did_get_line
> is initialized to FALSE.  These are bogus warnings.
>
> The warnings can be avoided by initializing the variables.  But this
> should not be needed.  It may also be confusion and even mistakes when
> later changing this code.
>
> I cannot reproduce these warnings.  I assume it depends on the version
> of the compiler.  For me "gcc --version" results in:
>
> gcc (Ubuntu 12.2.0-3ubuntu1) 12.2.0
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For me "gcc --version" results in the following (I'm including the
shell prompts before and after to display the empty line):

linux-tuxedo:~/.build/vim/vim-hg # gcc --version
gcc (SUSE Linux) 13.0.1 20230421 (prerelease) [revision
f980561c60b0446cc427595198d7f3f4f90e0924]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

linux-tuxedo:~/.build/vim/vim-hg #

The 40-nybble string after "revision" should of course be on the same
line; my mailer puts it on the next line for the sake of width.

I have reconfigured my "normal" build to use Motif GUI (now and in the
future) rather than GTK3 so I'll have a build with +eval and a non-GTK
GUI. As I suppose you would expect, these warnings are still present
in its "make reconfig" listing.

I can live with bogus warnings, but of course they make "true"
warnings harder to notice, especially if they happen in the same
module.

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 

Compiler warnings in Vim with +eval and +gui_gtk after applying patches 1492 to 1496

[Tony Mechelynck]

I'm including the full log because "make -j4" might display the
warnings otherwise than where they belong.

linux-tuxedo:~/.build/vim/vim-hg/src/shadow-normal # (make -j4 || echo
'exit status' $? ; date) 2>&1 |tee -a make.log
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/evalfunc.o evalfunc.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/memline.o memline.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/popupmenu.o popupmenu.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/vim9instr.o vim9instr.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/gui_gtk_x11.o gui_gtk_x11.c
memline.c: In function ‘adjust_text_props_for_delete’:
memline.c:3667:43: warning: ‘this_props_len’ may be used uninitialized
[-Wmaybe-uninitialized]
 3667 | for (done_this = 0; done_this < this_props_len;
  | ~~^~~~
memline.c:3626:17: note: ‘this_props_len’ was declared here
 3626 | int this_props_len;
  | ^~
In file included from vim.h:244,
 from memline.c:45:
memline.c:3674:56: warning: ‘text’ may be used uninitialized
[-Wmaybe-uninitialized]
 3674 | mch_memmove(_this, text + textlen + done_this,
os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
  430 | # define mch_memmove(to, from, len) memmove((char *)(to),
(char *)(from), len)
  |^~~~
memline.c:3627:18: note: ‘text’ was declared here
 3627 | char_u  *text;
  |  ^~~~
memline.c:3674:56: warning: ‘textlen’ may be used 

Re: Finding the Motif libs

[Tony Mechelynck]

On Wed, Apr 12, 2023 at 6:09 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > > > According to the YaST installer, openSUSE Tumbleweed package libXm4
> > > > titled "Motif runtime library" installs (only) files
> > > > /usr/lib64/libXm.so.4 and /usr/lib64/libXm.so.4.0.4
> > > >
> > > > so I did
> > > >
> > > > pushd /usr/lib64
> > > > ls -l libXm*
> > > >
> > > > which answered
> > > >
> > > > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so -> libXm.so.4.0.4
> > > > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so.4 -> libXm.so.4.0.4
> > > > -rwxr-xr-x 1 root root 3021784 Mar 19 23:38 libXm.so.4.0.4
> > > > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so -> libXmu.so.6.2.0
> > > > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so.6 -> 
> > > > libXmu.so.6.2.0
> > > > -rwxr-xr-x 1 root root  113936 Mar 19 23:28 libXmu.so.6.2.0
> > > > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so -> 
> > > > libXmuu.so.1.0.0
> > > > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so.1 -> 
> > > > libXmuu.so.1.0.0
> > > > -rwxr-xr-x 1 root root   22568 Mar 19 23:28 libXmuu.so.1.0.0
> > > >
> > > > I think only the first three lines in this list are relevant. IOW on
> > > > my system there are three files answering to /usr/lib64/libXm.so* in
> > > > your list, two of which are soft links to the third one. IIUC by
> > > > giving configure the argument --with-motif-lib=-lXm it doesn't search
> > > > for the lib but just passes -lXm to the linker, which finds
> > > > /usr/lib64/libXm.so -> libXm.so.4.0.4 and happily uses that (as it
> > > > should) to find the Motif entry points.
> > >
> > > So perhaps it's because configure doesn't check /usr/lib64, and the
> > > library was moved there recently?  You can try by editing
> > > src/auto/configure and around line 10221; add "/usr/lib64" before
> > > "/usr/lib/i386-linux-gnu" in the assignment to "gui_libs".
> > >
> > AFAIK on openSUSE /usr/lib has always been the 32-bit library (here
> > with interfaces for 32-bit executables running on this 64-bit system)
> > and /usr/lib64 the "purely" 64-bit library.
>
> Please try with patch 9.0.1445.  Hopefully it works without any special
> arguments now.

As I come back to the computer, the source is at patchlevel 9.0.1447
and the Motif libs are found even with no --with-motif-lib= argument
(and a "make reconfig").

Problem solved.

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

Re: Finding the Motif libs

[Tony Mechelynck]

On Mon, Apr 10, 2023 at 9:07 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > > > Recently (but I'm not sure when) my supposedly Motif gvim started
> > > > getting compiled without GUI. Examination of the config log showed the
> > > > following lines:
> > > >
> > > > checking --enable-gui argument... Motif GUI support
> > > > checking for pkg-config... /usr/bin/pkg-config
> > > > checking for location of Motif GUI includes... in default path
> > > > checking --with-motif-lib argument... no
> > > > checking for location of Motif GUI libs... 
> > > >
> > > > After some trial and error, I found out that by changing just one line
> > > > in my environment settings, as follows:
> > > >
> > > > from: export CONF_OPT_GUI='--enable-gui=motif'
> > > >   to: export CONF_OPT_GUI='--enable-gui=motif --with-motif-lib=-lXm'
> > > >
> > > > (and doing no other changes), then sourcing the configure script again
> > > > in the same shell to overwrite the environment values set by the
> > > > previous version of the same script, and running "make reconfig", its
> > > > --version output told me this time "Tiny version with X11-Motif GUI".
> > > > The relevant lines in the config log are now
> > > >
> > > > checking --enable-gui argument... Motif GUI support
> > > > checking for pkg-config... /usr/bin/pkg-config
> > > > checking for location of Motif GUI includes... in default path
> > > > checking --with-motif-lib argument... -lXm
> > > >
> > > > Is this expected? If just specifying that the Motif lib is named libXm
> > > > (without mentioning a directory) makes configure find it, I would have
> > > > expected it to already know that. Or is that name nonstandard?
> > >
> > > It's not about the lib name, it's about finding the library to link
> > > with.  A sequence of directories are checked for:
> > > libXm.a
> > > libXm.dll.a
> > > libXm.so*
> > > libXm.sl
> > > libXm.dylib
> > >
> > > Perhaps the name of the library changed?  On my system I can find
> > > /usr/lib/x86_64-linux-gnu/libXm.a
> > >
> > > The check hasn't changed for a long time.  It can be found in
> > > src/configure.ac around line 2960.
> >
> > According to the YaST installer, openSUSE Tumbleweed package libXm4
> > titled "Motif runtime library" installs (only) files
> > /usr/lib64/libXm.so.4 and /usr/lib64/libXm.so.4.0.4
> >
> > so I did
> >
> > pushd /usr/lib64
> > ls -l libXm*
> >
> > which answered
> >
> > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so -> libXm.so.4.0.4
> > lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so.4 -> libXm.so.4.0.4
> > -rwxr-xr-x 1 root root 3021784 Mar 19 23:38 libXm.so.4.0.4
> > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so -> libXmu.so.6.2.0
> > lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so.6 -> libXmu.so.6.2.0
> > -rwxr-xr-x 1 root root  113936 Mar 19 23:28 libXmu.so.6.2.0
> > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so -> libXmuu.so.1.0.0
> > lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so.1 -> libXmuu.so.1.0.0
> > -rwxr-xr-x 1 root root   22568 Mar 19 23:28 libXmuu.so.1.0.0
> >
> > I think only the first three lines in this list are relevant. IOW on
> > my system there are three files answering to /usr/lib64/libXm.so* in
> > your list, two of which are soft links to the third one. IIUC by
> > giving configure the argument --with-motif-lib=-lXm it doesn't search
> > for the lib but just passes -lXm to the linker, which finds
> > /usr/lib64/libXm.so -> libXm.so.4.0.4 and happily uses that (as it
> > should) to find the Motif entry points.
>
> So perhaps it's because configure doesn't check /usr/lib64, and the
> library was moved there recently?  You can try by editing
> src/auto/configure and around line 10221; add "/usr/lib64" before
> "/usr/lib/i386-linux-gnu" in the assignment to "gui_libs".
>
AFAIK on openSUSE /usr/lib has always been the 32-bit library (here
with interfaces for 32-bit executables running on this 64-bit system)
and /usr/lib64 the "purely" 64-bit library.

IIUC the relevant lines are the following (src/auto/configure lines
10220-10235):

$as_echo_n "checking for location of Motif GUI libs... " >&6; }
gui_libs="`echo $x_libraries|sed 's%/^/^/*$%%'` `echo "$gui_XXX" |
sed s/XXX/lib/g` /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu
`echo "$GUI_INC_LOC" | sed s/include/lib/` $GUI_LIB_LOC"
GUI_LIB_LOC=
for try in $gui_libs; do
  for libtry in "$try"/libXm.a "$try"/libXm.dll.a "$try"/libXm.so*
"$try"/libXm.sl "$try"/libXm.dylib; do
if test -f "$libtry"; then
  GUI_LIB_LOC=$try
fi
  done
done
if test -n "$GUI_LIB_LOC"; then
if test "$GUI_LIB_LOC" = /usr/lib \
   -o "$GUI_LIB_LOC" = /usr/lib/i386-linux-gnu \
   -o "$GUI_LIB_LOC" = /usr/lib/x86_64-linux-gnu; then
GUI_LIB_LOC=
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: in default path" >&5

Indeed /usr/lib and a couple of others are looked for but /usr/lib64 isn't.

As I'm loath to meddle with 

Re: Finding the Motif libs

[Tony Mechelynck]

On Mon, Apr 10, 2023 at 10:11 PM James McCoy  wrote:
>
> On Mon, Apr 10, 2023 at 09:29:52AM +0200, Tony Mechelynck wrote:
> > On Sun, Apr 9, 2023 at 11:02 PM Bram Moolenaar  wrote:
> > >
> > >
> > > Tony wrote:
> > >
> > > > Recently (but I'm not sure when) my supposedly Motif gvim started
> > > > getting compiled without GUI. Examination of the config log showed the
> > > > following lines:
> > > >
> > > > checking --enable-gui argument... Motif GUI support
> > > > checking for pkg-config... /usr/bin/pkg-config
> > > > checking for location of Motif GUI includes... in default path
> > > > checking --with-motif-lib argument... no
> > > > checking for location of Motif GUI libs... 
> > > >
> > > > After some trial and error, I found out that by changing just one line
> > > > in my environment settings, as follows:
> > > >
> > > > from: export CONF_OPT_GUI='--enable-gui=motif'
> > > >   to: export CONF_OPT_GUI='--enable-gui=motif --with-motif-lib=-lXm'
> > > >
> > > > (and doing no other changes), then sourcing the configure script again
> > > > in the same shell to overwrite the environment values set by the
> > > > previous version of the same script, and running "make reconfig", its
> > > > --version output told me this time "Tiny version with X11-Motif GUI".
> > > > The relevant lines in the config log are now
> > > >
> > > > checking --enable-gui argument... Motif GUI support
> > > > checking for pkg-config... /usr/bin/pkg-config
> > > > checking for location of Motif GUI includes... in default path
> > > > checking --with-motif-lib argument... -lXm
> > > >
> > > > Is this expected? If just specifying that the Motif lib is named libXm
> > > > (without mentioning a directory) makes configure find it, I would have
> > > > expected it to already know that. Or is that name nonstandard?
> > >
> > > It's not about the lib name, it's about finding the library to link
> > > with.  A sequence of directories are checked for:
> > > libXm.a
> > > libXm.dll.a
> > > libXm.so*
> > > libXm.sl
> > > libXm.dylib
> > >
> > > Perhaps the name of the library changed?  On my system I can find
> > > /usr/lib/x86_64-linux-gnu/libXm.a
> > >
> > > The check hasn't changed for a long time.  It can be found in
> > > src/configure.ac around line 2960.
> >
> > According to the YaST installer, openSUSE Tumbleweed package libXm4
> > titled "Motif runtime library" installs (only) files
> > /usr/lib64/libXm.so.4 and /usr/lib64/libXm.so.4.0.4
>
> Most shared library packages on Linux are split into the runtime package
> (which contains only the SONAME-versioned library names) and the
> development package (which includes the header files and the unversioned
> library name -- libXm.so -- which is used when building).  It sounds
> like you only have the runtime package installed.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

When I search for "Motif" packages, YaST tells me (in alphabetical
order) that the following are installed:
• libGLwM1 : Motif OpenGL drawing area widget library
• libMrm4 : Motif Resource Manager library
• libUil4 : Motif User Interface Language library
• libXm4 : Motif runtime library
• motif : Motif Runtime Programs
• motif-devel : Motif Include Files and Libraries Mandatory for Development
Not installed are:
• motif-debuginfo : Debug information for package motif
• motif-debugsource : Debug sources for package motif
• motif-devel-debuginfo : Debug information for package motif-devel

If motif-devel were not installed, configure would not find, as it
does even without my help, the Motif include files; and the existence
of the unversioned /usr/lib64/libXm.so as a soft link pointing where
it should, is mentioned in one of my ealier messages.

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/CAJkCKXsAzD%3DVa3%3DLpuhDL1296swqgzxOrqJ4z%2BuKsFE7Pf1GJg%40mail.gmail.com.

Re: Finding the Motif libs

[Tony Mechelynck]

On Sun, Apr 9, 2023 at 11:02 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > Recently (but I'm not sure when) my supposedly Motif gvim started
> > getting compiled without GUI. Examination of the config log showed the
> > following lines:
> >
> > checking --enable-gui argument... Motif GUI support
> > checking for pkg-config... /usr/bin/pkg-config
> > checking for location of Motif GUI includes... in default path
> > checking --with-motif-lib argument... no
> > checking for location of Motif GUI libs... 
> >
> > After some trial and error, I found out that by changing just one line
> > in my environment settings, as follows:
> >
> > from: export CONF_OPT_GUI='--enable-gui=motif'
> >   to: export CONF_OPT_GUI='--enable-gui=motif --with-motif-lib=-lXm'
> >
> > (and doing no other changes), then sourcing the configure script again
> > in the same shell to overwrite the environment values set by the
> > previous version of the same script, and running "make reconfig", its
> > --version output told me this time "Tiny version with X11-Motif GUI".
> > The relevant lines in the config log are now
> >
> > checking --enable-gui argument... Motif GUI support
> > checking for pkg-config... /usr/bin/pkg-config
> > checking for location of Motif GUI includes... in default path
> > checking --with-motif-lib argument... -lXm
> >
> > Is this expected? If just specifying that the Motif lib is named libXm
> > (without mentioning a directory) makes configure find it, I would have
> > expected it to already know that. Or is that name nonstandard?
>
> It's not about the lib name, it's about finding the library to link
> with.  A sequence of directories are checked for:
> libXm.a
> libXm.dll.a
> libXm.so*
> libXm.sl
> libXm.dylib
>
> Perhaps the name of the library changed?  On my system I can find
> /usr/lib/x86_64-linux-gnu/libXm.a
>
> The check hasn't changed for a long time.  It can be found in
> src/configure.ac around line 2960.

According to the YaST installer, openSUSE Tumbleweed package libXm4
titled "Motif runtime library" installs (only) files
/usr/lib64/libXm.so.4 and /usr/lib64/libXm.so.4.0.4

so I did

pushd /usr/lib64
ls -l libXm*

which answered

lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so -> libXm.so.4.0.4
lrwxrwxrwx 1 root root  14 Mar 19 23:38 libXm.so.4 -> libXm.so.4.0.4
-rwxr-xr-x 1 root root 3021784 Mar 19 23:38 libXm.so.4.0.4
lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so -> libXmu.so.6.2.0
lrwxrwxrwx 1 root root  15 Mar 19 23:28 libXmu.so.6 -> libXmu.so.6.2.0
-rwxr-xr-x 1 root root  113936 Mar 19 23:28 libXmu.so.6.2.0
lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so -> libXmuu.so.1.0.0
lrwxrwxrwx 1 root root  16 Mar 19 23:28 libXmuu.so.1 -> libXmuu.so.1.0.0
-rwxr-xr-x 1 root root   22568 Mar 19 23:28 libXmuu.so.1.0.0

I think only the first three lines in this list are relevant. IOW on
my system there are three files answering to /usr/lib64/libXm.so* in
your list, two of which are soft links to the third one. IIUC by
giving configure the argument --with-motif-lib=-lXm it doesn't search
for the lib but just passes -lXm to the linker, which finds
/usr/lib64/libXm.so -> libXm.so.4.0.4 and happily uses that (as it
should) to find the Motif entry points.

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

Finding the Motif libs

[Tony Mechelynck]

Recently (but I'm not sure when) my supposedly Motif gvim started
getting compiled without GUI. Examination of the config log showed the
following lines:

checking --enable-gui argument... Motif GUI support
checking for pkg-config... /usr/bin/pkg-config
checking for location of Motif GUI includes... in default path
checking --with-motif-lib argument... no
checking for location of Motif GUI libs... 

After some trial and error, I found out that by changing just one line
in my environment settings, as follows:

from: export CONF_OPT_GUI='--enable-gui=motif'
  to: export CONF_OPT_GUI='--enable-gui=motif --with-motif-lib=-lXm'

(and doing no other changes), then sourcing the configure script again
in the same shell to overwrite the environment values set by the
previous version of the same script, and running "make reconfig", its
--version output told me this time "Tiny version with X11-Motif GUI".
The relevant lines in the config log are now

checking --enable-gui argument... Motif GUI support
checking for pkg-config... /usr/bin/pkg-config
checking for location of Motif GUI includes... in default path
checking --with-motif-lib argument... -lXm

Is this expected? If just specifying that the Motif lib is named libXm
(without mentioning a directory) makes configure find it, I would have
expected it to already know that. Or is that name nonstandard?

N.B. Here is the full (new) configuration script for that shell (I
compile each differently configured version in a separate shadowdir
and a separate konsole tab and shell, with a soft link, not a copy, to
the src/Makefile, and configure arguments set only via environment
variables):

# Vim without evaluation but with Motif
export CONF_OPT_GUI='--enable-gui=motif --with-motif-lib=-lXm'
export CONF_OPT_FEAT='--with-features=small'
export CONF_ARGS2='--with-vim-name=vim-small'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'


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/CAJkCKXtwYmii4R5GOnvaMPBd8VieSJzMsBNXBb4qy5-6bNh9_A%40mail.gmail.com.

Re: using vim to run vim9script

[Tony Mechelynck]

On Wed, Mar 29, 2023 at 9:58 PM Ernie Rael  wrote:
[...]
> The interesting thing is that if the vimscript
> exits with an exception or :cquit, then after the bash shell
> script exits, the return code is 1 (as hoped for), otherwise it
> exits with 0. This seems to be undocumented behavior.
[...]
It is documented under ":help :cquit" — I looked for behaviour on :qa
with an uncaught exception but didn't find anything. Maybe that's what
":h v:exiting" covers.
Also, :cquit 5 or :5cquit makes Vim exit with return code 5 (or
similarly for other values). I think that in such a case the bash
script would exit with the return code of the last command it ran but
I'm not 100% sure (another possibility would be 1 for false, 0 for
true, nothing else).

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/CAJkCKXuauRJ6o_i7AswemJ%3D%2B0JLV4atC8AmYM6%2BWonOxr4wC3g%40mail.gmail.com.

Re: Compilation warnings in builds with expression evaluation

[Tony Mechelynck]

On Tue, Mar 28, 2023 at 6:25 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > I noticed this in a "make reconfig" at patchlevel 9.0.1429. It may or
> > may not have happened earlier. Builds without expression evaluation
> > are not affected.
> >
> > The following is from a Normal build without the -j argument to make,
> > to avoid line-interlacing from builds of different modules:
> >
> > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> > -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> > -I/usr/include/harfbuzz -I/usr/include/freetype2
> > -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
> > -I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
> > -I/usr/include/wayland -I/usr/include/libxkbcommon
> > -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
> > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
> > -I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
> > -Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
> > -D_FORTIFY_SOURCE=1-o objects/memline.o memline.c
> > memline.c: In function ‘adjust_text_props_for_delete’:
> > memline.c:3623:43: warning: ‘this_props_len’ may be used uninitialized
> > [-Wmaybe-uninitialized]
> >  3623 | for (done_this = 0; done_this < this_props_len;
> >   | ~~^~~~
>
> I cannot make this warning show up.  I did add the "-O2" argument to
> gcc, that usually reveals these "may be used uninitialized" warnings.
> I assume you use a different version of gcc.  I'm afraid I cannot guess
> what would be the best way to get rid of these warnings.  It looks like
> the optimizer doesn't see that "did_get_line" is FALSE at first and the
> block that sets the variables will always be executed before they are
> used.

At this moment, my gcc version is 13-1.2-x86_64 and my OS is openSUSE
Tumbleweed, snapshot 20230326. Also installed are, among others,
gcc13, cpp13 and libstdc++6-devel-gcc13, all at version
13.0.1+git6669-1.1-x86_64.

The answer to "gcc --version" is
gcc (SUSE Linux) 13.0.1 20230314 (experimental) [revision
42630fadbe248717859d61c0244c821c32b4e52c]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

>
> Can someone reproduce the warning and come up with a reasonable solution?
> I don't think initializing the variables is a good solution, that should
> not be necessary.

As long as warning messages don't prevent production of an executable
program, and as long as that executable does what I expect of it in
terms of editing properly and not crashing, I can live with them; but
I know that you prefer not having the compiler's output cluttered with
useless warnings. I suppose that changing the Makefile to compile all
modules with -Wno-maybe-uninitialized is not an option because when
this message appears it should usually be looked into.

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

Re: Warning (no error) in regexp.nfa.c included from regexp.c in Tiny build

[Tony Mechelynck]

On Sat, Mar 25, 2023 at 12:30 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > In file included from regexp.c:2707:
> > regexp_nfa.c: In function ‘nfa_regmatch’:
> > regexp_nfa.c:6696:33: warning: ‘bytelen’ may be used uninitialized
> > [-Wmaybe-uninitialized]
> >  6696 | if (bytelen == 0)
> >   | ^~~~
> > regexp_nfa.c:6679:21: note: ‘bytelen’ declared here
> >  6679 | int bytelen;
> >   | ^~~
> >
> > This was in "make reconfig" at patchlevel 9.0.1425 but maybe appeared 
> > earlier.
>
> I guess you build without syntax highlighting.
>
I don't specifically include or exclude syntax highlighting. IOW,
according to runtime/doc/various.txt:469, my Normal and bigger builds
have it, my smaller builds don't.

This warning did not reappear in the "make reconfig" build I did today
at patchlevel 9.0.1429 (which IIUC means that patch 1427 fixed it) but
I got another one instead (which I described in another email a few
minutes ago, concerning memline.c and possibly os_unix.h) for builds
with +eval only.

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/CAJkCKXvAUjJQSe4x-xNHcTx2V1t%3DLJMi1pPwifAmsBenOYBp7A%40mail.gmail.com.

Compilation warnings in builds with expression evaluation

[Tony Mechelynck]

I noticed this in a "make reconfig" at patchlevel 9.0.1429. It may or
may not have happened earlier. Builds without expression evaluation
are not affected.

The following is from a Normal build without the -j argument to make,
to avoid line-interlacing from builds of different modules:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -pthread-O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/memline.o memline.c
memline.c: In function ‘adjust_text_props_for_delete’:
memline.c:3623:43: warning: ‘this_props_len’ may be used uninitialized
[-Wmaybe-uninitialized]
 3623 | for (done_this = 0; done_this < this_props_len;
  | ~~^~~~
memline.c:3582:17: note: ‘this_props_len’ was declared here
 3582 | int this_props_len;
  | ^~
In file included from vim.h:244,
 from memline.c:45:
memline.c:3630:56: warning: ‘text’ may be used uninitialized
[-Wmaybe-uninitialized]
 3630 | mch_memmove(_this, text + textlen + done_this,
os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
  430 | # define mch_memmove(to, from, len) memmove((char *)(to),
(char *)(from), len)
  |^~~~
memline.c:3583:18: note: ‘text’ was declared here
 3583 | char_u  *text;
  |  ^~~~
memline.c:3630:56: warning: ‘textlen’ may be used uninitialized
[-Wmaybe-uninitialized]
 3630 | mch_memmove(_this, text + textlen + done_this,
  |^
os_unix.h:430:68: note: in definition of macro ‘mch_memmove’
  430 | # define mch_memmove(to, from, len) memmove((char *)(to),
(char *)(from), len)
  |^~~~
memline.c:3584:17: note: ‘textlen’ was declared here
 3584 | size_t  textlen;
  | ^~~

The configuration arguments for this build are set as follows:

export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=normal'
export CONF_ARGS2='--with-vim-name=vim-normal'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'


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

Warning (no error) in regexp.nfa.c included from regexp.c in Tiny build

[Tony Mechelynck]

In file included from regexp.c:2707:
regexp_nfa.c: In function ‘nfa_regmatch’:
regexp_nfa.c:6696:33: warning: ‘bytelen’ may be used uninitialized
[-Wmaybe-uninitialized]
 6696 | if (bytelen == 0)
  | ^~~~
regexp_nfa.c:6679:21: note: ‘bytelen’ declared here
 6679 | int bytelen;
  | ^~~

This was in "make reconfig" at patchlevel 9.0.1425 but maybe appeared earlier.

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

Re: doc: Spelling of LAMBDA in digraph table

[Tony Mechelynck]

On Tue, Mar 21, 2023 at 10:37 AM Max Mahlke  wrote:
>
> Dear all,
>
> in runtime/doc/digraph.txt, the greek letter lambda is spelt LAMDA. I
> was looking for it under the accepted spelling LAMBDA, though I am aware
> that some people prefer the LAMDA spelling. I see that the vim source
> makes frequent use of both spellings.
>
> I would therefore suggest changing
>
> runtime/doc/digraph.txt
> 550:Λ   L*  039B0923GREEK CAPITAL LETTER LAMDA
> 581:λ   l*  03BB0955GREEK SMALL LETTER LAMDA
>
> to
>
> runtime/doc/digraph.txt
> 550:Λ   L*  039B0923GREEK CAPITAL LETTER LAMDA/LAMBDA
> 581:λ   l*  03BB0955GREEK SMALL LETTER LAMDA/LAMBDA
>
> I would gladly submit a PR for this change on GitHub.
>
> Apologies if this has been discussed before, I have not found any
> mention in the mailing list archives or on the GitHub repository.
>
> Kind regards
> Max Mahlke

tl·dr : See last paragraph but one, below.

When I was in secondary school, in the Latin-Greek section of a school
where instruction was given in French, I learnt to call this letter
"lambda". However the official, unchangeable names as shown in the
"Greek and Coptic" Unicode reference file
http://www.unicode.org/charts/PDF/U0370.pdf are GREEK CAPITAL LETTER
LAMDA and GREEK SMALL LETTER LAMDA respectively. The small letter, but
not the capital, has under its official name there the commentary "=
lambda".

The names in all-caps used in Vim, and in particular by the optional
Unicode plugin by Christian Brabandt, but also at lines 179sqq of the
standard digraph.txt helpfile, are the official names published by the
Unicode Consortium. We shouldn't change them at will, even though I
too would use the name "lambda" with b for the Greek letter Λλ and
even though the English Wiktionary entry for "lamda"
https://en.wiktionary.org/wiki/lamda gives as definition "Misspelling
of *lambda*" with a Usage note: "This spelling appears in the Unicode
standard (U+0039B, U+003BB)."

So it appears that the use of the word LAMDA in those names is a
misspelling which was taken up in an official standard which cannot
ever be modified (because the rules of the Unicode standard include
never modifying the official name of a codepoint once it has been
defined, not even to correct an error). A deplorable fact, to be sure,
but I think that we have to live with that misspelled all-caps
unchangeable official name.

All hope is not lost, however. One thing we _could_ do, if Bram
agrees, is define help tags *Lambda* and *lambda* right where these
"official misspellings" are found in the digraph.txt helpfile. Then
":help Lambda" and ":help lambda" would bring us to the appropriate
digraphs.

Another thing which any Vim user should do who, like me, frequently
uses Greek letters absent from his/her keyboard, is commit to memory
the fact that digraphs for Greek letters are characterized by a Latin
letter followed by an asterisk: so ^K a * gives the letter alpha, ^K b
* gives the letter beta, ^K L * gives upper-case lambda, etc., with
the particularity that ^K s * is a "normal" sigma while the "final"
sigma is ^K * s. In addition, typing :dig! in Normal mode displays the
list of digraphs with section headers. You'll find the Greek alphabet
as part of the "Greek and Coptic" section.

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

Confusing help

[Tony Mechelynck]

At change.txt lines 1382-1386:

> If you use a put command without specifying a register, Vim uses the register
> that was last filled (this is also the contents of the unnamed register).  If
> you are confused, use the `:dis` command to find out what Vim will put (this
> command displays all named and numbered registers; the unnamed register is
> labelled '"').

However, if I try to see what this command does by typing ":h :dis", I
am sent to the help entry for :disassemble because the only tags for
the :dis command are :di (the shortest abbreviation) and :display (the
full command name).

I suggest writing either "use the `:display` command" or "use the
`:reg` command" at change.txt line 1384. Either possibility will
unambiguously send to the correct help if tried, with the advantage,
in the latter case, of not needing a scroll-up.

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/CAJkCKXv15oOXmKJCYD6t5vcMtevT6eJVA9Fheq_j%3Da%3Ddhtc1vA%40mail.gmail.com.

Re: Patch 9.0.1283

[Tony Mechelynck]

On Sun, Feb 5, 2023 at 5:03 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.1283
> Problem:The code for setting options is too complicated.
> Solution:   Refactor the do_set() function. (Yegappan Lakshmanan, Lewis
> Russell, closes #11945)
> Files:  src/option.c

Warnings Wmaybe-uninitialized for cp_val and varp in all builds. The
following is from the Tiny build:

linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny # (make -j4 || echo
'exit status' $? ; date) 2>&1 |tee -a make.log
gcc -c -I.   -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1  -o objects/option.o option.c
In function ‘do_set_string’,
inlined from ‘do_set_option_value’ at option.c:2047:10,
inlined from ‘do_set_option’ at option.c:2267:11,
inlined from ‘do_set’ at option.c:2349:15:
option.c:1471:65: warning: ‘cp_val’ may be used uninitialized
[-Wmaybe-uninitialized]
 1471 |?
VI_DEFAULT : VIM_DEFAULT];
option.c: In function ‘do_set’:
option.c:2099:17: note: ‘cp_val’ was declared here
 2099 | int cp_val;
  | ^~
In function ‘do_set_option_bool’,
inlined from ‘do_set_option_value’ at option.c:2020:11,
inlined from ‘do_set_option’ at option.c:2267:11,
inlined from ‘do_set’ at option.c:2349:15:
option.c:1850:12: warning: ‘varp’ may be used uninitialized
[-Wmaybe-uninitialized]
 1850 | if ((int *)varp == >b_p_ar && opt_flags == OPT_LOCAL)
  |^
option.c: In function ‘do_set’:
option.c:2095:18: note: ‘varp’ was declared here
 2095 | char_u  *varp;  // pointer to variable for
current option
  |  ^~~~
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1version.c -o objects/version.o
link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly.
  gcc   -L/usr/local/lib -Wl,--as-needed-o vi objects/alloc.o
objects/arabic.o objects/arglist.o objects/autocmd.o objects/beval.o
objects/buffer.o objects/change.o objects/blob.o objects/blowfish.o
objects/cindent.o objects/clientserver.o objects/clipboard.o
objects/cmdexpand.o objects/cmdhist.o objects/crypt.o
objects/crypt_zip.o objects/debugger.o objects/dict.o objects/diff.o
objects/digraph.o objects/drawline.o objects/drawscreen.o
objects/edit.o objects/eval.o objects/evalbuffer.o objects/evalfunc.o
objects/evalvars.o objects/evalwindow.o objects/ex_cmds.o
objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o
objects/ex_getln.o objects/fileio.o objects/filepath.o
objects/findfile.o objects/float.o objects/fold.o objects/getchar.o
objects/gui_xim.o objects/hardcopy.o objects/hashtab.o objects/help.o
objects/highlight.o objects/if_cscope.o objects/if_xcmdsrv.o
objects/indent.o objects/insexpand.o objects/list.o objects/locale.o
objects/logfile.o objects/map.o objects/mark.o objects/match.o
objects/mbyte.o objects/memline.o objects/menu.o objects/misc1.o
objects/misc2.o objects/mouse.o objects/move.o objects/normal.o
objects/ops.o objects/option.o objects/optionstr.o objects/os_unix.o
objects/pathdef.o objects/popupmenu.o objects/popupwin.o
objects/profiler.o objects/pty.o objects/quickfix.o objects/regexp.o
objects/register.o objects/screen.o objects/scriptfile.o
objects/search.o objects/session.o objects/sha256.o objects/sign.o
objects/sound.o objects/spell.o objects/spellfile.o
objects/spellsuggest.o objects/strings.o objects/syntax.o
objects/tag.o objects/term.o objects/terminal.o objects/testing.o
objects/textformat.o objects/textobject.o objects/textprop.o
objects/time.o objects/typval.o objects/ui.o objects/undo.o
objects/usercmd.o objects/userfunc.o objects/version.o
objects/vim9class.o objects/vim9cmds.o objects/vim9compile.o
objects/vim9execute.o objects/vim9expr.o objects/vim9instr.o
objects/vim9script.o objects/vim9type.o objects/viminfo.o
objects/window.o objects/bufwrite.o  objects/charset.o
objects/json.o objects/main.o objects/memfile.o objects/message.o
-lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf
-lselinux -lgpm
link.sh: Linked fine
Sun  5 Feb 17:33:03 CET 2023
linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny #


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

Re: "Connection refused" at hg.256bit.org

[Tony Mechelynck]

On Fri, Jan 20, 2023 at 8:58 PM Christian Brabandt  wrote:
>
> Am 2023-01-20 16:53, schrieb Tony Mechelynck:
> > The date-time stamps below (1. good, 2. bad) give a range of when it
> > started to happen. "traceroute hg.256bit.org" seems to run OK.
> >
> > linux-tuxedo:~/.build/vim/vim-hg # hg in || echo 'exit status' $? ;
> > date
> > comparing with http://hg.256bit.org/vim
> > searching for changes
> > no changes found
> > (sent 2 HTTP requests and 631 bytes; received 615 bytes in responses)
> > exit status 1
> > Fri 20 Jan 10:14:20 CET 2023
> > linux-tuxedo:~/.build/vim/vim-hg # hg in || echo 'exit status' $? ;
> > date
> > abort: error: Connection refused
> > exit status 255
> > Fri 20 Jan 16:45:56 CET 2023
> >
> > Best regards,
> > Tony.
>
> Yes, my fault. Not sure what happened, I started a docker process and
> for some reason, the server did
> a hard crash. Then it came up but several services (apache, mail, ...)
> did not
> and it went through a long raid resync.
>
> I now restarted the services and everything seems to work for now :)
>
> Hopefully it will be stable for now.
>
> Sorry,
> Chris

Just came back to the computer and now I could connect to your Mercurial server.

Thanks, and have a nice weekend,
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/CAJkCKXtm2j2diWrSymjq0_e5zdkcHU1%3DJLrETRfW%2Bw83%2B2s27w%40mail.gmail.com.

"Connection refused" at hg.256bit.org

[Tony Mechelynck]

The date-time stamps below (1. good, 2. bad) give a range of when it
started to happen. "traceroute hg.256bit.org" seems to run OK.

linux-tuxedo:~/.build/vim/vim-hg # hg in || echo 'exit status' $? ; date
comparing with http://hg.256bit.org/vim
searching for changes
no changes found
(sent 2 HTTP requests and 631 bytes; received 615 bytes in responses)
exit status 1
Fri 20 Jan 10:14:20 CET 2023
linux-tuxedo:~/.build/vim/vim-hg # hg in || echo 'exit status' $? ; date
abort: error: Connection refused
exit status 255
Fri 20 Jan 16:45:56 CET 2023

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

Build failure in Tiny (scroll_dict undefined at window.c:3137:27) after applying patches 9.0. 925 to 928

[Tony Mechelynck]

gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/window.o window.c
window.c: In function ‘may_trigger_win_scrolled_resized’:
window.c:3137:27: error: ‘scroll_dict’ undeclared (first use in this
function); did you mean ‘scroll_start’?
 3137 | if (trigger_scroll && scroll_dict != NULL)
  |   ^~~
  |   scroll_start
window.c:3137:27: note: each undeclared identifier is reported only
once for each function it appears in
make: *** [Makefile:3511: objects/window.o] Error 1

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/CAJkCKXsp3OQtWqVmo7WuaQLmnm4r3MQDr0jGRF%2BiejMXkzs%3Dmg%40mail.gmail.com.

Re: Health update

[Tony Mechelynck]

On Wed, Nov 2, 2022 at 1:00 PM Bram Moolenaar  wrote:
[...]
> OK.  Changing commits would be rewriting history, that sounds like
> something we don't want, even though it looks like some commits were not
> done right.  I tried creating diffs from the tagged commits, but those
> are a bit messy too.  I'll not try to fix more, unless someone can tell
> me the git commands that will make something better.  E.g. updating the
> description to say what the commit is really about.  But only if this
> won't have undesired side effects.
[...]
IIUC, the 40-nybble commit ID is computed from the parent's ID and
everything in the new commit including the description (but not the
tag(s) if any, which are added afterwards). This would mean that
changing a description would actually mean deleting a commit and
everything descended from it, then recreating all these deleted
commits with different contents (and in particular different IDs),
thus making the repository incompatible with any users' repositories
where any of the now deleted commits had been downloaded.

I agree with Christian: leave it as-is, it is not perfect (perfection
is not of this world) but we can live with it.

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/CAJkCKXt9PVOQ4qgxxPfNw28dS%3DWdYVgwte5KfNWGAt7aMXFi-w%40mail.gmail.com.

Re: Christian, is your Mercurial server down?

[Tony Mechelynck]

Awesome, thanks!

Tony.

On Wed, Nov 2, 2022 at 11:22 AM Christian Brabandt  wrote:
>
> Tony and list,
> I fixed the problem. The problem was, the script stopped working when
> git detected,
> that tag v9.0.0814 was re-defined. So I had to manualy update the tags.
>
> I think it should be good now. Please let me know, if you have any
> questions,
>
> Thanks,
> Chris
>
>
> Am 2022-10-31 16:29, schrieb Christian Brabandt:
> > Tony,
> > I am currently away from my pc, returning tomorrow. I can then check.
> > Sorry for the delay,
> >
> > Best
> > Chris
> >
> >> Am 31.10.2022 um 15:38 schrieb Tony Mechelynck
> >> :
> >>
> >> For some reason after I have downloaded patches up to 9.0.818 (which
> >> doesn't build) with the exception of patch 9.0.816 (which apparently
> >> is missing) your Mercurial server http://hg.256bit.org/vim has been
> >> telling me (for some days already) that there are "no changes found".
> >> However I see in the mailing list that even from his sickbed Bram has
> >> been publishing patches up to 9.0.822 so far. What's the matter?
> >>
> >> 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/CAJkCKXtrNcZxLoBGMZG0ZF56BCgn3NAEb-fw0_tWKv7TmPswXw%40mail.gmail.com.

Christian, is your Mercurial server down?

[Tony Mechelynck]

For some reason after I have downloaded patches up to 9.0.818 (which
doesn't build) with the exception of patch 9.0.816 (which apparently
is missing) your Mercurial server http://hg.256bit.org/vim has been
telling me (for some days already) that there are "no changes found".
However I see in the mailing list that even from his sickbed Bram has
been publishing patches up to 9.0.822 so far. What's the matter?

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

Re: Health update

[Tony Mechelynck]

On Fri, Oct 28, 2022 at 10:05 AM Bram Moolenaar  wrote:
[...]
> Thanks for all the wishes, it helps a lot to know you are caring.

Indeed we care. Take care of your health, and in the meantime we'll
try to take care of Vim as best we can.

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

Patch 9.0.816 missing?

[Tony Mechelynck]

"hg glog -l 10" gives me patches up to 9.0.814 and 9.0.815;
"hg in" gives me patches 9.0.817 and 9.0.818 only.
None of 815, 817 or 818 has either a Description (other than the patch
number itself) or a tag on the Mercurial server.
What happened to patch 816 "CTRL-Z at end of file is always dropped."
which I see on vim_dev?

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/CAJkCKXtCQ%2BaCWFp-9QNFiUMAn48yLPfgc0pD%2BxQ9edSp%2B9Du_A%40mail.gmail.com.

Strange patch 9.0.815

[Tony Mechelynck]

At least on the Mercurial server, patch 9.0.815 has no description of
the "problem", nor of the "solution", and it also hasn't got a
Mercurial tag.

Neither does it have a vim-dev message 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/CAJkCKXvNSHOdN0oPj98EFYcKW9qVt-syFQDN2LgRpEFShjAN%2Bw%40mail.gmail.com.

Thanks Bram for re-enabling +rightleft +arabic

[Tony Mechelynck]

Thanks Bram for re-enabling +rightleft +arabic!

I'll still be compiling 5 builds of Vim, some of them as a sanity test
for various compile-time featuresets, as follows:
• vi: a minimum build with as few features as possible and in
particular -eval and no GUI
• vim-small: a build with -eval but with Motif GUI
• vim-normal: the Normal featureset, with GTK3 GUI
• vim: a build (formerly Big, now described as Huge) with GTK3 GUI and
with +keymap +langmap +rightleft +arabic +autoservername but with no
interpreted languages
• vim-huge: a Huge build with GTK3 GUI and as many features as I can
find how to add, and in particular with several interpreted languages

A +gui build and a minimum "vi" build from my distro are also
installed, and there is no conflict with the above, but I rarely use
them. They are there as a fallback, for instance for the case when
there is a big change in the OS, I should have run "make reconfig" on
Vim to catch changes in the libraries and include files, forgot to do
it, and suddenly my own-compiled Vim gets a startup crash at every
run.

I think that the "typical user" might want to choose one or two of the
above configurations, or similar ones, but of course there are other
possibilities and Your Mileage May Vary: one of the great pluses of
Vim (in addition to its full documentation) is IMHO that it is not a
corset: different users can arrive at the same result by different
paths and among others with different successions of keystrokes.

To save wall clock time when compiling, rather than giving Make a -j
argument (which I might still add sometime, now that I have a more
powerful computer, with 12 virtual cores), I compile them in parallel,
each in its own shell in its own shadow directory, with its own
configure environment and no changes to the distributed Makefile.

Best regards, and have fun
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/CAJkCKXv%3Dz8kvWKaj1E8REvg0RPCU%3DqJcPT0%3Dycvz8jqqpLWA9g%40mail.gmail.com.

Re: Cannot compile with +rightleft and +arabic

[Tony Mechelynck]

On Sun, Oct 9, 2022 at 12:45 PM Bram Moolenaar  wrote:
> It is rather arbitrary.  I moved features related to highlighting to the
> normal build, and features related to natural language support to the
> huge build.  Now we have three builds that are different enough to
> justify their existence.  You can pick the normal build and cherry-pick
> some features, or use the huge build and disable features that you don't
> want.

OK, I'll compile a not-so-huge build and a really-huge build then (in
addition to smaller builds used mostly as a sanity check), as follows:

This is the really-huge build:

# configuration for Huge Vim
export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_PYTHON3='--disable-python3interp'
export CONF_OPT_TCL='--enable-tclinterp'
# /usr/bin/tclsh (softlink) is correctly set
export CONF_OPT_RUBY='--enable-rubyinterp'
export CONF_OPT_LUA='--enable-luainterp'
export CONF_OPT_MZSCHEME='--disable-mzschemeinterp'
#export CONF_OPT_PLTHOME='--with-plthome=/usr/local/plt'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_TERMINAL='--enable-terminal'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_ARGS2='--with-vim-name=vim-huge'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'

and this is ne not-so-huge one:

# Configuration for Big (or "simplified Huge") Vim build
export CONF_OPT_GUI='--enable-gui=gtk3'
# the multibyte feature (+multi_byte) is now always enabled
# so the following is not really needed anymore
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_TERMINAL='--disable-terminal'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=huge'
# export CONF_ARGS2='--with-vim-name=vim-big'
# let's actually name it "vim" (with symlinks from gvim, view, etc.)
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'

The difference is mostly in the interpreted languages and in the
terminal feature, all of which are disabled in the lesser of the two.
I'll keep an eye on how the featureset (as shown by :version) evolves.

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/CAJkCKXt%2BtbTiwddiJvyWMXCAbLAJf-B0W7RvvZBnBeCybx%2BndQ%40mail.gmail.com.

Re: Cannot compile with +rightleft and +arabic

[Tony Mechelynck]

On Sun, Oct 9, 2022 at 12:45 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > Whatever I do, my Vim executables come now out with -rightleft and
> > -arabic (since patchlevel 700 maybe?).
> >
> > These features used to work well enough, and that is the reason why I
> > haven't been filing bug reports or posting feedback about them. Now I
> > see that at lines 237 to 247 of feature.h, both FEAT_RIGHTLEFT and
> > FEAT_ARABIC are now forcibly undefined even if they had been defined
> > earlier (and even in Huge builds) on the pretext that no bug reports
> > and no feedback have been seen about them recently. Configure
> > arguments --enable-rightleft and --enable-arabic also have no effect.
>
> That was intentional.  I asked around about people using the +rightleft
> feature and got no response.  Since I suspected the message wasn't read
> I have disabled the features, but the code is still there.
>
> I have been wondering how well the right-left support works, since there
> were no bug fixes in that area while there must have been changes and
> features that interfere.  The code has many #ifdefs for this, thus if
> it's not used then I rather get rid of it.  But if, as you say, it works
> well enough then it's worth keeping.
>
> I'll keep them disabled for a few more days, hopefully that triggers
> useful feedback.

I can't believe that I'm the only one using these Vim features,
because I expect that:
• anyone writing in Hebrew, even occasionally, would need +rightleft;
• anyone wriling in Arabic (or Farsi or Urdu or...), even
occasionally, would need both +rightleft and +arabic.

I remember when Nadim added the +arabic feature, and I helped him test
it, especially at first. I think there has been an occasional change
as successive Unicode versions defined new RTL characters. These
changes may have gone relatively unnoticed by people who don't use
them, but I can assure you that, with its known limitations such as
not offering true-bidi except in a bidi terminal such as mlterm, the
+arabic feature is quite usable, and I expect that +rightleft is even
better for writing Hebrew (where +arabic is unnecessary because
letters usually stand apart from each other).

>
> > Similarly, keymaps work well, and I wonder why they have been
> > relegated to the Huge build. IMHO, keymaps (and possibly langmaps,
> > which I don't use because I am lucky enough to have a mother languague
> > using the Latin alphabet) are an essential feature when working with
> > non-Latin scripts. I have taken the trouble to write owncoded keymaps
> > for both Russian (Cyrillic) and Arabic, but now my workhouse Big build
> > (downgraded to Normal level) can't use them anymore. They used to be
> > usable with a Big build but now a Huge build (with, from my point of
> > view, lots of unneeded ballast) is required.
>
> It is rather arbitrary.  I moved features related to highlighting to the
> normal build, and features related to natural language support to the
> huge build.  Now we have three builds that are different enough to
> justify their existence.  You can pick the normal build and cherry-pick
> some features, or use the huge build and disable features that you don't
> want.

However, +multi_byte was made unconditional (moved to Tiny) some time
ago. Isn't that natural language support too? OTOH, Unicode support is
becoming more and more universal these days, especially on Linux (but
AFAIR not in your own email client as configured).

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/CAJkCKXt00UNUM6%3DbyH%2BSHyLkQ5aWmz3EbkLoxLBSD7mEkChzxA%40mail.gmail.com.

Cannot compile with +rightleft and +arabic

[Tony Mechelynck]

Whatever I do, my Vim executables come now out with -rightleft and
-arabic (since patchlevel 700 maybe?).

These features used to work well enough, and that is the reason why I
haven't been filing bug reports or posting feedback about them. Now I
see that at lines 237 to 247 of feature.h, both FEAT_RIGHTLEFT and
FEAT_ARABIC are now forcibly undefined even if they had been defined
earlier (and even in Huge builds) on the pretext that no bug reports
and no feedback have been seen about them recently. Configure
arguments --enable-rightleft and --enable-arabic also have no effect.

Similarly, keymaps work well, and I wonder why they have been
relegated to the Huge build. IMHO, keymaps (and possibly langmaps,
which I don't use because I am lucky enough to have a mother languague
using the Latin alphabet) are an essential feature when working with
non-Latin scripts. I have taken the trouble to write owncoded keymaps
for both Russian (Cyrillic) and Arabic, but now my workhouse Big build
(downgraded to Normal level) can't use them anymore. They used to be
usable with a Big build but now a Huge build (with, from my point of
view, lots of unneeded ballast) is required.

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/CAJkCKXvz%3DX8OYYmA63C-zZBMK9%3D%2BYtNGKkv4p1L4v6OQDXYxOQ%40mail.gmail.com.

Link error in Tiny build (undefined reference to `plines_nofill' in move.c in function `scroll_cursor_bot') after applying patches 9.0. 670 to 672

[Tony Mechelynck]

linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny # (make || echo 'exit
status' $? ; date) 2>&1 |tee -a make.log
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/move.o move.c
gcc -c -I.   -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce
-Wall -Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1  -o objects/option.o option.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/window.o window.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1version.c -o objects/version.o
link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly.
  gcc   -L/usr/local/lib -Wl,--as-needed-o vi objects/alloc.o
objects/arabic.o objects/arglist.o objects/autocmd.o objects/beval.o
objects/buffer.o objects/change.o objects/blob.o objects/blowfish.o
objects/cindent.o objects/clientserver.o objects/clipboard.o
objects/cmdexpand.o objects/cmdhist.o objects/crypt.o
objects/crypt_zip.o objects/debugger.o objects/dict.o objects/diff.o
objects/digraph.o objects/drawline.o objects/drawscreen.o
objects/edit.o objects/eval.o objects/evalbuffer.o objects/evalfunc.o
objects/evalvars.o objects/evalwindow.o objects/ex_cmds.o
objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o
objects/ex_getln.o objects/fileio.o objects/filepath.o
objects/findfile.o objects/float.o objects/fold.o objects/getchar.o
objects/gui_xim.o objects/hardcopy.o objects/hashtab.o objects/help.o
objects/highlight.o objects/if_cscope.o objects/if_xcmdsrv.o
objects/indent.o objects/insexpand.o objects/list.o objects/locale.o
objects/map.o objects/mark.o objects/match.o objects/mbyte.o
objects/memline.o objects/menu.o objects/misc1.o objects/misc2.o
objects/mouse.o objects/move.o objects/normal.o objects/ops.o
objects/option.o objects/optionstr.o objects/os_unix.o
objects/pathdef.o objects/popupmenu.o objects/popupwin.o
objects/profiler.o objects/pty.o objects/quickfix.o objects/regexp.o
objects/register.o objects/screen.o objects/scriptfile.o
objects/search.o objects/session.o objects/sha256.o objects/sign.o
objects/sound.o objects/spell.o objects/spellfile.o
objects/spellsuggest.o objects/strings.o objects/syntax.o
objects/tag.o objects/term.o objects/terminal.o objects/testing.o
objects/textformat.o objects/textobject.o objects/textprop.o
objects/time.o objects/typval.o objects/ui.o objects/undo.o
objects/usercmd.o objects/userfunc.o objects/version.o
objects/vim9cmds.o objects/vim9compile.o objects/vim9execute.o
objects/vim9expr.o objects/vim9instr.o objects/vim9script.o
objects/vim9type.o objects/viminfo.o objects/window.o
objects/bufwrite.o  objects/charset.o objects/json.o
objects/main.o objects/memfile.o objects/message.o-lSM -lICE -lXpm
-lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf  -lselinux -lgpm
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld:
objects/move.o: in function `scroll_cursor_bot':
move.c:(.text+0x1748): undefined reference to `plines_nofill'
collect2: error: ld returned 1 exit status
link.sh: Linking failed
make: *** [Makefile:2055: vi] Error 1
exit status 2
Thu  6 Oct 16:08:21 CEST 2022

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

--- 
You received this message because you are subscribed to the Google 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/CAJkCKXuiTccM2v_3V-dUGGe4-yup63jyZn0RPhaqz0uooYB4Ag%40mail.gmail.com.

Re: Patch 9.0.0649

[Tony Mechelynck]

On Mon, Oct 3, 2022 at 5:44 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.0649
> Problem:No indication when the first line is broken for 'smoothscroll'.
> Solution:   Show "<<<" in the first line.
> Files:  src/drawline.c, src/testdir/dumps/Test_smoothscroll_2.dump,
> src/testdir/dumps/Test_smoothscroll_3.dump,
> src/testdir/dumps/Test_smoothscroll_5.dump,
> src/testdir/dumps/Test_smoothscroll_6.dump

Shortly before this patch, if 'list' was on and 'listchars' contained
a "precedes:" entry, the corresponding character was displayed in the
first screen character cell if 'smoothscroll' was on and the first
visible file line began earlier. That was enough for me.

FYI, my vimrc (which sets 'encoding' to utf-8 and has ":scriptencoding
utf-8" near the top) includes the lines

if exists('+list')
  set list
  if exists('+listchars')
set lcs=eol:¶,tab:\|_,extends:>,precedes:<,conceal:*,nbsp:·
  endif
endif

(it was already like this, because even with 'wrap' as a global
default, I may want to set 'nowrap' locally in one or more windows).

I wonder if I should revert this patch locally to go back to how
'smoothscroll' worked (together with 'list' and 'listchars') at
patchlevels 644 (or maybe 645) to 648, or if it would be possible to
make it depend on some option, let's say maybe add a "firstline" flag
to the 'display' option. But I want to think it over before going away
from "standard" Vim on my own in this manner.

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/CAJkCKXtizgXdEuO9X-SPSObxZgBab-NWYLpE8TnpO%2Bbg76Q01Q%40mail.gmail.com.

After ":set sms" in my .vimrc, 'smoothscroll' is not set in files edited later (Big gvim 9.0.643)

[Tony Mechelynck]

I added in my vimrc the lines

if exists ('+smoothscroll')
set sms
endif

(the :set line is line 299).

After my handcrafted session file (sourced by invoking "gvim -S")
loads several files with 'wrap' set (also by my vimrc) in gvim (Big)
9.0.643 I tried repeatedly hitting Ctrl-E in one of these files, where
some lines are longer than the screen width. Result: Scrolled lines
scroll by file lines and ":verbose set sms?" answers
nosmoothscroll
Last set from ~/.vimrc line 299

What does work is typing
:windo set sms
at the command line: thereafter 'smoothscroll' works properly in
windows already open at that point.

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/CAJkCKXuY3y8HUSghn4CbGv%2BUti4skygUNy564WdO9-D-sKC5gw%40mail.gmail.com.

Re: At patch level 9.0.471: Segmentation fault at startup

[Tony Mechelynck]

The problem disappears after "make reconfig". Library discrepancy
between "recently changed" and "other" modules? (I'm on openSUSE
Tumbleweed, a rather "volatile" OS.)

Best regards,
Tony.

On Thu, Sep 15, 2022 at 8:48 PM Tony Mechelynck
 wrote:
>
> • I only tested the Big version.
> • This happens in both vim and gvim.
> • With my usual handcoded Session file, it happens immediately in both
> vim and gvim.
> • With only my usual vimrc, it happens immediately in gvim; in vim the
> :info splash screen is displayed, then hitting Space a couple of times
> gives SEGV.
> • With --clean, it happens immediately in gvim; in vim the splash
> screen appears then hitting Space does nothing, but :h followed by the
> Enter key gives SEGV instead of displaying the help.
>
> The following script is sourced in bash before compiling the concerned
> executable:
>
> export CONF_OPT_GUI='--enable-gui=gtk3'
> export CONF_OPT_MULTIBYTE='--enable-multibyte'
> export CONF_OPT_AUTOSERVE='--enable-autoservername'
> export CONF_OPT_FEAT='--with-features=big'
> export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'
>
> 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/CAJkCKXv3nv%3Dy5ysiPXA9vA%3DmA0uerJNZ6z7vQefxUzDvJXDjZA%40mail.gmail.com.

At patch level 9.0.471: Segmentation fault at startup

[Tony Mechelynck]

• I only tested the Big version.
• This happens in both vim and gvim.
• With my usual handcoded Session file, it happens immediately in both
vim and gvim.
• With only my usual vimrc, it happens immediately in gvim; in vim the
:info splash screen is displayed, then hitting Space a couple of times
gives SEGV.
• With --clean, it happens immediately in gvim; in vim the splash
screen appears then hitting Space does nothing, but :h followed by the
Enter key gives SEGV instead of displaying the help.

The following script is sourced in bash before compiling the concerned
executable:

export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=big'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'

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/CAJkCKXuo2KP-rMBud5C%3DQ7_w9pd2S1KMJZER_wX67J4Y8znYuQ%40mail.gmail.com.

Errors in $VIMRUNTIME/autoload/dist/ft.vim at patchlevel 9.0.376

[Tony Mechelynck]

This did not happen at patchlevel 372

Error detected while processing command line..script
/root/Session.vim[12]..BufRead Autocommands for "*.htm"..script
/usr/local/share/vim/vim90/autoload/dist/ft.vim:
line  114:
E15: Invalid expression: " '')"
E475: Invalid argument: default = '')
Error detected while processing command line..script
/root/Session.vim[12]..BufRead Autocommands for "*.htm":
E117: Unknown function: dist#ft#FThtml

The first one comes from

export def BindzoneCheck(default = '')
  if getline(1) .. getline(2) .. getline(3) .. getline(4)
  =~ '^; <<>> DiG [0-9.]\+.* <<>>\|$ORIGIN\|$TTL\|IN\s\+SOA'
setf bindzone
  elseif default != ''
exe 'setf ' .. default
  endif
enddef

This script has "vim9script" at top but my own vimrc and owncoded
Session.vim are written in pre-vim9 script language.


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/CAJkCKXsCb_G%3DsNJrK7tuRnNDfdBc2eT8DV7kcUsOCyvHBSg-TA%40mail.gmail.com.

-Wmaybe-uninitialized in Normal, Big and Huge spellfile.c after applying patches 9.0. 373 to 375

[Tony Mechelynck]

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/at-spi-2.0 -pthread-O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/spellfile.o spellfile.c
In function ‘read_region_section’,
inlined from ‘spell_load_file’ at spellfile.c:450:9:
spellfile.c:851:37: warning: ‘c’ may be used uninitialized
[-Wmaybe-uninitialized]
  851 | return c == EOF ? SP_TRUNCERROR : 0;
  |~^~~
spellfile.c: In function ‘spell_load_file’:
spellfile.c:844:17: note: ‘c’ was declared here
  844 | int c;
  | ^


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/CAJkCKXtb0sa5N8Z1uzx-39R3FTf%3DEdfvj0AFG3UOJ9hah6F%3DvA%40mail.gmail.com.

Re: Zero cmdheight

[Tony Mechelynck]

To each his choice. Personally I set 'cmdheight' to at least 2 to
avoid it bobbing up and down too much; OTOH for the sake of screen
space I set 'winminheight' to zero, 'winheight' to , 'helpheight'
to  and 'noequalalways', so all non-current windows get reduced to
just a status line and nothing else (that's what I call "Rolodex Vim"
as in an old-fashioned Rolodex card file where the current card is
open in full and all others are reduced to only an index each at top
or bottom).

So I'm not going to :set ch=0 ; but if Bram is willing to provide it
and some people want to use it that's OK for me: one of the things I
like a lot in Vim is its customizability: each user may use it in
his/her own way, and indeed several people may obtain the same result
by means of different commands.

The problem when you start providing some feature is that people are
going to use it, and then you need an extremely good reason to remove
it (not just "I asked around the office and no one was using it"). As
a counter-example, some years ago (a decade or two maybe) the Firefox
developers removed the ability to go to the Firefox "home page" at
Mozilla by clicking an icon at the top right corner of the Firefox
window. A very little thing, but immediately several users raised the
hue and cry, saying (the equivalent of) "Why did you remove that
feature? I was using it and I liked it a lot". The "official" answer
was "It isn't discoverable and no one is using it, it won't come
back". The bug was RESOLVED WONTFIX — that or maybe INVALID, I don't
remember. Happily enough for us, AFAIK Bram is conscious of this, and
he is very cautious about removing an established feature (and when he
does it's always with good reason). To the point that when introducing
the floating-point feature he felt obliged to explain that "if you
compile with +float, the expression 7.5 (with no spaces around the
dot) will mean 'the floating point seven-and-a-half' and no longer the
string '75' i.e. '7' concatenated with '5'". He even asked around if
anyone was using this old meaning of that same expression, to make
sure that this "compatibility break" would bother approximately
nobody. I approve of that: Better overdoing it a little than failing
to notice how people, if any, are using what you're going to remove.

Best regads,
Tony.

On Tue, Aug 30, 2022 at 11:32 PM Gianmaria Bajo  wrote:
>
> Another thing you would lose, and that I could not accept losing, is the 
> partial command you've typed, as when there is some pending operator, or the 
> 'f' key. It couldn't even be shown somewhere else with a plugin, as far as I 
> know.
>
> Il giorno martedì 30 agosto 2022 alle 23:23:47 UTC+2 Gianmaria Bajo ha 
> scritto:
>>
>> Just my 2 cents.
>>
>> For me it's utterly useless.
>>
>> You lose the messages, even if they show up somewhere else, they would show 
>> up in a wrong/more difficult place to read, it would be distracting. For 
>> messages, the most natural place is the bottom line. This reason alone would 
>> be enough for me never to use it.
>> You lose the feedback about the size of the visual area as Bram said, I also 
>> use it.
>> You lose feedback from commands. For example I have
>>
>> nnoremap \W :noau wall
>>
>> and in the command line I can see if some file was actually written.
>>
>> The advantage is zero, one more line is nothing if you lose the message area 
>> that you'll need to reimplement necessarily in some other form. And I'm not 
>> counting the bugs, the added complexity to the code, etc.
>> Even if it worked perfectly I would not use it.
>>
>> That some people express desire for it means nothing. Many new users that 
>> come from other programs, instinctively want things to look as in their old 
>> favorite program. Except that they won't use the feature either, once they 
>> realize it's bad. Other people say yes only because it looks shiny, but 
>> maybe they use the editor 2 minutes a day in average, or just go away the 
>> day after. Surely it's possible to ignore the desires of such audiences?
>>
>> I was already disappointed that neovim merged it just to please the 
>> brainless masses. I hope you don't do the same mistake. With all respect to 
>> the author of the patch, I understand it's interesting to try to implement 
>> new things, but this is just a bad idea, IMHO.
>>
>> Il giorno lunedì 29 agosto 2022 alle 12:24:15 UTC+2 Bram Moolenaar ha 
>> scritto:
>>>
>>>
>>> It takes a lot of effort to make zero 'cmdheight' work properly.
>>> Various bugs and corner cases keep popping up.
>>>
>>> I added the message window, so that various informative messages do not
>>> get lost, and that helps. But it also makes it more complicated.
>>>
>>> There is also one bug that I don't know how to reproduce yet, which
>>> makes the window frames too tall. The last statusline goes missing.
>>>
>>> So, I was wondering who will actually want to use this? It gives you a
>>> line of extra space, at the cost of various side effects. Especially

Re: [vim/vim] gvim --help does not show important information about configuration files (Issue #10999)

[Tony Mechelynck]

On Mon, Aug 29, 2022 at 8:39 AM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> you can also check :version output:
> [image: image]
> 
> You can then use :e $HOME/vimfiles/vimrc to open/edit the vimrc file.
>
> —
>
The attached is the same but in English and on Linux:

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/vim/vim/issues/10999/1229842897%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/CAJkCKXvZbX4HDHxaVXK7zC9U65%2BnD66rG16YZWKVKLQOnO-_DQ%40mail.gmail.com.

Build failure in Small and Tiny cmdexpand.c after applying patches 9.0 276 to 280

[Tony Mechelynck]

linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny # (make || echo 'exit
status' $? ; date) 2>&1 |tee -a make.log
[…]
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/cmdexpand.o cmdexpand.c
cmdexpand.c: In function ‘wildmenu_cleanup’:
cmdexpand.c:3624:13: error: ‘cmdline_info_T’ has no member named ‘input_fn’
 3624 | if (cclp->input_fn)
  | ^~
cmdexpand.c:3650:13: error: ‘cmdline_info_T’ has no member named ‘input_fn’
 3650 | if (cclp->input_fn)
  | ^~
make: *** [Makefile:3175: objects/cmdexpand.o] Error 1
exit status 2
Fri 26 Aug 20:18:13 CEST 2022
linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny #

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

Re: Patch 9.0.0261

[Tony Mechelynck]

On Thu, Aug 25, 2022 at 1:46 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.0261
> Problem:bufload() reads a file even if the name is not a file name. (Cyker
> Way)
> Solution:   Do not read the file when the buffer name is not a file name.
> (closes #10975)
> Files:  runtime/doc/builtin.txt, src/buffer.c,
> src/testdir/test_functions.vim

"Linking failed" in Small and Tiny ("undefined reference to
'bt_quickfix'" in buffer.c at text+0x4349):

linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny # (make || echo 'exit
status' $? ; date) 2>&1 |tee -a make.log
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/buffer.o buffer.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1version.c -o objects/version.o
link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly.
  gcc   -L/usr/local/lib -Wl,--as-needed-o vi objects/alloc.o
objects/arabic.o objects/arglist.o objects/autocmd.o objects/beval.o
objects/buffer.o objects/change.o objects/blob.o objects/blowfish.o
objects/cindent.o objects/clientserver.o objects/clipboard.o
objects/cmdexpand.o objects/cmdhist.o objects/crypt.o
objects/crypt_zip.o objects/debugger.o objects/dict.o objects/diff.o
objects/digraph.o objects/drawline.o objects/drawscreen.o
objects/edit.o objects/eval.o objects/evalbuffer.o objects/evalfunc.o
objects/evalvars.o objects/evalwindow.o objects/ex_cmds.o
objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o
objects/ex_getln.o objects/fileio.o objects/filepath.o
objects/findfile.o objects/float.o objects/fold.o objects/getchar.o
objects/gui_xim.o objects/hardcopy.o objects/hashtab.o objects/help.o
objects/highlight.o objects/if_cscope.o objects/if_xcmdsrv.o
objects/indent.o objects/insexpand.o objects/list.o objects/locale.o
objects/map.o objects/mark.o objects/match.o objects/mbyte.o
objects/memline.o objects/menu.o objects/misc1.o objects/misc2.o
objects/mouse.o objects/move.o objects/normal.o objects/ops.o
objects/option.o objects/optionstr.o objects/os_unix.o
objects/pathdef.o objects/popupmenu.o objects/popupwin.o
objects/profiler.o objects/pty.o objects/quickfix.o objects/regexp.o
objects/register.o objects/screen.o objects/scriptfile.o
objects/search.o objects/session.o objects/sha256.o objects/sign.o
objects/sound.o objects/spell.o objects/spellfile.o
objects/spellsuggest.o objects/strings.o objects/syntax.o
objects/tag.o objects/term.o objects/terminal.o objects/testing.o
objects/textformat.o objects/textobject.o objects/textprop.o
objects/time.o objects/typval.o objects/ui.o objects/undo.o
objects/usercmd.o objects/userfunc.o objects/version.o
objects/vim9cmds.o objects/vim9compile.o objects/vim9execute.o
objects/vim9expr.o objects/vim9instr.o objects/vim9script.o
objects/vim9type.o objects/viminfo.o objects/window.o
objects/bufwrite.o  objects/charset.o objects/json.o
objects/main.o objects/memfile.o objects/message.o-lSM -lICE -lXpm
-lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf  -lselinux -lgpm
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld:
objects/buffer.o: in function `open_buffer':
buffer.c:(.text+0x4349): undefined reference to `bt_quickfix'
collect2: error: ld returned 1 exit status
link.sh: Linking failed
make: *** [Makefile:2112: vi] Error 1
exit status 2
Thu 25 Aug 14:49:00 CEST 2022
linux-tuxedo:~/.build/vim/vim-hg/src/shadow-tiny #

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

--- 
You received this message because you are subscribed to the Google 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/CAJkCKXv1ZhA1szHccbDv4UtgU5k8aggV8QJKO1rNBt7WsVjHyw%40mail.gmail.com.

Re: Patch 9.0.0241

[Tony Mechelynck]

Ah, I see: Patch 242.

On Sun, Aug 21, 2022 at 11:41 PM Tony Mechelynck
 wrote:
>
> On Sun, Aug 21, 2022 at 10:05 PM Bram Moolenaar  wrote:
> >
> >
> > Patch 9.0.0241
> > Problem:"make install" does not install shared syntax file. (James 
> > McCoy)
> > Solution:   Install and uninstall the shared syntax files. (closes #10956)
> > Files:  src/Makefile
>
> After this patch, "make install" fails, as shown below. Maybe a "mkdir
> -p" line is missing for /usr/local/share/vim/vim90/syntax/shared/
>
> My environment is set by sourcing (not executing) the following script in 
> bash:
>
> #
> export CONF_OPT_GUI='--enable-gui=gtk3'
> export CONF_OPT_MULTIBYTE='--enable-multibyte'
> export CONF_OPT_AUTOSERVE='--enable-autoservername'
> export CONF_OPT_FEAT='--with-features=big'
> export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'
>
> and this is how "make install" fails:
>
> linux-tuxedo:~/.build/vim/vim-hg/src/shadow-big # make install || echo
> 'exit status' $? ; date
> […]
> cd ../runtime/syntax/shared; cp *.vim README.txt
> /usr/local/share/vim/vim90/syntax/shared
> cp: target '/usr/local/share/vim/vim90/syntax/shared': No such file or 
> directory
> make: *** [Makefile:2436: installrtbase] Error 1
> exit status 2
> Sun 21 Aug 23:17:08 CEST 2022
> linux-tuxedo:~/.build/vim/vim-hg/src/shadow-big #
>
> 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/CAJkCKXvFqL3YBPzSWg4NcQYPD2o8sKy9qVdqBA5zA0f6GwOneQ%40mail.gmail.com.

Re: Patch 9.0.0241

[Tony Mechelynck]

On Sun, Aug 21, 2022 at 10:05 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.0241
> Problem:"make install" does not install shared syntax file. (James McCoy)
> Solution:   Install and uninstall the shared syntax files. (closes #10956)
> Files:  src/Makefile

After this patch, "make install" fails, as shown below. Maybe a "mkdir
-p" line is missing for /usr/local/share/vim/vim90/syntax/shared/

My environment is set by sourcing (not executing) the following script in bash:

#
export CONF_OPT_GUI='--enable-gui=gtk3'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=big'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'

and this is how "make install" fails:

linux-tuxedo:~/.build/vim/vim-hg/src/shadow-big # make install || echo
'exit status' $? ; date
[…]
cd ../runtime/syntax/shared; cp *.vim README.txt
/usr/local/share/vim/vim90/syntax/shared
cp: target '/usr/local/share/vim/vim90/syntax/shared': No such file or directory
make: *** [Makefile:2436: installrtbase] Error 1
exit status 2
Sun 21 Aug 23:17:08 CEST 2022
linux-tuxedo:~/.build/vim/vim-hg/src/shadow-big #

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

Re: Warning or error (depending on featureset) trying to build Vim 9.0.156 (after applying patches 151 to 156)

[Tony Mechelynck]

On Sat, Aug 6, 2022 at 11:37 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > In the Huge, Big and Normal builds I get -Wmaybe-uninitialized
> > warnings for line_attr in drawline.c but they are different in each
> > case; I don't understand getting a -Wmaybe-uninitialized for a
> > variable which was given an initial value on the line declaring it.
> > This is gcc 12.1.1 20220721:
>
> line_attr itself is initialized, but it gets assigned from
> line_attr_save, which the compiler thinks might be uninitialized.
>
> The compiler could be clearer about why it came to this warning.

...especially in the Big build where it tells me nothing more than
«line_attr might be used uninitialized; it is defined as "int
line_attr = 0"».

> Otherwise it requires quite a bit of guessing.

Patch 159 clears the -eval error and patch 161 clears the +eval
warning which had me baffled. Thanks for finding out and explaining.

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

Warning or error (depending on featureset) trying to build Vim 9.0.156 (after applying patches 151 to 156)

[Tony Mechelynck]

In the Huge, Big and Normal builds I get -Wmaybe-uninitialized
warnings for line_attr in drawline.c but they are different in each
case; I don't understand getting a -Wmaybe-uninitialized for a
variable which was given an initial value on the line declaring it.
This is gcc 12.1.1 20220721:

* In the Huge build:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/at-spi-2.0 -pthread-O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations  -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/drawline.o drawline.c
drawline.c: In function ‘win_line’:
drawline.c:2767:47: warning: ‘line_attr’ may be used uninitialized
[-Wmaybe-uninitialized]
 2762 | else if ((
  |  ~
 2763 | # ifdef FEAT_DIFF
  | ~
 2764 | wlv.diff_hlf != (hlf_T)0 ||
  | ~~~
 2765 | # endif
  | ~~~
 2766 | # ifdef FEAT_TERMINAL
  | ~
 2767 | wlv.win_attr != 0 ||
  | ~~^~
 2768 | # endif
  | ~~~
 2769 | line_attr != 0
  | ~~
 2770 | ) && (
  | ~
drawline.c:590:17: note: ‘line_attr’ was declared here
  590 | int line_attr = 0;  // attribute for the whole line
  | ^

* In the Big build:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/at-spi-2.0 -pthread-O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations  -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/drawline.o drawline.c
drawline.c: In function ‘win_line’:
drawline.c:590:17: warning: ‘line_attr’ may be used uninitialized
[-Wmaybe-uninitialized]
  590 | int line_attr = 0;  // attribute for the whole line
  | ^

* In the Normal build:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/at-spi-2.0 -pthread-O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/drawline.o drawline.c
drawline.c: In function ‘win_line’:
drawline.c:2792:39: warning: ‘line_attr’ may be used uninitialized
[-Wmaybe-uninitialized]
 2792 | wlv.char_attr = line_attr;
  | ~~^~~
drawline.c:590:17: note: ‘line_attr’ was declared here
  590 | int line_attr = 0;  // attribute for the whole line
  | ^

In the Small and Timy builds, this warning does not appear, but
compilation stops after finding an undefined identifier in ex_docmd.c:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/ex_docmd.o ex_docmd.c
In file included from ex_docmd.c:14:
ex_docmd.c: In function ‘parse_command_modifiers’:
ex_docmd.c:2851:35: error: ‘e_cannot_use_hash_curly_to_start_comment’
undeclared (first use in this function)
 2851 | *errormsg =
_(e_cannot_use_hash_curly_to_start_comment);
  |
^~~~
vim.h:564:25: note: in definition of macro ‘_’
  564 | # define _(x) ((char *)(x))
  | ^

Re: Patch 9.0.0121

[Tony Mechelynck]

On Sun, Jul 31, 2022 at 6:36 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.0121
> Problem:Cannot put virtual text after or below a line.
> Solution:   Add "text_align" and "text_wrap" arguments.
> Files:  runtime/doc textprop.txt, src/textprop.c, src/structs.h,
> src/drawline.c, src/charset.c, src/testdir/test_textprop.vim,
> src/testdir/dumps/Test_prop_with_text_after_1.dump

This patch gives a fatal error in Small and Tiny builds:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/charset.o charset.c
charset.c: In function ‘win_linetabsize’:
charset.c:774:8: error: ‘chartabsize_T’ has no member named ‘cts_with_trailing’
  774 | cts.cts_with_trailing = len = MAXCOL;
  |^
make: *** [Makefile:3156: objects/charset.o] Error 1
exit status 2
Sun 31 Jul 18:41:30 CEST 2022

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/CAJkCKXsd9oaOMmVChaLhmYgH3%3DK7CsbrSA6C%2Bjt_zgw_H%2Bv4Yw%40mail.gmail.com.

Re: Patch 9.0.0072

[Tony Mechelynck]

On Tue, Jul 26, 2022 at 12:43 PM Bram Moolenaar  wrote:
>
>
> Tony wrote:
>
> > On Mon, Jul 25, 2022 at 10:16 PM Bram Moolenaar  wrote:
> > >
> > >
> > > Patch 9.0.0072 (after 9.0.0067)
> > > Problem:Compiler warning for uninitialized variable.
> > > Solution:   Initialize it. (John Marriott)
> > > Files:  src/drawline.c
> >
> > After this patch, I get a new warning in Big and Huge only, as follows:
[...]
>
> My compiler didn't complain about it.  Anyway, we can init used_tpi to
> avoid the warning.

Thanks for patch 9.0.75. My compiler describes itself as follows:

linux-tuxedo:~ # gcc --version
gcc (SUSE Linux) 12.1.1 20220629 [revision
7811663964aa7e31c3939b859bbfa2e16919639f]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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/CAJkCKXuBf1VKbPaEjHb2EUUMcbA%2BiXkUdMSLp%3Dh1xjbz56%2BwFw%40mail.gmail.com.

Re: Patch 9.0.0072

[Tony Mechelynck]

On Mon, Jul 25, 2022 at 10:16 PM Bram Moolenaar  wrote:
>
>
> Patch 9.0.0072 (after 9.0.0067)
> Problem:Compiler warning for uninitialized variable.
> Solution:   Initialize it. (John Marriott)
> Files:  src/drawline.c

After this patch, I get a new warning in Big and Huge only, as follows:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/at-spi-2.0 -pthread-O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations  -D_REENTRANT  -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/drawline.o drawline.c
drawline.c: In function ‘win_line’:
drawline.c:1541:35: warning: ‘used_tpi’ may be used uninitialized
[-Wmaybe-uninitialized]
 1541 | text_props[used_tpi].tp_id = -MAXCOL;
  |   ^
drawline.c:1489:25: note: ‘used_tpi’ was declared here
 1489 | int used_tpi;
  | ^~~~


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

Warning in drawline.c after applying patches 9.0.67 to 71

[Tony Mechelynck]

The following (as shown for Big) also appears in Huge build:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/harfbuzz -I/usr/include/freetype2
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
-I/usr/include/wayland -I/usr/include/libxkbcommon
-I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/at-spi-2.0 -pthread-O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations  -D_REENTRANT  -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/drawline.o drawline.c
drawline.c: In function ‘win_line’:
drawline.c:858:16: warning: ‘charsize’ may be used uninitialized
[-Wmaybe-uninitialized]
  858 | if (( (*mb_ptr2cells)(ptr) >= charsize || *ptr ==
TAB) && col == 0)
  |^
drawline.c:822:25: note: ‘charsize’ was declared here
  822 | int charsize;
  | ^~~~
drawline.c:1541:35: warning: ‘used_tpi’ may be used uninitialized
[-Wmaybe-uninitialized]
 1541 | text_props[used_tpi].tp_id = -MAXCOL;
  |   ^
drawline.c:1489:25: note: ‘used_tpi’ was declared here
 1489 | int used_tpi;
  | ^~~~


Normal has only the first of these (for line 858) but not the other
(for line 1541).
Tiny and Small have a different warning:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
-Wno-deprecated-declarations -D_REENTRANT -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1-o objects/drawline.o drawline.c
drawline.c: In function ‘win_line’:
drawline.c:854:18: warning: ‘charsize’ may be used uninitialized
[-Wmaybe-uninitialized]
  854 | vcol -= charsize;
  |  ^~
drawline.c:822:25: note: ‘charsize’ was declared here
  822 | int charsize;
  | ^~~~


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