Updated the main comment to reflect the new behavior.

Updated again, very slick, not completely trivial.

I don't know, but I don't see what this supposed to be doing, so I'm doing something wrong and I don't know what.

So, I've changed my key binding for sublime_linter_panel_toggle to include "args": {"focus": true}:

{ "keys": ["ctrl+super+a"], "command": "sublime_linter_panel_toggle", "args": {"focus": true} },

So, when I open the panel using that the panel should get focus? I do seem to see that focus shift sometimes but it looks completely random and it doesn't stick. As I understand it I should be able to use the arrow keys to then move between errors in the panel? That doesn't work at all for me, the arrows just move the cursor in the main window.

I also don't really 100% understand the goal here. Even without this PR, I can open the output panel and use prev_result/next_result (I bind them to ALT+arrows up/down) to move through all my errors. I can even close the output panel if it's in the way and continue using prev/next just as I would with e.g. a build system output or search output. I know we've been through all this before and there is a bug with prev_result/next_result in combination with jump back/forward. But it is the standard way to move through all sorts of output in Sublime Text and we already perfectly support that. I don't necessarily rejoice in adding this non-trivial feature that seems to replicate what I already have, but then again, I haven't actually used it yet because it doesn't work... and I will reserve judgement until I do 😉

But, maybe I just need to see this working to get it. So, what am I doing wrong and how do I get this:

Enable standard "show_panel" with "focus: True" to open the panel and focus it.

I'm at e0fee64 and I pass the args to the command as mentioned above. Why doesn't it focus?

The focus stuff is just in here.

Basically, the first focus line on L292. Before we always moved focus back to the view here which is now in a conditional. The arrow keys don't work if you don't get the focus to the panel. (Actually, it is completely unimportant how a user gets the focus to the panel, and I wasn't sure if there is a more standard way. So this was actually the least I'm-confident part of the PR 😁.) Anyhow, this is one line and works 100% reliable on my ST3. Maybe add some print statements here. Probably ST4 bug? Does it unfocus the panel even if you click in it with the mouse? (Randomly, or when new results fly in?) Or does it unfocus when moving up and down? For movements, I really just use window.open_file which is used in the "Goto symbol" code. It doesn't steal the focus here. 🤷

I'm using this all the time now, almost 100%.

Ok, sounds easy enough, I’ll go bug hunting .

It does window.focus_view(panel), and for a second the focus does seem to have shifted to the panel. When I hit ⬆️ though, it takes forever to respond and focus seems to go back to the main view. For some reason the binding you introduce for the up arrow wreaks havoc on my machine, it's back to normal if I go back to the dev branch.

So generally window.open_file now steals the focus. I added a commit to bring the focus back to the panel.

More generally, ST4 is laggy. It is slower for this operation, not instant. I can replicate this for the "Goto Symbol" quick panel as well. The "Goto Symbol" is kinda fast in safe mode but also not instant. With plugins enabled there is noticeable lag. (T.i. up/down is not instant anymore; easily to reproduce if you hold down the up/down key it does not update whereby ST3 scrolls through the items.) It looks like they delegate to the worker or yield back the UI thread at least so that plugins get a chance to work here in between. In ST3 open_file isfeels more blocking, and since the task/work Sublime has to do here is rather small (or ST3 is rather fast) it is usually instant.

The focus management is a bit special in ST3 because output panels behave special here. For example if a panel has focus, you cannot just focus_view a normal view, you have to "force" focus, first focusing the group then focusing the view. (As an explanation, because for open_file of course changing the focus seems natural, but stealing from an output panel is something different.)

Let's call it what it is. You use alpha software here.

1. window.open_file activates the view iff the file is the same as the already active_view (t.i. a "real"/"normal" view) but not on the first call, it starts with the second call. "transient" views only see "selection change" events.

2. However, there is no preview anymore, every move participates in the history. So "jump back" is broken. This can be reproduced using the normal "Goto Reference" or "Goto Symbol" as well. Just walk around the items in the quick panel, hit "ESC" or "enter", doesn't matter as all visited locations are in the history. (So basically the distinction this PR uses between "commit" and "discard" or generally "previewing" files is fundamentally broken.)

3. Generally, "Goto Reference" and "Goto File" are laggy, easy to reproduce if you hold down the arrow up or down keys. Using "Goto File" ST3 was capable of blasting through all possible files. ST4 blocks updating the UI ("freezes" and stutters).

...

Erm, "Goto Reference side-by-side", splits the view, and then navigating the quick panel both panes move and show the same content. 💩 And how do I unsplit, or move the cursor between panes?

Well it’s still in “closed beta”, so sure, probably the issue is there. Maybe you can file the bug reports upstream? I can throw them in the chat somewhere and they’re usually pretty good at following those things up, but I probably can’t give any explanation or details if they need them.

I’ll have to test again using ST3 then. Darn.

Okay, the innocuous looking panel.find_all_results() I use here (because it was there and did what I needed) has a performance excess even for rather few items in the panel (or in the Find in Files Results buffer; t.i. it's not our regex, it's rather the implementation on the Sublime side). For example having 350 errors in the panel already yields to 600ms execution time for that API call. (Calling this on a find buffer with 1000 matches, freezes Sublime for several seconds.)

Ok, so now what? It won't work until they improve stuff upstream?

Well, no, I just used find_all_results because it was there. We just use our error store. I mean sure we know which error we just draw in the panel.

Oh, now it works. And I get it now. Some bugs/quirks though:

If I click into the panel it doesn't work the first time I hit an arrow key. After a few hits it starts moving correctly though.

What feels kinda weird is that it doesn't start at the line I clicked, when I click into the panel.

It breaks the prev/next navigation in the output panel, in the sense that I can only ever go "up"/"prev" to results in other files, not down. Does it rewrite the output panel when you switch files in a way that the current file is always at the bottom?

Well, the combination of mouse interaction and keyboard navigation is not well defined. I basically focused on the keyboard driven workflow because it is the initial workflow this PR wants to make better. ("preview"/"commit"/"discard")

There are design questions here.

What would be a typical way to actually bring the focus to a panel? For now I went with two shortcuts and by listening for "show_panel" with focus: True. I surprisingly haven't found (in the forum etc.) a common way to do this. (I'm looking for a common keybindign to bring the focus to the Terminus bash panel, the ST console, the SL error panel etc...)

How do we visually show that the panel has focus? Here again I searched the forum because I would have thought there must be some (newer) theme thing I never implemented in my own hacky theme. For example, making the background a bit lighter on focus, or draw the thin border in a color. But there is none.

The SL panel is a bit strange here because it actively destroys any cursor. One of the rare instances of that you actually can't just use view.sel()[0] because for the panel there might be no cursor. Instead we draw a dangle. But maybe we should draw a normal cursor iff the panel has focus. Just for the visual feedback.

Regarding the mouse, if you click, do we expect to scroll to that error you clicked on? If so, transiently or committing to that new position? In this first implementation I just take the click as focus event, I never actually read the click position; so we actually jump always relative to the main active editor window.

And yes, "next_result" is bound to the active view; we don't wrap and jump around since v4.14 (iirc). That's halfway a bug and a feature; I always found the jumping-around to be really confusing. (And prior that the next file was just the next file in an alphabet sort. Now you usually stop at the end of the current file except the file has dependencies. Then you can actually jump to them using "next".)

Especially here, I really spent an extra mile in this PR to not jump to different files (not even wrap). So I even forbid going "prev" on top of a file.

What would be a typical way to actually bring the focus to a panel?

I believe the design of ST intends output panels to never get focus. You can switch to the tree via CTRL+0 and to editor panes via CTRL+1 (CTRL+2 etc if you have a split view). But there is no shortcut to go to the output panel. You can usually click into the panel to copy-paste something or to double-click a line, but that's it. Browsing goes via prev/next-result, which keeps the focus in the editor. Which is nice, because you can start editing immediately without switching focus back to the editor.

So your solution with the command param is good. Clicking into a panel of course also moves focus, so that should also work.

How do we visually show that the panel has focus?

ST is actually not good here. I tend to look for a cursor or the outlines around a selection. I don't even think you can do anything in the color scheme to indicate focus. Unless they added something in ST4, but I can't remember and don't think so.

So I even forbid going "prev" on top of a file.

Huh. I did truly "go prev" on top a file just now:

Huh. I did truly "go prev" on top a file just now:

The native "prev_result" goes to the previous file, but the "prev_commit" (arrow ⬆️) I implemented here doesn't. (Iirc it snapshots the file/view when you first press up or down, for example to restore that view on "discard", and then you can also never go above that file. But you can go into a file below.)

On the panels, I think I barely used panels 3 years ago, but today with Terminus, GitSavvy, SL... these are super popular and ST is a bit behind here supporting that dev move.

If I click into the panel it doesn't work the first time I hit an arrow key. After a few hits it starts moving correctly though.

Can't repro this one. Don't know what it even means. It doesn't move at all? It moves to a weird error?

but the "prev_commit" (arrow ⬆️) I implemented here doesn't.

exactly, which is good. 👍

It doesn't move at all? It moves to a weird error?

I had a better look today. It moves, but not the error near where I clicked in the panel, but the error near my cursor in de main editor. Which I guess makes a lot of sense. But because my eyes are now on the cursor in the output panel, it's weird that it sometimes jumps down several lines to the next error.