Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

odd highlighting of nested process substitution in for loops #45

Open
marienz opened this issue May 3, 2021 · 0 comments
Open

odd highlighting of nested process substitution in for loops #45

marienz opened this issue May 3, 2021 · 0 comments

Comments

@marienz
Copy link

marienz commented May 3, 2021

Highlighting of for loops over process substitution gets a little confused if there's more than one level. Example (from a real script):

    for i in (seq (count $PATH) -1 2)

This is currently highlighted with font-lock-string-face from the first open parenthesis up to the first closing parenthesis (after $PATH), then normally after that. This looks "off" to me: I keep glancing at that line and thinking I have an unbalanced quote or parenthesis (I think the final closing parenthesis being highlighted differently from its matching opening parenthesis is a large part of the problem).

It looks like this happens because fish-mode highlights up to the closing parenthesis by non-greedily skipping over other characters. I'm not very familiar with either fish or Emacs syntax highlighting, but maybe it would work better to search for the end of the current command (similarly to how the "command name" highlighting works: by searching for a semicolon or newline, more or less)? Unless Emacs has regexp extensions for matching balanced groups or something similar finding the right closing parenthesis directly won't handle cases like this one, but I'm not sure if fish has cases other than backslash-escaped newlines that complicate finding the end of the "for" command.

(Personally I'd prefer to not treat process substitution specially here, but as commit b5f28b0 mentions that's very much a matter of preference, and doing what it currently does using pure regexp is hard...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant