elixir-lsp
Whole module is highlighted on a local do..end mismatch
This is in VSCode with the ElixirLS extension version 0.26.4, under Elixir 1.17.3 / OTP 27.
There is a distracting behavior of an error highlighting I was trying to figure out and so far couldn't. On pretty much any non-matching do..end block the whole module gets highlighted with squiggles which is quite distracting. As during editing it is not rare to have non-matching do..end blocks, this happens a lot.
I couldn't find a way to disable this behavior, please point me at it if there is one. For me the desired behavior on non-matching blocks would be to only have the opening bit of the deepest affected block selected, and not the whole of it, and of course not anything outside.
Details
What seems notable, the information about the locality of the error is present in the error message and maybe can be used to limit the error selection to the relevant area.
Here is an example of a non-matching square bracket, the effect is reasonably local squiggles, although could be made better by only highlighting the unmatched opening bracket. Maybe it could also rely on indentation to not highlight anything below the expected location, but this is debatable.
Here is a non-matching curly bracket, similar behavior, still acceptable:
And here is a non-matching do..end block where the whole module gets highlighted which is not only distracting, but also useless:
Notably, if we look at the error details, there is a hint on the actual locality of the non-matched do, which happens to be at line 9:
In a situation with a deeper nested do..end the behavior is similarly undesirable, but in this case the locality is not detected correctly, as the erroneous line is now 23, and not 9. Even then, limiting the selection to the block starting at line 9 would be helpful.
Counterpoint: the same behaviour in typescript
similar behaviour in python
similar behaviour in c#
Notably, if we look at the error details, there is a hint on the actual locality of the non-matched do, which happens to be at line 9:
In a situation with a deeper nested do..end the behavior is similarly undesirable, but in this case the locality is not detected correctly, as the erroneous line is now 23, and not 9. Even then, limiting the selection to the block starting at line 9 would be helpful.
@nicnilov Please report that to elixir repo. ElixirLS only emits diagnostics based on errors and warnings returned by the compiler. The ranges and error locations are generated by elixir tokenizer/parser/compiler.
@lukaszsamson Thank you for the prompt response. I have reported the issue to Elixir repo (Issue#14293), however I can't agree with the counterpoint you are making. The prevalence of the behavior cannot constitute its justification. It seems not difficult to agree that an exact pointer to a syntax error location is much more useful than a general signal that there is an error somewhere in the module.
I realize my response may not be overly contributive, but not sure what else can be done.
Thanks @nicnilov! I agree the prevalence of the behavior cannot constitute its justification but it may be that the prevalence justifies a natural cause shared by all of them.
The issue is, when you don't have a closing end then by definition the outermost do is the one that is wrong. We can try to provide hints, but the hints are not precise because they rely on indentation. A program that is not indented and not closed, would then point to the wrong location.
Perhaps one thing we could do is to provide the hint as additional metadata, so you could point to the error and the hint, but if given broken code, there is only so much we can do to guess what it is right, and any guess we make will be wrong at some point. Pointing out to the outermost one is the technically correct one.
I agree the prevalence of the behavior cannot constitute its justification but it may be that the prevalence justifies a natural cause shared by all of them.
That's for sure, but we should be trying to find a way to improve nevertheless.
The issue is, when you don't have a closing end then by definition the outermost do is the one that is wrong. We can try to provide hints, but the hints are not precise because they rely on indentation. A program that is not indented and not closed, would then point to the wrong location.
Yes, during editing there can be no assumption the indentation is correct and the program is closed. But it is exactly during editing when I find this behavior most distracting. When I just look at an open file which is not compilable and is highlighted whole it may be less of an issue than when I'm typing a lot and have the whole of my editor blink on and off because a delimiter happens to be unclosed at a particular moment.
Maybe a solution is to switch off the dynamic syntax error highlighting and only perform it when the file has been saved - I looked for that option but couldn't find it either.
Alternatively, whole module not being closed could be considered a separate scenario, and instead of the squiggles all the way it could be reported in a different, more restrained fashion.
Perhaps one thing we could do is to provide the hint as additional metadata, so you could point to the error and the hint, but if given broken code, there is only so much we can do to guess what it is right, and any guess we make will be wrong at some point.
It seems useful to me to have the hint available as metadata, but I don't know whether ElixirLS authors will be willing to make use of it.
Pointing out to the outermost one is the technically correct one.
Technically it may be correct, but ergonomically - hardly. To clarify, for me the most inconvenience comes not from the imprecision of the error location as such, but from the irrelevance and distraction of the behavior in the particular case of the do..end blocks.
With that said the direction Elixir have been moving in since 1.15 with better diagnostic output is very welcome.
One thing that could be done is to not highlight everything if it goes until the end of the file until there is a save. But that's a visual decision for the LSP to make, not Elixir's. If there is any metadata we could add upstream, please let us know, but the exception is technically correct, and then there is a decision of what is best to do visually.
@josevalim Didn't mention you above, sorry. Hello, how can I contact you via email or Telegram?
I found this to be a great language with a lot of amazing features
I want to talk about a good offer.
One thing that could be done is to not highlight everything if it goes until the end of the file until there is a save. But that's a visual decision for the LSP to make, not Elixir's. If there is any metadata we could add upstream, please let us know, but the exception is technically correct, and then there is a decision of what is best to do visually.
I found this to be a great language with a lot of amazing features
I want to talk about a good offer.