You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider the same Zed program as in the #2574 repro. If I had reason to do some kind of edit in the middle of such a wide line, the syntax error such as shown in the following screenshot is not super helpful on its own. We have have handy row numbers in the editor, but there's no way way for a user to quickly land at column 2517 and see their mistake.
One way I've seen other tools help in this situation is to move the user's cursor to the location in the program indicated by that row/column in the syntax error. In #2972@jameskerr also mentioned a possible approach being to "add squiggly lines under an error in the editor", though in this case where the error is effectively out of view in the editor that might not suffice.
Now, I'm aware that we quietly append some additional Zed on the end of a user's program to help with pagination, and I know we may do even more such changes when we address issues like #2533 and #2567, so this may be easier said than done.
The text was updated successfully, but these errors were encountered:
The changes in linked PR #3087 provide the "squiggly lines under an error in the editor" envisioned above by @jameskerr. If The red squiggly lines appear below whatever caused the syntax error. If I hover my mouse over that area the details are shown as a tooltip. These tips appear as I'm typing as a user before I've even tried to execute the program.
Another example is this query from the Zed join tutorial that I've pasted into the editor. It correctly notifies me that the pools I've referenced don't exist.
Here's a few areas where we may continue to improve:
When the user does submit a query to be run and it contains an error, the column numbers shown are incorrect, such as in the example below where the ; is the 13th character from the left in line 1 of the editor but it's listed as 33. Thankfully the caret points at the precise location of the problem so we assume that for now that's more likely to draw the user's attention rather than them counting off characters one by one. 😄
Regarding the text-based summary of errors that appears where the query output normally would be, @mattnibs made this suggestion:
I suppose you could also the list errors in the results area and maybe have a link that jumps the text edit cursor to the affected area and activates the error hover box?
Incidentally, this would be particularly helpful in addressing the problem originally cited in this issue where the syntax error is way "off to the right" in the editor and it would be difficult for a user to find it manually via horizontal scroll.
@jameskerr said he'd like to provide some visual cue when syntax errors happen inside of pinned query fragments.
Repro is with Brim commit ab5b75d.
Consider the same Zed program as in the #2574 repro. If I had reason to do some kind of edit in the middle of such a wide line, the syntax error such as shown in the following screenshot is not super helpful on its own. We have have handy row numbers in the editor, but there's no way way for a user to quickly land at column 2517 and see their mistake.
One way I've seen other tools help in this situation is to move the user's cursor to the location in the program indicated by that row/column in the syntax error. In #2972 @jameskerr also mentioned a possible approach being to "add squiggly lines under an error in the editor", though in this case where the error is effectively out of view in the editor that might not suffice.
Now, I'm aware that we quietly append some additional Zed on the end of a user's program to help with pagination, and I know we may do even more such changes when we address issues like #2533 and #2567, so this may be easier said than done.
The text was updated successfully, but these errors were encountered: