Skip to content

[Aborted] sh.lang: improve recognition of "case ... esac" statement (afterpart)

Gaël Bonithon requested to merge neyfag/gtksourceview:patch-sh into master
  • Allow items to be separated by spaces or end operators again (regression introduced by !67 (closed))
  • Give a better fix to #77 (closed) (less restrictive, such that patterns like var=) are properly recognized)
  • Specify test file

Not all cases are taken into account (it's difficult, and perhaps out-of-scope), but it should still be better (not sure, see below).

I'm not sure this PR is a good idea, nor PR !67 (closed). Actually, I'm not sure that item recognition in "case … esac" statements is a good idea. Here is why.

  • With this PR, item recognition is quite good, but the regex used is too big and makes mousepad (xfce text editor) suffer on my computer (a modest laptop). Furthermore, I encounter side-effects that I don't fully understand: some expressions may become grey, while they are not recognized as items in the "case … esac" statement. Example:

    'a' '/usr/' '/etc/index.txt'

    where "a" may be any letter, "/usr" and "/etc" any existing directory, and "index.txt" is mandatory. An other strange case:

    var1=${var2/a/b.txt}

    where "var1" and "var2" may be any string, "a" and "b" any letter, and ".txt" is mandatory.

  • With PR !67 (closed), issue #77 (closed) is solved, but a regression is introduced concerning the recognition of items separated by spaces or double semi-colons, like

    for $var in item1)
;; item2)
;;item3)
esac

  • I don't know if the situation preceding !67 (closed) is better or worst, but it's not good: some valid items are not recognized, and (most important) some false items are recognized.

Finally, I had a look at what is done in Github editor atom (it was installed on my computer): no item recognition is done in "case … esac" statments. Maybe it's not a bad idea?

I let you close this PR, in case you do not want to close it immediately.

Edited by Gaël Bonithon

Merge request reports