Fire fish_postexec event on tokenization error#6880
Conversation
This is a fix for issue fish-shell#6816 "shell integration with tokenization error"
|
So I've been thinking about this, and I think it would be nicer to introduce a new event if there's an error. The reason being that it's not entirely clear that postexec handlers would be useful if nothing was actually executed. Your function would then just register for both events. |
|
A distinct signal for error would also work. Wold it be only for tokenization errors (corresponding to my patch), or also other kinds of errors (which would require other changes)? Based on |
I would imagine all kinds of errors that cause us not to execute a command - I think that might be
But I think for now just the tokenization will suffice. |
There was a problem hiding this comment.
In addition to faho's changes, please move the event posting to outside the reader_shell_test call (which is supposed to only do syntax validation). Here is where fish acts on the test result.
|
Ok - I moved the However, this is still one (less serious) problem: The error message is printed while we're still in input mode, so it is printed with the wrong style. Fixing this using heuristics is no doubt possible, but it would be less complex/fragile to have an explicit |
Also remove the "event will be emitted even if the command is invalid" because it's not the case anymore, AFAICT. See #6880.
Fixes issue #6816 "shell integration with tokenization error"
TODOs:
CHANGELOG.md note could be:
A tokenization error (such as command-line containing just
)) now raises thefish_postexecevent, as documented.