SUMMARY The latest syntax highlighting updates, which introduced dark yellow "if", "else", ";;"... and red (as strings) heredoc comments in the Breeze Dark theme, also broke some major syntax highlighting. STEPS TO REPRODUCE 1. Update the system as usual 2. Open a .sh file 3. See that the syntax highlight changed from the last time you opened that document 4. Notice some highlighting bugs OBSERVED RESULT - comments at the beginning of an array element line (of an array split in multiple lines) don't make the whole line grey anymore - comments after an active array element don't make the rest of line grey anymore (it is now white). Having a single quote in the comment starts the string highlight until another single quote is met, even if it's some lines below - the characters "[@]" are cyan as the rest in "${!associativeArray[@]}" but white in "${notAssociativeArray[@]}" - sometimes I see that additional single square bracket conditions after the first one have white "[]" (instead of grey), but if I copy the statement/loop on a new document they appear normally (perhaps the error is somewhere else) EXPECTED RESULT See above SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.19.15-1-MANJARO (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
The comments have normally been fixed and I confirm the problem for ${!xxx[@]}. Could you give a code that reproduces the [] issue? It may depend on the lines that precede.
The update broke a few more things: 1. binary operators: apart from #431036, it interprets all code after "||" as string (red): if [[ "$foo" ]] || [[ "$bar" ]]; then ... ^----------------- ^--------------------- fine red=string 2. backticks: #431036 3. "translation strings" are interpreted too greedy: $"foobar..." marks the rest of the file as string (red), i.e. it does not end with the first double quote. 4. binary operators in "if" break functions: the function body is interpreted fine but the closing "}" is underlined in red bla() { if false && true; then echo fi } ^-- underlined This also happens without the "if" keyword: bla() { [[ cond ]] && foo } ^-- underlined 5. If I move the "[[ cond ]] && foo" line from 4. outside the function the same as in 1. and 3. happens. Weirdly enough, this fixed itself after I moved the line a few times in and out - but then it happened again. I then tried the same in a different script where it worked with certain functions but failed with others. bla() { [[ cond ]] && foo } ^-- underlined (same example as 4.) ---- [[ cond ]] && foo ^.... from this point everything is red bla() { echo }
1 to 5: all fixed in 5.79 :)
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/syntax-highlighting/-/merge_requests/151
Git commit 04e16355f52fc83ffa5821890d91009e26d6da99 by Jonathan Poelen. Committed on 16/01/2021 at 01:21. Pushed by cullmann into branch 'master'. Bash: fix } in ${!xy*} and more Parameter Expansion Operator (# in ${#xy} ; !,*,@,[*],[@] in ${!xy*}) M +3 -3 autotests/html/highlight.sh.dark.html M +3 -3 autotests/html/highlight.sh.html M +3 -3 autotests/reference/highlight.sh.ref M +8 -5 data/syntax/bash.xml https://invent.kde.org/frameworks/syntax-highlighting/commit/04e16355f52fc83ffa5821890d91009e26d6da99
Another example of problematic code: ``` case "$1" in "a") run_a;; "b") run_b;; *) echo "Plase choose between 'a' or 'b'" && exit 1;; esac ```
Git commit 322fe5624fa050ab2255a9683538ae9be0b8603c by Jonathan Poelen. Committed on 20/01/2021 at 22:23. Pushed by cullmann into branch 'master'. Bash, Zsh: fix cmd;; in a case M +7 -0 autotests/folding/highlight.sh.fold M +7 -0 autotests/folding/test.zsh.fold M +7 -0 autotests/html/highlight.sh.dark.html M +7 -0 autotests/html/highlight.sh.html M +7 -0 autotests/html/test.zsh.dark.html M +7 -0 autotests/html/test.zsh.html M +7 -0 autotests/input/highlight.sh M +7 -0 autotests/input/test.zsh M +7 -0 autotests/reference/highlight.sh.ref M +7 -0 autotests/reference/test.zsh.ref M +3 -4 data/syntax/bash.xml M +3 -4 data/syntax/zsh.xml https://invent.kde.org/frameworks/syntax-highlighting/commit/322fe5624fa050ab2255a9683538ae9be0b8603c
Thank you, the only thing I still see is - the characters "[@]" are cyan as the rest in "${!associativeArray[@]}" but white in "${notAssociativeArray[@]}" Everything else seems to have been fixed
You have to wait for version 5.79 which has not yet been released. For the other fixes, I hadn't noticed that they were already in 5.78.
Is it possible to have "flag" in ``` while getopts 'hq' flag; do case "${flag}" in h) print_help && exit;; q) quiet=true;; *) exit 1 ;; esac done ``` highlighted as a variable like "line" in ``` while read -r line; do : done ``` ?
Please could you make the request in another issue or on the project repository (https://invent.kde.org/frameworks/syntax-highlighting/-/issues)? It would be better than to continue on this thread which is fixed and which no longer concerns a regression.
*** Bug 430483 has been marked as a duplicate of this bug. ***
Other issue this is fine: ``` case "$1" in a) function_a ;; b) function_b ;; esac ``` this is not: ``` case "$1" in a) function_a;; b) function_b;; esac ```
This is fixed in 5.79, the current version in manjaro is 5.78 (which should not be long, there is about 1 month between each version).
Got the new version, with dark green HEREDOC delimiters. I encountered a with following code: ``` export ID="XXXXXX" # comment ``` "#" is white and "comment" is cyan like the variable "ID"
Extglob patterns break the parsing as well: ``` # in quotes "${var#lo+(r)em}" # everything that follows is treated as "string" (red) ``` and ``` # without quotes ${var#lo+(r)em} # everything that follows is treated as "different string" (black) ``` It happens with all extglob patterns: ?(...), *(...), +(...), @(...), !(...) Kate version 21.12.0 Frameworks version 5.89.0 Should I open a new bug report for this?
> Should I open a new bug report for this? Yes, this issue is long since resolved and no one should read it anymore. Except maybe those who are still subscribed to it (I won't answer it anymore since I'm unsubscribing to it).