Re: [vim/vim] patch 9.0.0817 (fb0cf23)

mattn

unread,

Oct 28, 2022, 4:38:35 AM10/28/22

to vim/vim, Subscribed

@brammool Take care of yourself, and get better soon!

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

K.Takata

unread,

Oct 28, 2022, 4:51:15 AM10/28/22

to vim/vim, Subscribed

It looks that this change is unexpected.
Should be reverted, I think:

--- a/src/Makefile
+++ b/src/Makefile
@@ -355,7 +355,7 @@ CClink = $(CC)
 #CONF_OPT_GUI = --enable-gui=gnome2 --disable-gtktest
 #CONF_OPT_GUI = --enable-gui=gtk3
 #CONF_OPT_GUI = --enable-gui=gtk3 --disable-gtktest
-CONF_OPT_GUI = --enable-gui=motif
+#CONF_OPT_GUI = --enable-gui=motif
 #CONF_OPT_GUI = --enable-gui=motif --with-motif-lib="-static -lXm -shared"
 
 # Uncomment this line to run an individual test with gvim.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

K.Takata

unread,

Oct 28, 2022, 4:58:46 AM10/28/22

to vim/vim, Subscribed

Anyway, please take care of yourself.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Maxim Kim

unread,

Oct 28, 2022, 5:15:05 AM10/28/22

to vim/vim, Subscribed

While compiling I get error:

bufwrite.c: In function ‘buf_write’:

bufwrite.c:2055:45: error: invalid type argument of ‘->’ (have ‘struct bw_info’)

 2055 |                 (void)write_eintr(write_info->bw_fd, "\x1a", 1);

      |                                             ^~

make[1]: *** [Makefile:3098: objects/bufwrite.o] Error 1

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Shougo

unread,

Oct 28, 2022, 5:29:28 AM10/28/22

to vim/vim, Subscribed

It should be endoffile?

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Christopher Plewright

unread,

Oct 28, 2022, 5:29:47 AM10/28/22

to vim/vim, Subscribed

make it like this;
(void)write_eintr(write_info.bw_fd, "\x1a", 1);
note -> not right, use .

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Maxim Kim

unread,

Oct 28, 2022, 5:36:04 AM10/28/22

to vim/vim, Subscribed

it compiles but errors with:

~/prj/vim $ vim 
E356: get_varp ERROR

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

mattn

unread,

Oct 28, 2022, 5:57:44 AM10/28/22

to vim/vim, Subscribed

diff --git a/src/bufwrite.c b/src/bufwrite.c
index 713dac561..12c5c7a47 100644
--- a/src/bufwrite.c
+++ b/src/bufwrite.c
@@ -2052,7 +2052,7 @@ restore_backup:
 	    }
 	    if (!buf->b_p_fixeol && buf->b_p_eof)
 		// write trailing CTRL-Z
-		(void)write_eintr(write_info->bw_fd, "\x1a", 1);
+		(void)write_eintr(write_info.bw_fd, "\x1a", 1);
 
 	    // write failed or last line has no EOL: stop here
 	    if (end == 0
diff --git a/src/option.c b/src/option.c
index 329781008..87764e231 100644
--- a/src/option.c
+++ b/src/option.c
@@ -5490,6 +5490,7 @@ get_varp(struct vimoption *p)
 #ifdef FEAT_EVAL
 	case PV_TFU:	return (char_u *)&(curbuf->b_p_tfu);
 #endif
+	case PV_EOF:	return (char_u *)&(curbuf->b_p_eof);
 	case PV_EOL:	return (char_u *)&(curbuf->b_p_eol);
 	case PV_FIXEOL:	return (char_u *)&(curbuf->b_p_fixeol);
 	case PV_ET:	return (char_u *)&(curbuf->b_p_et);

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Tony Mechelynck

unread,

Oct 28, 2022, 6:05:58 AM10/28/22

to vim/vim, Subscribed

About the change at src/Makefile:258:

The Google interface in SeaMonkey doesn't let me add a comment under that line.
The documentation recommends to set configure parameters by editing the Makefile, which IMHO is dangerous. This is one kind of problem it can lead to.

I leave the Makefile unchanged and I set my configure parameters by means of environment variables (each set of which is kept written up in a script to be sourced by bash). This way I can compile five Vim executables (each in its own shell and in its own shadow directory) at the same time with a single Makefile:

one minimum minimorum Tiny build, with no GUI
one Small (or nowadays Tiny) build with Motif GUI
one Normal build with GTK3 GUI
one Big (or nowadays Huge) build with no interpreted languages and GTK3 GUI
one Huge build with several interpreted languages and GTK3 GUI.
This way, each of them gets its own configuration, gets it as I want it even if make decides to reconfigure, and they don't throw wrenches into each other's cogwheels.

Best regards,
Tony.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christopher Plewright

unread,

Oct 28, 2022, 6:46:58 AM10/28/22

to vim/vim, Subscribed

yes, that works for me @mattn

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 28, 2022, 11:49:43 AM10/28/22

to vim/vim, Subscribed

> It looks that this change is unexpected.
> Should be reverted, I think:

> ```diff

> --- a/src/Makefile
> +++ b/src/Makefile
> @@ -355,7 +355,7 @@ CClink = $(CC)
> #CONF_OPT_GUI = --enable-gui=gnome2 --disable-gtktest
> #CONF_OPT_GUI = --enable-gui=gtk3
> #CONF_OPT_GUI = --enable-gui=gtk3 --disable-gtktest
> -CONF_OPT_GUI = --enable-gui=motif
> +#CONF_OPT_GUI = --enable-gui=motif
> #CONF_OPT_GUI = --enable-gui=motif --with-motif-lib="-static -lXm -shared"
>
> # Uncomment this line to run an individual test with gvim.

> ```

Yes, that slipped through. I often compile with Motif because it's
twice as fast as GTK. I'll just make a commit without tag to fix this,
I assume that should be fine.

--
DENNIS: You can't expect to wield supreme executive power just 'cause some
watery tart threw a sword at you!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 28, 2022, 11:57:29 AM10/28/22

to vim/vim, Subscribed

> It should be `endoffile`?

I cannot see the context of this remark. It's OK in optiondefs.h, where are
you looking?

--
ARTHUR: Now stand aside worthy adversary.
BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
ARTHUR: A scratch? Your arm's off.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 28, 2022, 11:58:22 AM10/28/22

to vim/vim, Subscribed

> While compiling I get error:
> ```
> bufwrite.c: In function ‘buf_write’:
> bufwrite.c:2055:45: error: invalid type argument of ‘->’ (have ‘struct bw_info’)
> 2055 | (void)write_eintr(write_info->bw_fd, "\x1a", 1);
> | ^~
> make[1]: *** [Makefile:3098: objects/bufwrite.o] Error 1
>

> ```

I had fixed that, but apparently it didn't get through. Let me just
make a simple commit, we can add a description later.

--
BLACK KNIGHT: None shall pass.
ARTHUR: I have no quarrel with you, brave Sir knight, but I must cross
this bridge.
BLACK KNIGHT: Then you shall die.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

zeertzjq

unread,

Oct 28, 2022, 12:04:03 PM10/28/22

to vim/vim, Subscribed

There are two 'endofline' in options.txt

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 28, 2022, 12:05:54 PM10/28/22

to vim/vim, Subscribed

> ```diff

> diff --git a/src/bufwrite.c b/src/bufwrite.c
> index 713dac561..12c5c7a47 100644
> --- a/src/bufwrite.c
> +++ b/src/bufwrite.c
> @@ -2052,7 +2052,7 @@ restore_backup:
> }
> if (!buf->b_p_fixeol && buf->b_p_eof)
> // write trailing CTRL-Z

> - (void)write_eintr(write_info->bw_fd, "\x1a", 1);

> + (void)write_eintr(write_info.bw_fd, "\x1a", 1);
>
> // write failed or last line has no EOL: stop here
> if (end == 0

Did that one already.

> diff --git a/src/option.c b/src/option.c
> index 329781008..87764e231 100644
> --- a/src/option.c
> +++ b/src/option.c
> @@ -5490,6 +5490,7 @@ get_varp(struct vimoption *p)
> #ifdef FEAT_EVAL
> case PV_TFU: return (char_u *)&(curbuf->b_p_tfu);
> #endif
> + case PV_EOF: return (char_u *)&(curbuf->b_p_eof);
> case PV_EOL: return (char_u *)&(curbuf->b_p_eol);
> case PV_FIXEOL: return (char_u *)&(curbuf->b_p_fixeol);
> case PV_ET: return (char_u *)&(curbuf->b_p_et);

> ```

Strange that this went missing. I'll add it now, please suggest a git
command for more info on the commit if needed.

--
ARTHUR: You are indeed brave Sir knight, but the fight is mine.
BLACK KNIGHT: Had enough?
ARTHUR: You stupid bastard. You havn't got any arms left.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 28, 2022, 12:33:42 PM10/28/22

to vim/vim, Subscribed

Ah, a copy/paste that I didn't finish. Can make it a runtime files update,
then also the tags get updated.
The description also isn't quite right, I hope you get the idea.

On Fri, 28 Oct 2022 at 17:03, zeertzjq ***@***.***> wrote:

> There are two 'endofline' in options.txt
>
> —

> Reply to this email directly, view it on GitHub

> <https://github.com/vim/vim/commit/fb0cf2357e0c85bbfd9f9178705ad8d77b6b3b4e#r88207496>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACBCVPYMSUGZS5XH63XWVQLWFP2N5ANCNFSM6AAAAAARQ26G7I>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***
> com>
>

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Gary Johnson

unread,

Oct 28, 2022, 2:02:57 PM10/28/22

to reply+ACY5DGD3LJEJEQVLDC...@reply.github.com, vim...@googlegroups.com

On 2022-10-28, Bram Moolenaar wrote:

> Strange that this went missing. I'll add it now, please suggest a git
> command for more info on the commit if needed.

I understand your frustration with git. Here are a couple of
commands I use to examine commits.

To see the commit messages in a pager, including the names of the
affected files:

$ git log --name-only --decorate

To see side-by-side diffs of the changes between two commits, for
example, between the commit with the tag v9.0.0805 and its
predecessor:

$ git difftool v9.0.0805^..v9.0.0805

You can specify any two commits by their tags, by their commit
hashes, or by either of those with modifiers such as ^ to indicate
a parent.

The best way to fix a bad commit really depends on the situation and
on what has been pushed. It's generally difficult to change
anything already pushed. In my limited experience, the safest way
to make a change is to create a new commit that contains the code
the way you want it, including any reversions, and commit and push
that. Anything fancier than that, that you don't understand well,
can easily lead to mistakes and more frustration.

HTH,
Gary

vim-dev ML

unread,

Oct 28, 2022, 2:03:15 PM10/28/22

to vim/vim, vim-dev ML, Your activity

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Oct 28, 2022, 5:23:41 PM10/28/22

to vim...@googlegroups.com, vim-dev ML

> On 2022-10-28, Bram Moolenaar wrote:
>
> > Strange that this went missing. I'll add it now, please suggest a git
> > command for more info on the commit if needed.
>
> I understand your frustration with git. Here are a couple of
> commands I use to examine commits.
>
> To see the commit messages in a pager, including the names of the
> affected files:
>
> $ git log --name-only --decorate
>
> To see side-by-side diffs of the changes between two commits, for
> example, between the commit with the tag v9.0.0805 and its
> predecessor:
>
> $ git difftool v9.0.0805^..v9.0.0805
>
> You can specify any two commits by their tags, by their commit
> hashes, or by either of those with modifiers such as ^ to indicate
> a parent.

Commit hashes are unreadable, you can't really check what commit you are
using. That why I always use tags, they are human readable.

To get a diff like what I use in patch emails this is the closest I
could get:

% git difftool --extcmd="diff -c" --no-prompt v8.1.2098 v8.1.2099

> The best way to fix a bad commit really depends on the situation and
> on what has been pushed. It's generally difficult to change
> anything already pushed. In my limited experience, the safest way
> to make a change is to create a new commit that contains the code
> the way you want it, including any reversions, and commit and push
> that. Anything fancier than that, that you don't understand well,
> can easily lead to mistakes and more frustration.

When we moved from Google code to github someone created a very long
list of git commands to fixup all the problems in the history. It's a
lot of work to figure out and verify it ends up right, but it is
possible. I rather have someone else figure this out for me!
I also just get upset by how git commands are made in a way it seems
they are intentionally difficult to use. Like in intelligence test,
instead of being user friendly.

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

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\

Bram Moolenaar

unread,

Oct 28, 2022, 5:23:55 PM10/28/22

to vim/vim, vim-dev ML, Comment

> About the change at src/Makefile:258:

> 1. The Google interface in SeaMonkey doesn't let me add a comment under that line.
> 2. The documentation recommends to set configure parameters by editing

> the Makefile, which IMHO is dangerous. This is one kind of problem it
> can lead to.

The thing is that providing examples for configure arguments in some
readme or help file means they are not easy to use. You need to create
your own shell script with the configure command from them, set
environment variables, or some other way.

Writing your own shell script is safest, but you need to copy/paste
lines from somewhere. I do this for a few programs that don't have
another way and that I build once in a while. E.g. building the latest
xterm with my preferred options (there are quite a few choices that
usually take some trial and error to find out what you want, you want to
remember that for next time). This actually applies to most programs
using autoconf.

Setting shell environment variables is possible. It has one advantage:
if you have some preference that applies to multiple programs. For
example compiler flags and libraries. It has one huge disadvantage:
it's very easy to pick up a preference intended for building another
program. E.g. setting $CFLAGS to contain "-g" and forgetting about it.
It may override the $CFLAGS that should actually be used, without any
warning. That is why I recommend using the shell script option.

Vim traditionally supports building on many different systems and also
supports just running "make", instead of requiring a separate
"configure" run, which I have always found weird. The only disadvantage
of editing src/Makefile is that when syncing you need to merge your
changes. Which is actually a good thing, you are forced to look at what
changed and reconsider your choice. It's just a bit of work to do.

> I leave the Makefile unchanged and I set my configure parameters by
> means of environment variables (each set of which is kept written up
> in a script to be sourced by bash). This way I can compile five Vim
> executables (each in its own shell and in its own shadow directory) at
> the same time with a single Makefile:

> * one minimum minimorum Tiny build, with no GUI
> * one Small (or nowadays Tiny) build with Motif GUI
> * one Normal build with GTK3 GUI
> * one Big (or nowadays Huge) build with no interpreted languages and GTK3 GUI
> * one Huge build with several interpreted languages and GTK3 GUI.
> This way, each of them gets its own configuration, gets it as **I**

> want it even if make decides to reconfigure, and they don't throw
> wrenches into each other's cogwheels.

This sounds similar to using "make shadow" and then adjusting the
choices in each shadow. Problem here is that syncing doesn't re-shadow.
Any changes to the shadow mechanism requires wiping out stuff and doing
it all over again. I'm not aware of an "incremental shadow" mechanism.

--
Any resemblance between the above views and those of my employer, my terminal,
or the view out my window are purely coincidental. Any resemblance between
the above and my own views is non-deterministic. The question of the
existence of views in the absence of anyone to hold them is left as an
exercise for the reader. The question of the existence of the reader is left
as an exercise for the second god coefficient. (A discussion of
non-orthogonal, non-integral polytheism is beyond the scope of this article.)
(Ralph Jennings)

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\

/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

N-R-K

unread,

Oct 29, 2022, 5:59:34 AM10/29/22

to vim/vim, vim-dev ML, Comment

please suggest a git
command for more info on the commit if needed.

I personally use git commit -v which shows a diff of what's being committed.
This is quite handy and saved me a bunch of times.

If you notice something is missing, quit the editor without saving the changes and the commit will be aborted. Then you can add the missing stuff with git add.

And if something got added by mistake, you can clear it with git restore --staged and then selectively add things with git add -p.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Christian Brabandt

unread,

Nov 3, 2022, 5:01:48 AM11/3/22

to vim/vim, vim-dev ML, Comment

I personally use git commit -v which shows a diff of what's being committed.

I agree and I have set the following to always include a diff below the actual commit message, to verify what I will commit

git config --global commit.verbose true

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Tony Mechelynck

unread,

Nov 3, 2022, 10:21:18 AM11/3/22

to vim/vim, vim-dev ML, Comment

I use shadow directories with the following caveats:

When creating the shadow directories, I create them with names starting with "shadow-" (which are mentioned in .hgignore) using for instance "SHADOWDIR=shadow-huge make -e shadow" (-e is required to override the $SHADOWDIR defined in the Makefile)
Then I replace the copy of the src/Makefile in each shadow-directory by a symbolic link to it (as ../Makefile).
Whenever a new C source file is added to the repository, I have to manually create a link to it in each shadow directory. Getting make "No rule to make xxxx.o" error reminds me of it if I forget. Other new files I get automagically by virtue of symlinks src/shadow-xxx/proto -> ../proto, src/runtime -> ../runtime, etc., created once and for all by "make shadow".
I use one separate konsole tab and shell for each Vim featureset, with a cd to the appropriate shadow directory and sourcing (in bash) the appropriate export lines for that build. No other binary is compiled in the same shell.
When an update to important system libraries comes around, I run "make reconfig" as a precaution against crashes due to linking modules compiled for different versions of the libraries. This is probably an excess precaution.
Most other times, running "(make || echo 'exit status' $? ;date) 2>&1 | tee -a make.log" (with optionally a -j3 argument to make) followed by "make install" in the "principal" shadowdir and "make installvimbin" in all others, allows me to incrementally compile five Vims in parallel with different featuresets.
This way, I get changes to the Makefile by virtue of using a link to it rather than a copy, I have to manually link to additional C sources but it is not a big problem, if C sources are deleted I get hanging links which are not a problem because the corresponding objects, no more needed by the link phase, aren't built anymore, and all in all it works very well. If you aren't aware of an incremental shadow mechanism, I am.