The latest version of runtime/sh.vim (be4e016) breaks syntax highlighting, particularly with recognizing quoted text. It seems to be confused when quotes begin and end, and ends up treating code as quotes in some portions of the file. The previous version of runtime/sh.vim (86b4816) works fine as far as I can tell.
I've mainly tested it on a .bashrc file, but it has similar issues in some other bash files.
Master (v 9.0 with patches 1-1303)
Linux debian-dell 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Hmm, perhaps you could rectify some things, too. Please provide a (preferably short) example of the issue, don't send an image -- send text so I can test with it and not have to spend a lot of time re-typing it, and be clear about where the problem is. Thanks!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Hmm, perhaps you could rectify some things, too. Please provide a (preferably short) example of the issue, don't send an image -- send text so I can test with it and not have to spend a lot of time re-typing it, and be clear about where the problem is. Thanks!
I can also confirm that there was some kind of syntax highlighting bug after updating vim today.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
I also ran into a similar issue with the last vim update: VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Feb 11 2023 11:15:25)
This is how it looked with a previous VIM version: VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jan 12 2023 18:55:27)
And the example code:
#!/usr/bin/env bash # args: since (e.g: 2 months) set -euo pipefail worktree=$(git rev-parse --show-toplevel --show-prefix | paste -sd/ -) cd "$worktree" git log --format= --name-only --since "${*:-1970}" --relative \ | sort \ | uniq -cd \ | sort -nk1 \ | tail -n 50
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Hmm, perhaps you could rectify some things, too. Please provide a (preferably short) example of the issue, don't send an image -- send text so I can test with it and not have to spend a lot of time re-typing it, and be clear about where the problem is. Thanks!
Sure. The file starts out with comments in blue as usual, then when the code starts, almost everything is colored violet regardless of syntax purpose (except for a couple of small bits like punctuation), even through another set of comments, which should have gone back to being blue. But aside from comments later being colored blue in some places, it looks like it mostly disregards syntax rules and colors vast swaths of things violet.
Below I've pasted a portion of the text of the .bashrc file followed by a marked up version showing where colors start and stop using XML style color /color tags.
---------------------------------------------
.bashrc snippet:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
-----------------------------
.bashrc snippet with <color> </color> tags:
<blue># ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything</blue>
<violet>case $- in
*i*) <yellow>;;</yellow>
*) <yellow>return;;</yellow>
esac
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE<yellow>=</yellow><red>1000</red>
HISTFILESIZE<yellow>=</yellow><red>2000</red></violet>
<blue># check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.</blue>
<violet>shopt -s checkwinsize</violet>
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Here's another example:
#!/bin/bash
set -e -f -u -o pipefail
update_one_dir() {
if [[ ! -f ".pre-commit-config.yaml" ]]; then
return
fi
pre-commit autoupdate
if ! git check-local-copy-is-clean; then
pre-commit run --all-files
git commit -a -m 'Update hooks version.'
git push
fi
}
check-git-repos --pull_and_push "$(pwd)"
update_one_dir
Everything from line 9 (pre-commit autoupdate
) through to line 17 (update_one_dir
) is violet. The syntax of each line is shCmdSubRegion
, whereas in an earlier version it was shFunctionOne
or empty. In be4e016#diff-650e28e4ad6a5c9241345580a7136ff18b5629f3b4910a5b5a455828bca5e517R338 I see this diff at line 336/338:
syn region shCommandSub matchgroup=shCmdSubRegion start="\$(\ze[^(]" skip='\\\\\|\\.' end=")" contains=@shCommandSubList
syn region shCommandSub matchgroup=shCmdSubRegion start="\$(\ze[^(]\|$" skip='\\\\\|\\.' end=")" contains=@shCommandSubList
Reverting that line returns highlighting to normal.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Here's another example:
#!/bin/bash set -e -f -u -o pipefail update_one_dir() { if [[ ! -f ".pre-commit-config.yaml" ]]; then return fi pre-commit autoupdate if ! git check-local-copy-is-clean; then pre-commit run --all-files git commit -a -m 'Update hooks version.' git push fi } check-git-repos --pull_and_push "$(pwd)" update_one_dir
Everything from line 9 (
pre-commit autoupdate
) through to line 17 (update_one_dir
) is violet. The syntax of each line isshCmdSubRegion
, whereas in an earlier version it wasshFunctionOne
or empty. In be4e016#diff-650e28e4ad6a5c9241345580a7136ff18b5629f3b4910a5b5a455828bca5e517R338 I see this diff at line 336/338:syn region shCommandSub matchgroup=shCmdSubRegion start="\$(\ze[^(]" skip='\\\\\|\\.' end=")" contains=@shCommandSubList syn region shCommandSub matchgroup=shCmdSubRegion start="\$(\ze[^(]\|$" skip='\\\\\|\\.' end=")" contains=@shCommandSubList
Reverting that line returns highlighting to normal.
Good find. I meant to try reverting some of the changes, but I got sidetracked with some vimscript tutorials.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Have you tried sh.vim version 207 from @cecamp's website?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
I haven't tried it. But just putting the previous version of sh.vim into your home directory's .vim/syntax directory fixes the problem. Even doing that with the version of sh.vim that comes with Debian's vim works.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A simple script also fails to highlight properly.
#!/usr/bin/env sh
var="${1}";
if [ -z "${var}" ]; then
echo 'empty var';
fi
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
@pellea72 please answer the question that @k-takata asked, we want to know if version 207 fixes this problem.
It's unlikely we would use a previous version if a newer version exists.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Sorry, I didn't realize that was more recent than the version here on GitHub. Yes, his version 207 does seem to fix the problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
@pellea72 please answer the question that @k-takata asked, we want to know if version 207 fixes this problem. It's unlikely we would use a previous version if a newer version exists.
Sorry, I didn't realize that was more recent than the version here on GitHub. Yes, his version 207 does seem to fix the problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
In be4e016#diff-650e28e4ad6a5c9241345580a7136ff18b5629f3b4910a5b5a455828bca5e517R338 I see this diff at line 336/338:
syn region shCommandSub matchgroup=shCmdSubRegion start="\$(\ze[^(]" skip='\\\\\|\\.' end=")" contains=@shCommandSubList syn region shCommandSub matchgroup=shCmdSubRegion start="\$(\ze[^(]\|$" skip='\\\\\|\\.' end=")" contains=@shCommandSubList
Reverting that line returns highlighting to normal.
Changing the start="\$(\ze[^(]\|$"
to start="\$(\ze[^(]\?"
fixes this issue as well, perhaps better than simply reverting the line.
With current syntax* | With line reverted | With my change |
---|---|---|
![]() |
![]() |
![]() |
* as of cfce5cf
Perhaps @cecamp would take this simple change instead of a revert.
Aside: Adding hi def link shCmdSubRegion Error
helped me nail this down.
#!/bin/sh
case $- in *i*) ;; *) return;; esac
# Comment VAR=$(subshell) VAR=$( multi-line ) $( multi-line ) $(( arith )) $(( arith ))
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Today's update to runtime/sh.vim fixed it. Thanks for your efforts.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Closed #11977 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.