Monday, October 13, 2025

Re: Scrolling behavior when using gj and gk is jumpy

> I understand that, but my main point is that positioning the cursor serves as a way to scroll in basically every other text editor on earth and it would be nice if it did here, too.

Moving the cursor and scrolling are two different things, with the former _sometimes_ causing the latter.
Doing the former in order to obtain the latter is, well… not a very efficient use of your tools.
Especially when a) there is a whole set of commands and widgets for doing the latter (<C-e>/<C-y>/etc., scrollbars, mousewheel, trackpad…) and b) it doesn't work particularly well to begin with.

It is the same side effect at play in every text editor and every multi-line text input widget on every platform, Vim included: you are moving the cursor to a line that is outside the viewport so the viewport is moved to include that line.
Where Vim's behavior might be different from other editors in that case is how it handles wrapped lines.
And how it does it makes perfect sense given the actual purpose of jkgjgk: the full _line_ is displayed so that you can _edit_ it comfortably.

> Plus, even if I scroll with ctl-e etc, the second I move my cursor into the "paragraph," it'll do that jerky jump. 

Not with :set smoothscroll.

If you want to _scroll_, use scrolling commands (in Vim and elsewhere).
They exist for that specific purpose and they will always be better than unrelated commands that may or may not cause scrolling.
If you want pixel-perfect scrolling, use a modern non-terminal based editor.

On Monday, October 13, 2025 at 3:23:32 PM UTC+2 Marc Adler wrote:
I understand that, but my main point is that positioning the cursor serves as a way to scroll in basically every other text editor on earth and it would be nice if it did here, too.

Plus, even if I scroll with ctl-e etc, the second I move my cursor into the "paragraph," it'll do that jerky jump. 

On Sunday, October 12, 2025 at 1:47:22 AM UTC-5 Romain Lafourcade wrote:
The purpose of j, k, gj, and gk is to _position the cursor_ for the next editing command.

They might also move the buffer up or down relative to the viewport, but that is only a _side effect_ of having the cursor at the top or bottom of the window.

:help 'smoothscroll' works perfectly, but _for actual "scrolling" commands_, which j, k, gj, and gk are not. 

Use Ctrl-E, Ctrl-Y, etc. to _scroll_.

See :help scrolling.

On Saturday, October 11, 2025 at 11:25:03 AM UTC+2 Yee Cheng Chin wrote:
I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/52467ea1-1a18-4b33-91e8-4b509fb7e9f4n%40googlegroups.com.

Re: Scrolling behavior when using gj and gk is jumpy

I understand that, but my main point is that positioning the cursor serves as a way to scroll in basically every other text editor on earth and it would be nice if it did here, too.

Plus, even if I scroll with ctl-e etc, the second I move my cursor into the "paragraph," it'll do that jerky jump. 

On Sunday, October 12, 2025 at 1:47:22 AM UTC-5 Romain Lafourcade wrote:
The purpose of j, k, gj, and gk is to _position the cursor_ for the next editing command.

They might also move the buffer up or down relative to the viewport, but that is only a _side effect_ of having the cursor at the top or bottom of the window.

:help 'smoothscroll' works perfectly, but _for actual "scrolling" commands_, which j, k, gj, and gk are not. 

Use Ctrl-E, Ctrl-Y, etc. to _scroll_.

See :help scrolling.

On Saturday, October 11, 2025 at 11:25:03 AM UTC+2 Yee Cheng Chin wrote:
I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/963d9b1f-8033-4ce6-a999-44007c1686a2n%40googlegroups.com.

Re: Scrolling behavior when using gj and gk is jumpy

"You could of course file an issue to Vim to see if there will be an appetite to add this as an option."

I just found the vim dev group. I'll post there. It's a little weird that Vim is the only text editor that has this behavior.

On Saturday, October 11, 2025 at 4:25:03 AM UTC-5 Yee Cheng Chin wrote:
I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/49470204-89b2-436c-be22-98a1aea2753dn%40googlegroups.com.

Saturday, October 11, 2025

Re: Scrolling behavior when using gj and gk is jumpy

The purpose of j, k, gj, and gk is to _position the cursor_ for the next editing command.

They might also move the buffer up or down relative to the viewport, but that is only a _side effect_ of having the cursor at the top or bottom of the window.

:help 'smoothscroll' works perfectly, but _for actual "scrolling" commands_, which j, k, gj, and gk are not. 

Use Ctrl-E, Ctrl-Y, etc. to _scroll_.

See :help scrolling.

On Saturday, October 11, 2025 at 11:25:03 AM UTC+2 Yee Cheng Chin wrote:
I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/de12bf6e-8999-47a5-bdfa-3be9e7f6c724n%40googlegroups.com.

Friday, October 10, 2025

Re: Scrolling behavior when using gj and gk is jumpy

I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc.adler@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAHTeOx_iK55vy2xeOk7UCy%3DK-eeC%2B%2BVU_24Ri5zZLUKqMFg%3D5A%40mail.gmail.com.

Re: Vimdiff counting dark blue lines

What is a "unique" line in your example? All the lines in each diff block are different. That's why they are in the diff to begin with. The "dark blue" lines are just the lines that are extra compared to the other side in this example. Vim doesn't by default do line similarity tests, and it doesn't know that "Bookmarks" and "Bookmarks Toolbar" are similar lines. Maybe I don't understand what you are asking here.

Note: I said Vim doesn't do line similarity tests by default because if you do "diffopt+=linematch:100" it does do that but I don't think you are using that.

On Tue, Oct 7, 2025 at 11:24 PM Ben Yip <yebenmy@gmail.com> wrote:
`git diff --numstat A B` is a bit easier.

On Mon, Oct 6, 2025, 17:26 K otgc <konthegoldcoast@gmail.com> wrote:
'Tis not so simple as sideX minus sideY.
Out of screenshot, Bookmarks1 indeed has unique added lines that Bookmarks2 doesn't have.
However Bookmarks2 also has unique added lines that Bookmarks1 doesn't have.

I solved this 3 ways:
1:
manual count

2.
$ diff Bookmarks1 Bookmarks2 | grep '^<' | wc -l 42 $ diff Bookmarks1 Bookmarks2 | grep '^>' | wc -l 22

3.
$ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^>' | wc -l 21 $ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^<' | wc -l 41

On Sunday, 5 October 2025 at 08:54:15 UTC+2 Yee Cheng Chin wrote:
I'm imagining your diffopt does not have "inline:char" or "inline:word" right? In this case, the "dark blue lines" are basically "added lines" that are just the number of lines on the left minus the number of lines on the right. You just need to subtract them.

In order to count number of added/changed lines, you need some way of querying them using Vimscript, and currently Vim has pretty limited APIs for querying the diff structures. The one that you may want to use is `diff_hlID`. For example you can use diff_hlID(4321, 1)->synIDattr("name") and check if it's non-empty and count the lines between two sides. It requires a bit of scripting to work. There isn't a simple command to count this. I think it's more helpful if you explain exactly why you need to count these lines to begin with though.

On Fri, Oct 3, 2025 at 4:07 AM K otgc <kontheg...@gmail.com> wrote:
So not simply adding numbers to lines/rows, but totalling the unique added lines on the left and the right windows.

On Thursday, 2 October 2025 at 09:19:07 UTC+2 K otgc wrote:
The dark blue lines would be unique added lines.screenshot_20251002_091657.png

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4302280d-2e8f-45d9-bcda-7b0f7100490en%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/187336f2-b018-447f-88c5-63e23021f940n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAOhRes8hePMRdkzgO1n25hAbY4TQ4j8GOyi2xr7OeoX1MQncgg%40mail.gmail.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAHTeOx8%3DyjK7fd5jq84CtxVr%3DzXBOTSb456CVOOrHBbdosAZdw%40mail.gmail.com.

Scrolling behavior when using gj and gk is jumpy

I use Vim to write text, ie prose with paragraphs.


Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.


The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.


Smoothscroll fixes this, but only when you're scrolling down.


Is there a way to make it work when scrolling up?


Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor. 


Vim:

https://imgur.com/a/u83V2TA


VSCode:

https://imgur.com/a/8dhcXo1


Is there a way to fix this? Like I said, this behavior is unique to Vim. 

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

Monday, October 6, 2025

Re: Vimdiff counting dark blue lines

`git diff --numstat A B` is a bit easier.

On Mon, Oct 6, 2025, 17:26 K otgc <konthegoldcoast@gmail.com> wrote:
'Tis not so simple as sideX minus sideY.
Out of screenshot, Bookmarks1 indeed has unique added lines that Bookmarks2 doesn't have.
However Bookmarks2 also has unique added lines that Bookmarks1 doesn't have.

I solved this 3 ways:
1:
manual count

2.
$ diff Bookmarks1 Bookmarks2 | grep '^<' | wc -l 42 $ diff Bookmarks1 Bookmarks2 | grep '^>' | wc -l 22

3.
$ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^>' | wc -l 21 $ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^<' | wc -l 41

On Sunday, 5 October 2025 at 08:54:15 UTC+2 Yee Cheng Chin wrote:
I'm imagining your diffopt does not have "inline:char" or "inline:word" right? In this case, the "dark blue lines" are basically "added lines" that are just the number of lines on the left minus the number of lines on the right. You just need to subtract them.

In order to count number of added/changed lines, you need some way of querying them using Vimscript, and currently Vim has pretty limited APIs for querying the diff structures. The one that you may want to use is `diff_hlID`. For example you can use diff_hlID(4321, 1)->synIDattr("name") and check if it's non-empty and count the lines between two sides. It requires a bit of scripting to work. There isn't a simple command to count this. I think it's more helpful if you explain exactly why you need to count these lines to begin with though.

On Fri, Oct 3, 2025 at 4:07 AM K otgc <kontheg...@gmail.com> wrote:
So not simply adding numbers to lines/rows, but totalling the unique added lines on the left and the right windows.

On Thursday, 2 October 2025 at 09:19:07 UTC+2 K otgc wrote:
The dark blue lines would be unique added lines.screenshot_20251002_091657.png

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4302280d-2e8f-45d9-bcda-7b0f7100490en%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/187336f2-b018-447f-88c5-63e23021f940n%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAOhRes8hePMRdkzgO1n25hAbY4TQ4j8GOyi2xr7OeoX1MQncgg%40mail.gmail.com.

Re: Vimdiff counting dark blue lines

'Tis not so simple as sideX minus sideY.
Out of screenshot, Bookmarks1 indeed has unique added lines that Bookmarks2 doesn't have.
However Bookmarks2 also has unique added lines that Bookmarks1 doesn't have.

I solved this 3 ways:
1:
manual count

2.
$ diff Bookmarks1 Bookmarks2 | grep '^<' | wc -l 42 $ diff Bookmarks1 Bookmarks2 | grep '^>' | wc -l 22

3.
$ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^>' | wc -l 21 $ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^<' | wc -l 41

On Sunday, 5 October 2025 at 08:54:15 UTC+2 Yee Cheng Chin wrote:
I'm imagining your diffopt does not have "inline:char" or "inline:word" right? In this case, the "dark blue lines" are basically "added lines" that are just the number of lines on the left minus the number of lines on the right. You just need to subtract them.

In order to count number of added/changed lines, you need some way of querying them using Vimscript, and currently Vim has pretty limited APIs for querying the diff structures. The one that you may want to use is `diff_hlID`. For example you can use diff_hlID(4321, 1)->synIDattr("name") and check if it's non-empty and count the lines between two sides. It requires a bit of scripting to work. There isn't a simple command to count this. I think it's more helpful if you explain exactly why you need to count these lines to begin with though.

On Fri, Oct 3, 2025 at 4:07 AM K otgc <kontheg...@gmail.com> wrote:
So not simply adding numbers to lines/rows, but totalling the unique added lines on the left and the right windows.

On Thursday, 2 October 2025 at 09:19:07 UTC+2 K otgc wrote:
The dark blue lines would be unique added lines.screenshot_20251002_091657.png

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4302280d-2e8f-45d9-bcda-7b0f7100490en%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/187336f2-b018-447f-88c5-63e23021f940n%40googlegroups.com.

Saturday, October 4, 2025

Re: Vimdiff counting dark blue lines

I'm imagining your diffopt does not have "inline:char" or "inline:word" right? In this case, the "dark blue lines" are basically "added lines" that are just the number of lines on the left minus the number of lines on the right. You just need to subtract them.

In order to count number of added/changed lines, you need some way of querying them using Vimscript, and currently Vim has pretty limited APIs for querying the diff structures. The one that you may want to use is `diff_hlID`. For example you can use diff_hlID(4321, 1)->synIDattr("name") and check if it's non-empty and count the lines between two sides. It requires a bit of scripting to work. There isn't a simple command to count this. I think it's more helpful if you explain exactly why you need to count these lines to begin with though.

On Fri, Oct 3, 2025 at 4:07 AM K otgc <konthegoldcoast@gmail.com> wrote:
So not simply adding numbers to lines/rows, but totalling the unique added lines on the left and the right windows.

On Thursday, 2 October 2025 at 09:19:07 UTC+2 K otgc wrote:
The dark blue lines would be unique added lines.screenshot_20251002_091657.png

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4302280d-2e8f-45d9-bcda-7b0f7100490en%40googlegroups.com.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAHTeOx9jC2EM%3DL19Gwi3QmqHkeOMGpauvFssb1VWrjfTBgWKeg%40mail.gmail.com.

Friday, October 3, 2025

Re: Vimdiff counting dark blue lines

So not simply adding numbers to lines/rows, but totalling the unique added lines on the left and the right windows.

On Thursday, 2 October 2025 at 09:19:07 UTC+2 K otgc wrote:
The dark blue lines would be unique added lines.screenshot_20251002_091657.png

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4302280d-2e8f-45d9-bcda-7b0f7100490en%40googlegroups.com.

Thursday, October 2, 2025

Re: Vimdiff counting dark blue lines

The dark blue lines would be unique added lines.screenshot_20251002_091657.png

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/1d58384c-3c66-4a5b-86cd-68df0711276en%40googlegroups.com.

Tuesday, September 30, 2025

Vimdiff counting dark blue lines

Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1  4675,1  Bot and Bookmarks2  4655,1  Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/d45f1eac-39d2-475a-ada1-674df8459cd7n%40googlegroups.com.

Re: Shell Syntax Highlighting - Group bashAdminStatement

The syntax highlighting problems I've faced in the past are with syntaxes that I can't limit to a specific part of a file, such as a markdown file that has a code region in it. The problem syntaxes use the "extend" keyword when they define a region. The "extend" keyword overrides the "keepend" keyword which lets the syntax highlighting continue past the end of the code region. The c.vim, perl.vim, and vim.vim syntaxes all had this problem last I looked at it.
On Thursday, September 18, 2025 at 1:56:06 PM UTC-5 Björn Försterling wrote:
Hello,

ok, I will look into it.

Regards
Björn

On Wed Sep 17, 2025 at 10:31 PM CEST, Christian Brabandt wrote:
> Hi,
> It's not only that, it's also that certain commands (ls cat chmod) are
> only highlighted, if this is a detected bash or ksh script. I think we
> should move those to just Statements.
>
> We don't have a shell runtime file maintainer anymore and I assume
> changing this breaks some existing syntax tests. However, if you'd like
> to give it a try and unify kshStatements with bashStatement and
> bashAdminStatements (for the commands) and possibly keep those status
> keywords then please submit a PR at the Vim repo and please have a look
> at failing syntax tests (we probably just need to regenerate them).
>
> Thanks,
> Chris
>
> On Mi, 17 Sep 2025, 'Björn Försterling' via vim_use wrote:
>
>> Thank you for the answer.
>>
>> The words "daemon", "reload", "restart", "start", "status", and "stop" are
>> neither bash keywords nor external commands.
>> Maybe they were implemented for init scripts, but these are hardly used
>> anymore today.
>>
>> The words "killall", "killproc", and "nice" are external commands which is
>> ok I guess.
>> But I can't really see a pattern why some external programs are
>> highlighted and others are not.
>> They were probably selected on how frequently they are used in bash
>> scripts.
>>
>> For example if you type "systemctl start foo", then "start" is
>> highlighted, but "systemctl" is not.
>> Or for "systemctl daemon-reload" nothing will be highlighted.
>>
>> For external commands you could choose only coreutils or don't highlight
>> external commands at all.
>>
>> On Tue Sep 16, 2025 at 9:39 PM CEST, Christian Brabandt wrote:
>> >
>> > On Di, 16 Sep 2025, 'Björn Försterling' via vim_use wrote:
>> >
>> >> Hello,
>> >>
>> >> I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
>> >> The syntax highlighting for these words seems unfitting.
>> >>
>> >> syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop
>> >>
>> >> Maybe these were designed for init scripts or systemd commands.
>> >> Of course I can disable this syntax group in my own syntax files.
>> >>
>> >> But does someone know why these were implemented?
>> >
>> > So is the problem, that those are not really bash specific builtins but
>> > rather external commands? I suppose the same is true for bashStatement
>> > then.
>> >
>> > Thanks,
>> > Christian
>>
>
> Mit freundlichen Grüßen
> Christian

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/1e24e20b-3b1e-4243-934c-32afedbf979fn%40googlegroups.com.

Friday, September 26, 2025

Re: inconsistent behavior of findfunc and wildchar

I am not sure if it is posted successfully, as I cannot find it in the
google groups: <https://groups.google.com/g/vim_use>.

I created a github issue instead:
<https://github.com/vim/vim/issues/18411>.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aNdMrJPWgLKyLuZM%40ocarina-of-time.

inconsistent behavior of findfunc and wildchar

Hi,

I am recently trying the new findfunc feature. I found that the
arguments passed to findfunc was different in Linux and macOS.

For example, when I type `:find gvim ext` in cmdline, every time I
trigger `wildchar`, in macOS, findfunc receives a full list of arguments,
while in Linux, findfunc only receives the last arguments.

The minimal configuration to reproduce:

```vim
func Find(arg, _)
echom a:arg
if get(s:, 'filescache', []) == []
let s:filescache = systemlist('find . -path "*/.git" -prune -o -type f -print')
endif
return a:arg == '' ? s:filescache : matchfuzzy(s:filescache, a:arg)
endfunc
autocmd CmdlineEnter : let s:filescache = []

set wildoptions=pum
set wildmode=noselect

autocmd CmdlineChanged [:\/\?] call wildtrigger()
```

Run `:messages` after `:find gvim e`. In macOS, I got:

```
g
gv
gvi
gvim
gvim
gvim e
```

While in Linux, I got:

```
g
gv
gvi
gvim

e
```

I compiled the master branch (current commit:
<c05335082adb21d99d96374779856444a3a0688f>) in both macOS and Arch
Linux, with the following steps. (I had never compiled it myself before,
so I am not sure if it is the expected way or not.)

```bash
cd src
./configure --with-features=huge
make -j
```

I got error message `Failed to source defaults.vim` for the self
compiled vim when executing with `vim --clean`. I think it didn't affect
the behavior above.

Thanks,
Guangxiong Lin

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aNdA1e8ZdYKgDIeQ%40ocarina-of-time.

Thursday, September 18, 2025

Re: Shell Syntax Highlighting - Group bashAdminStatement

Hello,

ok, I will look into it.

Regards
Björn

On Wed Sep 17, 2025 at 10:31 PM CEST, Christian Brabandt wrote:
> Hi,
> It's not only that, it's also that certain commands (ls cat chmod) are
> only highlighted, if this is a detected bash or ksh script. I think we
> should move those to just Statements.
>
> We don't have a shell runtime file maintainer anymore and I assume
> changing this breaks some existing syntax tests. However, if you'd like
> to give it a try and unify kshStatements with bashStatement and
> bashAdminStatements (for the commands) and possibly keep those status
> keywords then please submit a PR at the Vim repo and please have a look
> at failing syntax tests (we probably just need to regenerate them).
>
> Thanks,
> Chris
>
> On Mi, 17 Sep 2025, 'Björn Försterling' via vim_use wrote:
>
>> Thank you for the answer.
>>
>> The words "daemon", "reload", "restart", "start", "status", and "stop" are
>> neither bash keywords nor external commands.
>> Maybe they were implemented for init scripts, but these are hardly used
>> anymore today.
>>
>> The words "killall", "killproc", and "nice" are external commands which is
>> ok I guess.
>> But I can't really see a pattern why some external programs are
>> highlighted and others are not.
>> They were probably selected on how frequently they are used in bash
>> scripts.
>>
>> For example if you type "systemctl start foo", then "start" is
>> highlighted, but "systemctl" is not.
>> Or for "systemctl daemon-reload" nothing will be highlighted.
>>
>> For external commands you could choose only coreutils or don't highlight
>> external commands at all.
>>
>> On Tue Sep 16, 2025 at 9:39 PM CEST, Christian Brabandt wrote:
>> >
>> > On Di, 16 Sep 2025, 'Björn Försterling' via vim_use wrote:
>> >
>> >> Hello,
>> >>
>> >> I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
>> >> The syntax highlighting for these words seems unfitting.
>> >>
>> >> syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop
>> >>
>> >> Maybe these were designed for init scripts or systemd commands.
>> >> Of course I can disable this syntax group in my own syntax files.
>> >>
>> >> But does someone know why these were implemented?
>> >
>> > So is the problem, that those are not really bash specific builtins but
>> > rather external commands? I suppose the same is true for bashStatement
>> > then.
>> >
>> > Thanks,
>> > Christian
>>
>
> Mit freundlichen Grüßen
> Christian

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/DCW5LAWEGPP3.10NWDQX3ZYLQG%40web.de.

Wednesday, September 17, 2025

Re: Shell Syntax Highlighting - Group bashAdminStatement

Hi,
It's not only that, it's also that certain commands (ls cat chmod) are
only highlighted, if this is a detected bash or ksh script. I think we
should move those to just Statements.

We don't have a shell runtime file maintainer anymore and I assume
changing this breaks some existing syntax tests. However, if you'd like
to give it a try and unify kshStatements with bashStatement and
bashAdminStatements (for the commands) and possibly keep those status
keywords then please submit a PR at the Vim repo and please have a look
at failing syntax tests (we probably just need to regenerate them).

Thanks,
Chris

On Mi, 17 Sep 2025, 'Björn Försterling' via vim_use wrote:

> Thank you for the answer.
>
> The words "daemon", "reload", "restart", "start", "status", and "stop" are
> neither bash keywords nor external commands.
> Maybe they were implemented for init scripts, but these are hardly used
> anymore today.
>
> The words "killall", "killproc", and "nice" are external commands which is
> ok I guess.
> But I can't really see a pattern why some external programs are
> highlighted and others are not.
> They were probably selected on how frequently they are used in bash
> scripts.
>
> For example if you type "systemctl start foo", then "start" is
> highlighted, but "systemctl" is not.
> Or for "systemctl daemon-reload" nothing will be highlighted.
>
> For external commands you could choose only coreutils or don't highlight
> external commands at all.
>
> On Tue Sep 16, 2025 at 9:39 PM CEST, Christian Brabandt wrote:
> >
> > On Di, 16 Sep 2025, 'Björn Försterling' via vim_use wrote:
> >
> >> Hello,
> >>
> >> I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
> >> The syntax highlighting for these words seems unfitting.
> >>
> >> syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop
> >>
> >> Maybe these were designed for init scripts or systemd commands.
> >> Of course I can disable this syntax group in my own syntax files.
> >>
> >> But does someone know why these were implemented?
> >
> > So is the problem, that those are not really bash specific builtins but
> > rather external commands? I suppose the same is true for bashStatement
> > then.
> >
> > Thanks,
> > Christian
>

Mit freundlichen Grüßen
Christian
--
Either one of us, by himself, is expendable. Both of us are not.
-- Kirk, "The Devil in the Dark", stardate 3196.1

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aMsavlajYq3Jtvmr%40256bit.org.

Re: Shell Syntax Highlighting - Group bashAdminStatement

Thank you for the answer.

The words "daemon", "reload", "restart", "start", "status", and "stop" are
neither bash keywords nor external commands.
Maybe they were implemented for init scripts, but these are hardly used
anymore today.

The words "killall", "killproc", and "nice" are external commands which is
ok I guess.
But I can't really see a pattern why some external programs are
highlighted and others are not.
They were probably selected on how frequently they are used in bash
scripts.

For example if you type "systemctl start foo", then "start" is
highlighted, but "systemctl" is not.
Or for "systemctl daemon-reload" nothing will be highlighted.

For external commands you could choose only coreutils or don't highlight
external commands at all.

On Tue Sep 16, 2025 at 9:39 PM CEST, Christian Brabandt wrote:
>
> On Di, 16 Sep 2025, 'Björn Försterling' via vim_use wrote:
>
>> Hello,
>>
>> I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
>> The syntax highlighting for these words seems unfitting.
>>
>> syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop
>>
>> Maybe these were designed for init scripts or systemd commands.
>> Of course I can disable this syntax group in my own syntax files.
>>
>> But does someone know why these were implemented?
>
> So is the problem, that those are not really bash specific builtins but
> rather external commands? I suppose the same is true for bashStatement
> then.
>
> Thanks,
> Christian

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/DCV9RD79NQKJ.34LS38F2H93K%40web.de.

Tuesday, September 16, 2025

Re: Shell Syntax Highlighting - Group bashAdminStatement

On Di, 16 Sep 2025, 'Björn Försterling' via vim_use wrote:

> Hello,
>
> I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
> The syntax highlighting for these words seems unfitting.
>
> syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop
>
> Maybe these were designed for init scripts or systemd commands.
> Of course I can disable this syntax group in my own syntax files.
>
> But does someone know why these were implemented?

So is the problem, that those are not really bash specific builtins but
rather external commands? I suppose the same is true for bashStatement
then.

Thanks,
Christian
--
"The number of Unix installations has grown to 10, with more expected."
-- The Unix Programmer's Manual, 2nd Edition, June, 1972

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aMm9AZ48kJG3iPt%2B%40256bit.org.

Re: Moderator's spam report for vim_use@googlegroups.com

approve

On Di, 16 Sep 2025, noreply-spamdigest via vim_use wrote:

> This message is being sent to you because you are a moderator of the group vim_use.
>
> The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages.
>
> If you take no action, all the messages below will be discarded automatically as spam.
>
> However, if you see any messages that are not spam below, you may approve them individually by going to:
>
> https://groups.google.com/group/vim_use/pendmsg
>
> Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to:
>
> https://groups.google.com/group/vim_use/manage_post
>
>
> ------- 1 of 1 -------
> Subject: Shell Syntax Highlighting - Group bashAdminStatement
> From: Björn Försterling <bjoern.foersterling@web.de>
> Date: Sep 16 10:22AM +0200
>
> Hello,
>
> I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
> The syntax highlighting for these words seems unfitting.
>
> syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop
>
> Approve: https://groups.google.com/group/vim_use/pendmsg?view=full&pending_id=6668635236888541789
>
>
> For more information about this message, please visit:
> https://support.google.com/groups/answer/2466386
>

Mit freundlichen Grüßen
Christian
--
Your ignorance cramps my conversation.

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aMkvbgKpF2t9gRjY%40256bit.org.

Shell Syntax Highlighting - Group bashAdminStatement

Hello,

I am wondering about the syntax group "bashAdminStatement" in "runtime/syntax/sh.vim".
The syntax highlighting for these words seems unfitting.

syn keyword bashAdminStatement daemon killall killproc nice reload restart start status stop

Maybe these were designed for init scripts or systemd commands.
Of course I can disable this syntax group in my own syntax files.

But does someone know why these were implemented?

Regards
Björn Försterling

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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/DCU2VDAK1TBC.1O9IC6COR82CH%40web.de.