-
-
Notifications
You must be signed in to change notification settings - Fork 272
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
Goto/highlight target error when moving around in the panel #1717
Comments
Well, that is maybe tricky because you need to think about click-dragging to select text etc. Also, IIRC "we" don't support double-clicking, we just format the output in a way that makes Sublime Text support it like that. I'm hesitant to introduce behavior in our output panel that makes it different from other output panels that look similar. It intentionally mimics the output of the "find results" panel and the "build output" panels. So I'm not against researching possible improvements here, but we should fit into the eco system, or move the eco system forward. |
Well, our panel is probably best-in-class. With the new "focus on one file" feature it maybe feels natural to just go through them via cursor. Of course popping up errors from other files would be surprising. Maybe on With the current panel it feels a bit too mousy, and that's just because the panel behaves so great in that it always shows the right information, auto-wrapped and auto-scrolled. I think I wish I could just use the keyboard more. And then introducing Either |
Let's brainstorm a bit: This basically combines quick-panel features with the "output.panel". Let's say the user opens the panel by (This is pretty much, or should be as close as possible, how If the panel is already open Typical use-case A: You edit a file, then some import at the top of the file gets unused. You somehow get the focus to the panel as described. Use the cursor to move to the said error. Hit Typical use-case B: You see that you have some errors in the file. You open and focus the panel to review some error, then hit |
You can already keyboard navigate through stuff in the output panel (any output panel) without focusing the panel itself, via next/previous result. This works in conjunction with “go back” just like anything else. I guess I don’t understand your use cases because I think they’re already fully covered (because it’s a standard output panel)? Maybe we could do a new command “open panel and scroll to nearest error in file” (to quickly check something relevant about what you’re writing). Or “open panel at first error in file” to start reviewing a file? |
Hm, next/previous result just doesn't work really reliable (on SL3?) and the interaction with "go back" is incomprehensible. Sometimes it skips results or jumps to the next file. In comparison the UI using the "goto symbol" (or any other quick panel) is 100%. In that: you basically open the panel, then up down to preview, enter to commit going to that location, ESC to discard. Our own goto next/previous error command is reliable but it always commits the location to the history. Nothing we can change though (I think) because it is only one keystroke we either always commit to the history or never. (The preview feature is missing, I guess.) |
Ok, I don't have that problem, but let's say it's there (maybe we should pin-point it and open an issue upstream).
I think it bundles all the steps into one "edit" or something. It is weird though. I agree that as soon as you have focus in the panel it's nice if you could do something there. It seems only natural that "Enter" would bring you to where your cursor points at. |
I think I quickly(?) hack a quick-panel to see if that UX (previewing locations, commit or discard jumping, all just using the keyboard) makes a difference, esp. I would like "go back" to work better, and of course not going to the mouse at all. |
Fixes #1717 Enable standard "show_panel" with "focus: True" to open the panel and focus it. Our toggle panel takes this arg as well and passes it through. Generally, you *somehow* focus the panel, then `<up>`/`<down>` will move to next or previous error transiently, t.i. without storing this move in Sublime's navigation history. `<enter>` will commit this new location to said history, while `<escape>` will discard the previewing and return to the original location. (Overall this mimics for example the Goto Symbol quick panel.) Note that `<escape>` is not specially bound here, we instead introspect or observe the standard "hide_command" with "cancel: true" command and act upon it. On top of this, we may close the panel only if you opened the panel with "focus: true". (T.i. you did not move the focus to an already open panel.) Further notes: If the panel has focus: - Change the "SNAP" value to (basically) 0 to the effect that the line gets highlighted only if the cursor is exactly on an error. (T.i. turn off the "snap to nearest value" feature.) - Change the color of our virtual cursor to get *some* visual feedback. (For the panel, we choosed total control over the cursor, so basically the user never sees a caret. We use a _selection_ (not a region!) to highlight error lines; and completely remove any selection otherwise.) Note that we will have a normal caret now if the panel has the focus. That's normal behavior.
Fixes #1717 Enable standard "show_panel" with "focus: True" to open the panel and focus it. Our toggle panel takes this arg as well and passes it through. Generally, you *somehow* focus the panel, then `<up>`/`<down>` will move to next or previous error transiently, t.i. without storing this move in Sublime's navigation history. `<enter>` will commit this new location to said history, while `<escape>` will discard the previewing and return to the original location. (Overall this mimics for example the Goto Symbol quick panel.) Note that `<escape>` is not specially bound here, we instead introspect or observe the standard "hide_command" with "cancel: true" command and act upon it. On top of this, we may close the panel only if you opened the panel with "focus: true". (T.i. you did not move the focus to an already open panel.) Further notes: If the panel has focus: - Change the "SNAP" value to (basically) 0 to the effect that the line gets highlighted only if the cursor is exactly on an error. (T.i. turn off the "snap to nearest value" feature.) - Change the color of our virtual cursor to get *some* visual feedback. (For the panel, we choosed total control over the cursor, so basically the user never sees a caret. We use a _selection_ (not a region!) to highlight error lines; and completely remove any selection otherwise.) Note that we will have a normal caret now if the panel has the focus. That's normal behavior.
Fixes #1717 Enable standard "show_panel" with "focus: True" to open the panel and focus it. Our toggle panel takes this arg as well and passes it through. Generally, you *somehow* focus the panel, then `<up>`/`<down>` will move to next or previous error transiently, t.i. without storing this move in Sublime's navigation history. `<enter>` will commit this new location to said history, while `<escape>` will discard the previewing and return to the original location. (Overall this mimics for example the Goto Symbol quick panel.) Note that `<escape>` is not specially bound here, we instead introspect or observe the standard "hide_command" with "cancel: true" command and act upon it. On top of this, we may close the panel only if you opened the panel with "focus: true". (T.i. you did not move the focus to an already open panel.) Further notes: If the panel has focus: - Change the "SNAP" value to (basically) 0 to the effect that the line gets highlighted only if the cursor is exactly on an error. (T.i. turn off the "snap to nearest value" feature.) - Change the color of our virtual cursor to get *some* visual feedback. (For the panel, we choosed total control over the cursor, so basically the user never sees a caret. We use a _selection_ (not a region!) to highlight error lines; and completely remove any selection otherwise.) Note that we will have a normal caret now if the panel has the focus. That's normal behavior.
Fixes #1717 Enable standard "show_panel" with "focus: True" to open the panel and focus it. Our toggle panel takes this arg as well and passes it through. Generally, you *somehow* focus the panel, then `<up>`/`<down>` will move to next or previous error transiently, t.i. without storing this move in Sublime's navigation history. `<enter>` will commit this new location to said history, while `<escape>` will discard the previewing and return to the original location. (Overall this mimics for example the Goto Symbol quick panel.) Note that `<escape>` is not specially bound here, we instead introspect or observe the standard "hide_command" with "cancel: true" command and act upon it. On top of this, we may close the panel only if you opened the panel with "focus: true". (T.i. you did not move the focus to an already open panel.) Further notes: If the panel has focus: - Change the "SNAP" value to (basically) 0 to the effect that the line gets highlighted only if the cursor is exactly on an error. (T.i. turn off the "snap to nearest value" feature.) - Change the color of our virtual cursor to get *some* visual feedback. (For the panel, we choosed total control over the cursor, so basically the user never sees a caret. We use a _selection_ (not a region!) to highlight error lines; and completely remove any selection otherwise.) Note that we will have a normal caret now if the panel has the focus. That's normal behavior.
We currently support double-clicking in the panel as a goto-command. Maybe we could reduce that to simple clicks, and then generally just follow the cursor in the panel.
Basically reducing the need for mouse interactions. We could then explore how the panel could get keyboard focus just by using the keyboard. (
ctrl+ka
only opens the panel without focusing it.)Technically that means we implement
on_selection_modifed
for the panel view. Since the target view also implementson_selection_modified
to scroll and select the correct error in the panel we need to take care of this circular triggering which will be the tricky part here.The text was updated successfully, but these errors were encountered: