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.

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.

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.

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.