Thank you, deathaxe, for your scriptlet; without the find_next line (which doesn’t make sense since nobody would triggering search automatically exclude the first hit for that search), it brings me back to the editor indeed (and without having to press {escape} for that… whilst closing the search panel though, which seems unavoidable then?
(Standard for “better” editors, e.g. EmEditor, etc., is that the search field remains open but does NOT retain focus IF a hit was found, just “lesser” editors invariably close the search panel in that case; in the absence of a(ny) hit, they (hopefully) all preserve focus within the search panel, since then that’s the only behavior that makes sense.)
I understand that the ST search panel, while retaining focus by its own, really weird standard (i.e. without your scriptlet running), remains “functional” in that way that subsequent {enter} will work as standard F3 works in all other editors: they select the subsequent hit (if there is any), and that seems to make sense for finding / visually checking the hits 1-by-1, since subsequent {enter} are more easily “within reach” than the F3 key is, but obviously NOT for editing one or some of them, since then, the user needs the standard F3 instead, anyway…
But that design decision obviously is related to ST’s - quite dangerous, since a filter functionality (with vicinity view, i.e. display of the surrounding lines, cf. EmEditor) seems to be missing - bulk change functionality: “Find All”, and then any editing within the search panel will edit all hits, wanted and unwanted ones…
Btw, sometimes, “Find All” will sometimes really display all hits very prominently, orange background within the general dark grey background, so that the user can visually check without fault, but then again, the same command just draws a thin rectangle around the hits, and which can easily be overlooked for a hit that should NOT be changed… and sometimes, the “Find All” has to be triggered twice, instead of just once, in order for the display to work as expected, and then again, as soon as the user switches focus from the search pane to the editor, in order for {pgup/dn} to become accessible for scrolling - they are NOT accessible while the search panel retains focus! -, the prominent hit display reverts back to the very “discrete” one, or sometimes, “Find All” makes the search panel vanish, and then again not - all this quite inscrutable indeed…
In order to preserve the prominent hit display, you seem to stay within the search panel by all means, and then exclusively scroll with the mouse wheel - and any mouse click then within the editor will make you lose it again.
So, yes, if you do it all (sic!) exactly as the ST developers want you to do it, the ST design comes with some benefits, but I wouldn’t call that “user-friendly”, general standards being considered bugs, and all that… 
The font rendering on screen is spectacular though…
EDIT:
With your kind information, deathaxe, I was then able to do the right key assigment:
{ "keys": ["enter"], "command": "focus_group", "args": { "group": 0 },
"context":
[
{"key": "panel", "operand": "find"},
{"key": "panel_has_focus"}
]
},
(And your scriptlet is also very valuable as a “chain” example!)
Thank you again, very much indeed!
