[vim/vim] runtime/syntax/sh.vim: Array highlighting (Issue #20183)

[Dan Church]

h3xx created an issue (vim/vim#20183)

Steps to reproduce

1. Create a file with the following contents:

#!/bin/bash
array_a=()
array_b=()
if :; then :; fi

2. Open it in vim with syntax highlighting on :sy on and filetype=sh.

Expected behaviour

array_a=() and array_b=() should be highlighted the same but aren't.

The array_b=() gets highlighted the same as if it were a function declaration, i.e. array_b() { ...; }.

image.png (view on web)

I did a git bisect which let me know it was 12f6f20 that introduced this issue.

Version of Vim

9.2.0433

Environment

Operating System: Slackware Linux
Terminal: PuTTY for Windows
Value of $TERM: screen.xterm-256color
Shell: Bash 5.3

Logs and stack traces

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183@github.com>

[Aliaksei Budavei]

zzzyxwvut left a comment (vim/vim#20183)

Well, = is not a metacharacter etc. in Bash (v5.3.9), and it
appears array_b= is a word, which is within rule 7b.

Try patching your example as follows:

--- 20183.bash
+++ 20183_.bash
@@ -1,4 +1,7 @@
 #!/bin/bash
+set -o posix
 array_a=()
 array_b=()
-if :; then :; fi
+if :; then echo $1; fi
+array_b[0]="$1"
+array_b= ${array_b[0]}

and then run with it:

./20183_.bash ./20183_.bash

I guess we can make such ambiguous recognition configurable
via a global variable, e.g. g:sh_not_in_bash_function_name,
and support a string of arbitrary characters, e.g. ][=, for
its value; and then let users decide what other characters
in their scripts do not belong to function names in addition
to metacharacters already excluded.

Please advise, @dkearns.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/4416602649@github.com>

[dkearns]

dkearns left a comment (vim/vim#20183)

What's the bug here? array_b= is a function in bash going back to at least version 4.4 and is highlighted correctly.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/4420562284@github.com>

[Dan Church]

h3xx left a comment (vim/vim#20183)

@dkearns Bash syntax supports lists. AFAIK this peculiar to Bash.

foo=() # declare an empty list
foo+=(one two three) # append three items to list
ary=(foo bar baz 'qux xyzzy')
echo "${ary[3]}" # prints qux xyzzy

Again, prior to 12f6f20, this highlighted perfectly, but now if followed by a keyword such as if, while, break, etc, the empty list syntax (foo=()) highlights like a function declaration. It is not a function declaration in Bash. It is a variable assignment.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/4422880773@github.com>

[dkearns]

dkearns left a comment (vim/vim#20183)

Sorry, I thought the function definition still had priority here but apparently it does not which is commendably sane.

Don't we just need to disallow a leading name= in a function name? E.g., the following is valid

-array_b=()
if :; then echo "-array_b= called with: $1"; fi
-array_b= 42  # Output: -array_b= called with: 42

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/4423422061@github.com>

[Aliaksei Budavei]

zzzyxwvut left a comment (vim/vim#20183)

That's good to know, @dkearns. The leading part does dispel
my initial confusion about name parsing.

Function names cannot start with a \<\h\w*= part (unless the
optional function reserved word is used in more recent Bash
versions); however, if there is a \W character among \<.\+=,
it is a valid function name. In other words, an empty array
assignment will be claimed by Bash as intended syntax when
this name candidate is made of ASCII alphanumeric characters
and _ only.

More examples:

example.bash

#!/bin/bash

xs=()
if :; then echo not a function body!; fi
xs+=(0 1 2 3)
echo "${xs[*]}"

function f=
if :; then echo "$1"; fi
declare -f f= >/dev/null && f\= a

function f=f
if :; then echo "$1"; fi
declare -f f=f >/dev/null && f\=f b

function f=f=
if :; then echo "$1"; fi
declare -f f=f= >/dev/null && f\=f\= c

alphα=()
if :; then echo "$1"; fi
declare -f alphα= >/dev/null && alphα= d

α=()
if :; then echo "$1"; fi
declare -f α= >/dev/null && α\= e

?f=f=()
if :; then echo "$1"; fi
declare -f ?f=f= >/dev/null && ?f=f= f

==f==()
if :; then echo "$1"; fi
declare -f ==f== >/dev/null && ==f== g

function =f
if :; then echo "$1"; fi
declare -f =f >/dev/null && =f h

== ()
if :; then echo "${xs[*]}"; fi
declare -f == >/dev/null && xs= ==


f=f()
if :; then echo not a function body!; fi

f=f=()
if :; then echo not a function body!; fi

See an attempt to sort this all out in #20205.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/4435812679@github.com>

[dkearns]

dkearns left a comment (vim/vim#20183)

Thanks.

Simply rearranging the the "Identifier" and "Functions" sections doesn't appear to generate any highlighting differences in the Kornshell test directory either. However, I haven't investigated how thoroughly they're testing this area yet so keeping it as a more localised fix, as you've done in #2025, probably makes sense. This syntax file, as you know, is a bit fragile.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/4441045594@github.com>

[Janis Papanagnou]

Sorry if I hijack that thread with my question, but I see from the posts that the
sh.vim is intended for use with Kornshell, and I'm also using it for that purpose
for quite some time. (Although recently I often set the syntax for ksh sources to
zsh because some things are highlighted as errors with sh.vim that are correctly
highlighted with zsh syntax active.)

I noticed with previous releases that Kornshell syntax isn't sensibly highlighted
in several non-POSIX places; erroneous syntax is displayed. Examples are
${.../.../...} types of expansion
.sh.value types of variables
(( ... )) arithmetic expressions
$' ... ' ANSI-strings

My question is whether newer versions of sh.vim are supporting these things,
whether it's on the radar, or whether someone is even already working on fixes
in that area?

Another question is whether highlighting of in Shell embedded Awk source code
could be officially supported. Someone once provided me with an add-on (that I
had put is some user directory beneath ~/.vim/ ) but that wasn't working correctly
in all respects and sadly that add-on also vanished with a system crash I had.

Thanks.

Janis

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von dkearns <vim-dev...@256bit.org>
Gesendet: Mittwoch, 13. Mai 2026 14:39
An: vim/vim
Cc: Subscribed
Betreff: Re: [vim/vim] runtime/syntax/sh.vim: Array highlighting (Issue #20183)

[https://avatars.githubusercontent.com/u/19326]dkearns left a comment (vim/vim#20183)<https://github.com/vim/vim/issues/20183#issuecomment-4441045594>

Thanks.

Simply rearranging the the "Identifier" and "Functions" sections doesn't appear to generate any highlighting differences in the Kornshell test directory either. However, I haven't investigated how thoroughly they're testing this area yet so keeping it as a more localised fix, as you've done in #2025<https://github.com/vim/vim/issues/2025>, probably makes sense. This syntax file, as you know, is a bit fragile.

—
Reply to this email directly, view it on GitHub<https://github.com/vim/vim/issues/20183#issuecomment-4441045594>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACY5DGBKR75AHYJK2UGHAB342RUG7AVCNFSM6AAAAACYYEYX2WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINBRGA2DKNJZGQ>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905> or Android<https://play.google.com/store/apps/details>.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/20183/44410...@github.com>

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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/vim/vim/issues/20183/4441045594%40github.com<https://groups.google.com/d/msgid/vim_dev/vim/vim/issues/20183/4441045594%40github.com?utm_medium=email&utm_source=footer>.

[Doug Kearns]

Hi Janis,

On Wed, 13 May 2026 at 23:48, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

<snip>

 

My question is whether newer versions of sh.vim are supporting these things,
whether it's on the radar, or whether someone is even already working on fixes
in that area?

I think, off the top of my head, that all of those features are supported.  There's been quite a lot of work done on KornShell support in the last twelve months.

I suspect you haven't set the g:is_kornshell variable?  You can check by running :let g:is_kornshell which should return something like "g:is_kornshell #1" if it's set or an "undefined" message if not.

See :help ft-ksh-syntax for details.

Another question is whether highlighting of in Shell embedded Awk source code
could be officially supported. Someone once provided me with an add-on (that I
had put is some user directory beneath ~/.vim/ ) but that wasn't working correctly
in all respects and sadly that add-on also vanished with a system crash I had.

 No, it's not currently supported.  I don't know how your plugin used to do it but I assume it required specific heredoc markers?

Regards,

Doug

[Janis Papanagnou]

Hi Doug,

no, I haven't set the g:is_kornshell variable. If typing that as ex-command I'm getting:
"E121: Undefined variable: g:is_kornshell". Also if setting it in .vimrc there's no change.

Does that mean I have a too old vim installation, and with the next update it works?

Concerning the embedded Awk syntax... - I don't know what "heredoc markers" are.
But I was able to just recover the embedded awk add-on from an old backup file.
It's rather short; I paste it below...
Is that something that could be streamlined into the Vim distribution or shall these
things be kept individually and local under $HOME/.vim ?

"Sh: EMBEDDING LANGUAGES~
"You may wish to embed languages into sh. I'll give an example courtesy of
"Lorance Stinson on how to do this with awk as an example. Put the following
"file into $HOME/.vim/after/syntax/sh/awkembed.vim:

" AWK Embedding: {{{1
" ==============
" Shamelessly ripped from aspperl.vim by Aaron Hope.
if exists("b:current_syntax")
unlet b:current_syntax
endif
syn include @AWKScript syntax/awk.vim
syn region AWKScriptCode matchgroup=AWKCommand start=+[=\\]\@<!'+ skip=+\\'+ end=+'+ contains=@AWKScript contained
syn region AWKScriptEmbedded matchgroup=AWKCommand start=+\<awk\>+ skip=+\\$+ end=+[=\\]\@<!'+me=e-1 contains=@shIdList,@shExprList2 nextgroup=AWKScriptCode
syn cluster shCommandSubList add=AWKScriptEmbedded
hi def link AWKCommand Type

"This code will then let the awk code in the single quotes: >
" awk '...awk code here...'
"be highlighted using the awk highlighting syntax. Clearly this may be
"extended to other languages.

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Doug Kearns <dougk...@gmail.com>
Gesendet: Mittwoch, 13. Mai 2026 16:31
An: vim...@googlegroups.com

Betreff: Re: [vim/vim] runtime/syntax/sh.vim: Array highlighting (Issue #20183)

Hi Janis,

<snip>

Regards,
Doug

--

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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.

To view this discussion visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoA1%3DN0X5pVECM-MQDCa6Uniaru2J5g8YC%3D1v7v0ocH7bw%40mail.gmail.com<https://groups.google.com/d/msgid/vim_dev/CAJ1uvoA1%3DN0X5pVECM-MQDCa6Uniaru2J5g8YC%3D1v7v0ocH7bw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Doug Kearns]

On Thu, 14 May 2026 at 01:51, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

Hi Doug,

no, I haven't set the g:is_kornshell variable. If typing that as ex-command I'm getting:
"E121: Undefined variable: g:is_kornshell".  Also if setting it in .vimrc there's no change.

Does that mean I have a too old vim installation, and with the next update it works?

Vim 9.2 is the latest release and that should include most of the latest KornShell updates.  You can always grab a copy of the latest file directly from the repo (https://raw.githubusercontent.com/vim/vim/refs/heads/master/runtime/syntax/sh.vim) and stick it in ~/.vim/syntax/

Can you post a copy of an example file that is not being highlighted correctly so I can check it works with the latest syntax file?

Concerning the embedded Awk syntax... - I don't know what "heredoc markers" are.

<snip>

I meant something like

awk -f- data <<'AWK'

{ print }

AWK

We could add some heredoc regions that would highlight sed, awk and others if the heredoc token matched the filetype name.  We could also handle it based on command name like your plugin.  However, I'm not sure the sh syntax file needs any extra complications.

Regards,

Doug

[Christian Brabandt]

On Mi, 13 Mai 2026, Janis Papanagnou wrote:

> "Sh: EMBEDDING LANGUAGES~
> "You may wish to embed languages into sh. I'll give an example courtesy of
> "Lorance Stinson on how to do this with awk as an example. Put the following
> "file into $HOME/.vim/after/syntax/sh/awkembed.vim:
>
> " AWK Embedding: {{{1
> " ==============
> " Shamelessly ripped from aspperl.vim by Aaron Hope.
> if exists("b:current_syntax")
> unlet b:current_syntax
> endif
> syn include @AWKScript syntax/awk.vim
> syn region AWKScriptCode matchgroup=AWKCommand start=+[=\\]\@<!'+ skip=+\\'+ end=+'+ contains=@AWKScript contained
> syn region AWKScriptEmbedded matchgroup=AWKCommand start=+\<awk\>+ skip=+\\$+ end=+[=\\]\@<!'+me=e-1 contains=@shIdList,@shExprList2 nextgroup=AWKScriptCode
> syn cluster shCommandSubList add=AWKScriptEmbedded
> hi def link AWKCommand Type

This is the example from the help at: :h sh-embed

So it should be supported by the current shell syntax script.

Thanks,
Christian
--
You will soon forget this.

[Janis Papanagnou]

Hi Doug,

I have no single test file so I list some ad hoc constructs that are still wrongly
market as errors in my currently used 9.1 version...

a=${x/y}
b=${x/y/z}
c=${x//y/z}
d=${.sh.value}
set "${name}"+([0-9]).*

Strangely, the other two I mentioned I could not reproduce anymore - they
are now correctly highlighted in the files where I saw them - after I fiddled
with the awk-"after" file; the following are fine now (don't know what's going
on here)...

if (( j * (i + 2) )) ; then : ; fi
e=$'Hello\tworld\n'

Concerning the Awk embedded code, I never used Shell-heredocs for that,
like in your example, to read that from stdin. - I always embed the code
explicitly inline (here with some parameters/context added for variety)
something like...

# some shell code before
awk -v t="${date)" '
# awk program here
' "${conf}" "${data}"> "${outfile}"
# more shell code after that

With the add-on I had submitted I seem to recall that I had mis-highlighting
(in the past; something seems to have changed meanwhile) in cases where
two awk instances were appearing, as in...

awk '...' | awk '...'

Shell heredocs per se had never been a highlighting issue for me as far as I recall.

BTW, thanks for updating the ksh syntax-highlighting! (The errors had for long
been quite a nuisance.)

Thanks!

Regards,
Janis

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Doug Kearns <dougk...@gmail.com>

Gesendet: Donnerstag, 14. Mai 2026 15:48

An: vim...@googlegroups.com
Betreff: Re: [vim/vim] runtime/syntax/sh.vim: Array highlighting (Issue #20183)

<snip>

Regards,
Doug

--

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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.

To view this discussion visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCXuERwg1Jahpjst4_BwjXmTJiSDsjwz5urs65hegmb-g%40mail.gmail.com<https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCXuERwg1Jahpjst4_BwjXmTJiSDsjwz5urs65hegmb-g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Doug Kearns]

On Fri, 15 May 2026 at 05:02, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

Hi Doug,

I have no single test file so I list some ad hoc constructs that are still wrongly
market as errors in my currently used 9.1 version...

a=${x/y}
b=${x/y/z}
c=${x//y/z}
d=${.sh.value}
set "${name}"+([0-9]).*

When highlighting ksh2020 (this currently requires a "#!/bin/ksh2020" shebang line) those examples are highlighted correctly except for the last one that contains an incorrect paren error.  I'll try and fix it.

 

Regards,

Doug

[Janis Papanagnou]

Hi Doug,

first, some recent (last 24 h) email from you (concerning sh) landed in my
spam folder and I'm unsure I recovered it correctly (or removed it). - Please
resend if you're missing some replies concerning your emails or need further
input from me. - Thanks.

Now, concerning your email message below...

I'm not sure what "ksh2020" is supposed to mean or identify . The original
standard ksh (based on original AT&T ksh) is ksh93 (either "ksh93u+" or the
maintained version "ksh93u+m" from Martijn Dekker).
It would be inappropriate to require a change in the shebang lines of scripts
to be all changed from "#!/bin/ksh" or "#!/bin/ksh93" to "#!/bin/ksh2020".
But I may as well have just misread your statement and all you wanted to say
is probably that "*if* I'm using that ksh2020 then I need to define the shebang
line accordingly".
The Vim solution should certainly be effective for all ksh versions; specifically
for a generic "ksh" or "ksh93".

Concerning "incorrect paren error" you noticed; all the "Kornshell-patterns"
(that are in Bash called "extended patterns") should be verified, if you noticed
in one case a highlighting error with the parenthesis; @(...), *(...), +(...), ?(...), !(...),
and there's also the {n}(...} and {n,m}(...) variants (but I've never used the latter).

Thanks.

Regards,
Janis

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Doug Kearns <dougk...@gmail.com>

Gesendet: Freitag, 15. Mai 2026 17:01

An: vim...@googlegroups.com
Betreff: Re: [vim/vim] runtime/syntax/sh.vim: Array highlighting (Issue #20183)

Regards,
Doug

--

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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.

To view this discussion visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoAUtm0SHbfkF3PA-77MH0Fopx9hbnQZh_WhdjKr_%2Bi-Rw%40mail.gmail.com<https://groups.google.com/d/msgid/vim_dev/CAJ1uvoAUtm0SHbfkF3PA-77MH0Fopx9hbnQZh_WhdjKr_%2Bi-Rw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Doug Kearns]

On Sat, 16 May 2026 at 07:26, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

<snip>

 

For context I don't know KornShell and have never used it in anger, I'm just trying to help you get it highlighted.

I'm not sure what "ksh2020" is supposed to mean or identify . The original
standard ksh (based on original AT&T ksh) is ksh93 (either "ksh93u+" or the
maintained version "ksh93u+m" from Martijn Dekker).

You can read about the history of ksh2020 on the KornShell wikipedia page.  I suggested using it for testing the highlighting because I assumed, perhaps incorrectly, that it was the most featureful version.  It appears to have been abandoned.

  

It would be inappropriate to require a change in the shebang lines of scripts
to be all changed from "#!/bin/ksh" or "#!/bin/ksh93" to "#!/bin/ksh2020".

I didn't implement this configuration method but it seems that version specific KornShell highlighting is only available via a dedicated shebang line otherwise a "generic" KornShell highlighting is used.  The help states "Specific shell features are automatically enabled based on the shell detected from the shebang line ("#! ...").  For KornShell Vim detects different shell features for mksh, ksh88, ksh93, ksh93u, ksh93v, and  ksh2020."

 

The short story is that with just `let g:is_kornshell = 1` set in my vimrc and using Vim 9.1 your parameter expansion and set command examples are not highlighted correctly but when using Vim 9.2 or later only the set command is highlighted incorrectly.

So the best course of action is to upgrade to Vim 9.2 or use the current development version of runtime/syntax/sh.vim that I linked to earlier.  Then you need to determine based on your specific usage whether it's best to configure the KornShell support via the variable, shebang line, or filename extension.

<snip>

Regards,

Doug

[Janis Papanagnou]

Hi Doug!

Sorry if my tone appeared to be rough; it wasn't meant to be.
It seems with 9.2 quite some wishes will come true. :-)

The only thing that is obscure to me is how the actual version will be determined.
And I have no idea what /"generic" KornShell highlighting/ actually means below.
I hope that's the full fledged ksh93 (in form of ksh93u+m).

The shebang line will usually have /bin/sh (e.g. on AIX the 'sh' was actually a 'ksh')
or /bin/ksh or /bin/ksh93 (e.g. on my Linux system the latter are both ksh93u+m) .
The necessity to specify more than ksh (or maybe ksh93) should not be mandated
to get the appropriate syntax highlighting. (I've no idea how Vim determines the
actual ksh-evolution variant, since the shebang line won't reflect any details.) - So
if we have #!/bin/ksh which of mksh, ksh88, ksh93, ksh93u syntax will be selected?
I hope that's the full fledged ksh93 (which is mostly a superset of previous versions).

Careful with the "ksh2020", and "ksh93v(-)"; these should *not* define the base!
(You've noticed the state for the former already, and the latter is not better.)

Thanks.

Regards,
Janis

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Doug Kearns <dougk...@gmail.com>

Gesendet: Samstag, 16. Mai 2026 05:55

An: vim...@googlegroups.com
Betreff: Re: [vim/vim] runtime/syntax/sh.vim: Array highlighting (Issue #20183)

<snip>

<snip>

Regards,
Doug

--

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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.

To view this discussion visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoB8B-G%3Dem54gQejYYV%3DMN9%2BXJvHiORDB%2BRuq_fW1NEimg%40mail.gmail.com<https://groups.google.com/d/msgid/vim_dev/CAJ1uvoB8B-G%3Dem54gQejYYV%3DMN9%2BXJvHiORDB%2BRuq_fW1NEimg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Doug Kearns]

On Sat, 16 May 2026 at 15:02, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

Hi Doug!

Sorry if my tone appeared to be rough; it wasn't meant to be.

Not at all.

 

It seems with 9.2 quite some wishes will come true.  :-)

The only thing that is obscure to me is how the actual version will be determined.
And I have no idea what /"generic" KornShell highlighting/ actually means below.
I hope that's the full fledged ksh93 (in form of ksh93u+m).

"generic" appears to be a union of the more specific version feature sets.  So unless you want incorrect syntax, based on a specific version, to be flagged it should work well.

The shebang line will usually have /bin/sh (e.g. on AIX the 'sh' was actually a 'ksh')
or /bin/ksh or /bin/ksh93 (e.g. on my Linux system the latter are both ksh93u+m) .
The necessity to specify more than ksh (or maybe ksh93) should not be mandated
to get the appropriate syntax highlighting. (I've no idea how Vim determines the
actual ksh-evolution variant, since the shebang line won't reflect any details.) - So
if we have #!/bin/ksh which of mksh, ksh88, ksh93, ksh93u syntax will be selected?
I hope that's the full fledged ksh93 (which is mostly a superset of previous versions).

You get the "generic" KornShell if the shebang line is ".../ksh", if the file extension is `*.ksh` and there's no more specific shebang line, or if g:is_kornshell is set.  If none of that is in effect it also attempts to check the binary name.

You can look at most of the detection code at the top of runtime/syntax/sh.vim...if you're feeling brave.

We should add some way to configure the more specific versions with yet another config variable, g:sh_kornshell_dialect = "ksh88", and/or a file comment that is not the shebang line.

 

Careful with the "ksh2020", and "ksh93v(-)"; these should *not* define the base!
(You've noticed the state for the former already, and the latter is not better.)

It does not.  I assumed incorrectly before, as I so often do.

 

Thanks.

No problem.

Regards,

Doug 

[Christian Brabandt]

Closed #20183 as completed via 23c77d8.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/20183/issue_event/25630781927@github.com>