Tune code editor warnings

[inhalt120g]

Describe the project you are working on

Right now I'm working on an arcade game, but this applies to any Godot project.

Describe the problem or limitation you are having in your project

The immediate marking of the whole line of code as an error before I even finished typing is unpleasant, especially when the whole script gets marked with red just because I haven't finished adjusting indentation. It makes me want to yell at Godot "Can you at least let me finish and hear what I'm saying before you mark my whole script as an error!".

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Assisted marking of incomplete lines of code, errors and similar is very useful. However, the current implementation is slightly too strong in cases when I just start typing something: as soon as I start typing the whole line is immediately marked as an error. It is very discouraging and attention grabbing at the same time.

This is especially bothersome when I'm typing in a new function, first it marks the whole line as an error when I start typing, then it's marked as an error again when I get to the next line (so I have to quickly throw in a "pass" just so it doesn't freak out), and so on. Same when adjusting indentation, the whole code gets marked as an error which always alarms me. It's constantly giving me the feeling of anxiety and makes it unpleasant to work.

Also in like 99% of cases where the whole line is marked as a mistake, it's a case of errors that, while preventing compiling and in that sense "very serious", are really easy to fix (like typos, wrong indentation… or just missing code that yes I am in the process of adding anyway).

I'd find it more practical if instead of the whole line, only the line number would get marked.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I'd find it much more convenient if the lines of this kind were marked only on the side, so instead of this:

it'd just mark it like this:

I assume whether the whole line or only the line number is marked should be added as a preference (because I assume there are many people that like to have the whole line marked). For people that do not use the column on the left, maybe the "mark the whole line" would get assigned automatically.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I assume the template for proposals was written with a very specific target audience in mind :) In any case, the answer is no it can't be worked around with a few lines of script because it's not that kind of problem.

Is there a reason why this should be core and not an add-on in the asset library?

From what I understand this can't be an add on.

[Mickeon]

The immediate marking of the whole line of code as an error before I even finished typing is unpleasant, especially when the whole script gets marked with red just because I haven't finished adjusting indentation. It makes me want to yell at Godot "Can you at least let me finish and hear what I'm saying before you mark my whole script as an error!".

This can be changed with an Editor Setting called text_editor/completion/idle_parse_delay.

It's not an exactly intuitive setting name (as many tend to be), but you can increase this value a bunch to suit your needs.

[inhalt120g]

Alright but that's just tweaking the delay, right? I don't have anything against it to be as fast as it is by default, I'm just saying that marking the whole line (as opposed to just the part where the line number is) is a bit scary.

[Calinou]

Maybe you want to use a more subtle color for error marks instead? You can do so by changing Mark Color in the editor settings (decrease the color's alpha channel).

I'd avoid adding more options unless strictly necessary, as we have a lot of editor settings already.

PS: I believe the current line color overrides the mark color if you make the current line color (mostly) opaque in the editor settings. This is worth trying as well, so that the error mark becomes (mostly) invisible if it's on the current line.

[inhalt120g]

I already defined the color I want to use. I know I can make various color adjustments (as you can probably tell from my screenshot :D ).

I agree, adding ever more options is something that should be avoided generally speaking.

Maybe I didn't explain the problem well. Let me retry.

First, what is not the problem: I don't have anything against having red (or whatever color) indicators telling me parts of the code are not functional as is. I also don't have anything against the markings being strong or articulate. I don't have anything against it being in real time. I don't have anything against it getting activated just because the code is not completed. This is all good and desirable.

The problem is that the actual text that I'm typing is marked with red, as opposed to side lines. When using interfaces of this kind, there is a psychological distinction (for the creator / customer / user) of "my parts" (for example, area where I as the author type, make edits and so on) and "system parts" (for example, automatic generation of line numbers). Ideally, "my parts" areas should always be about providing support and suggestions (code autocompletion, or adding vertical indentation markers etc) and avoid criticisms and negativity (especially when its about trivial stuff like "you haven't finished adding tabs").

And also… as a side note, when a huge area of code is marked as "wrong",… it is just discouraging.

Anyway I found a video of someone coding in Game Maker Studio 2, I am not sure whether GMS2's IDE is doing what I'm describing (I'm not really using GMS2) but it definitely looks similar visually (if there are any GMS2 users, please confirm because I have been unable to find any info about this particular behavior online): https://youtu.be/Z5qoDcw-xs8?si=C-guWM26O1R5JwK1&t=145 Edit: around this part:

So here, when the red marks appear, it looks much more sophisticated and professional, because indeed the IDE is marking some lines with red but it's very, erm, "polite" for lack of better word.

[Calinou]

I tend to find gutter-only marks easy to miss, especially on ultrawide displays when the window is maximized. This is why I'm not in favor of removing the line highlight entirely. If I recall correctly, Xcode displays errors that way and that frequently catches me off-guard. Not to mention it makes visually matching the mark with the line difficult for long lines.

We can make the line highlight more subtle (e.g. use a gradient that fades out towards the right of the line), but I wouldn't remove it. For some errors, it's also feasible to underline the problematic part of the line (though some errors will highlight from the first erroneous column to the end of the line).

[inhalt120g]

I agree, highlighting the whole line is more desirable in some cases (and yes, I can imagine ultra wide monitors are a good example). Reading back my own posts it does come across as if I'm implying it should be removed, but just to state it explicitly: it's all more about introducing an option that works better for different contexts and sensibilities than replacing anything.

When you say gradients, is something like this what you had in mind?

Even if the gradients would be a bit shorter or longer and maybe the colors tweaked a bit etc, it looks a bit undefined to me. Also this would require a bit of work to set up: everyone will want the gradient to be wider or narrower (which means more IDE options), and even after it's adjusted for personal preference it won't work well in situations when the code gets longer or shorter. And if there's automatic gradient stretching, decisions like should the gradient map to the extent of the length of current code, the extent of the code editor window, the extent of the longest line in the script and so on will have to be solved. So to me it sounds more like an interesting than an attractive option.

[Calinou]

When you say gradients, is something like this what you had in mind?

Yes :slightly_smiling_face:

And if there's automatic gradient stretching, decisions like should the gradient map to the extent of the length of current code, the extent of the code editor window, the extent of the longest line in the script and so on will have to be solved. So to me it sounds more like an interesting than an attractive option.

We can probably find an heuristic that works well for most use cases. This can be based on the length of the line itself (until its last visible character), the width of the editor pane, or something like that. We'll need to try several options and see which one works best in practice, as it's hard to guess in advance.

[inhalt120g]

Gradients are not something I'd personally use (to me it'd look a bit undefined so in that sense even the current highlighting style is preferred) but fair enough.

As for the "gentle style markings" as an option, I guess a good place to put it would be the gutter's own menu, maybe on the bottom like this:

[Calinou]

As for the "gentle style markings" as an option, I guess a good place to put it would be the gutter's own menu, maybe on the bottom like this:

That menu only contains actions, so making it contain preferences that are persisted across restarts would probably not make sense.

[Mickeon]

Not just that, it's not something that warrants being toggled so often it needs to be easily accessible like this

[inhalt120g]

Fair enough, does a checkbox under the "Gutter" part of the Editor preferences sound like a better place?