Added contrib extension to have focus follow mouse (fixes #25685).

[71]

This adds the editor.focusOnHover option which is false by default, and can be set to true to automatically focus editors when they are hovered.

Note: It's my first time submitting a PR, as such, I'm not sure whether all changes made to the build/ directory should have been committed as well. Since I had some doubts, I did not commit them.

[msftclas]

All CLA requirements met.

[71]

Alright, I also implemented this for terminals, however it uses some internals APIs that aren't allowed in contribution extensions, so I did not add the support to this terminal. See this commit for more informations.

[Tyriar]

Do you have a reference to the feature request issue? Features like this need to be discussed before being implemented, I'm not so sure we would want to accept such a feature personally. /cc @bpasero @alexandrudima

For the terminal code specifically there are some layer breakages, src/vs/editor/contrib is part of monaco and cannot reach outside into the vscode workbench where the terminal part is defined. For the terminal this would probably live mostly inside parts/terminal. You can read more about this here, but I recommend holding off on further changes until a discussion happens.

[bpasero]

Wouldn't it make more sense to have a setting that focusses whatever element is under the mouse in the workbench so that more UI pieces are covered, like views, panels and editors?

[71]

@Tyriar The feature request is in #25685.

Apologies for not going through the whole feature process beforehand; the docs mentioned how to contribute to the editor, but not how features should be discussed.

I do understand why adding the terminal support would be harder (unless we go from a contribution extension to a fully-fledged editor feature, which would probably be much harder to implement) but I find it disappointing to completely disregard the feature itself, especially since we were told it had been added to the roadmap in the issue I linked above. Edit: Never mind, I read that wrong.

@bpasero I also think that would be the best course of action, but didn't want to mess with the core editor. I can try looking into this though.

[bpasero]

I think that one would be: #44214

[Tyriar]

@6a

I do understand why adding the terminal support would be harder (unless we go from a contribution extension to a fully-fledged editor feature, which would probably be much harder to implement)

Well not necessarily harder, it just needs to live in the terminal folder as the "editor" isn't allowed to know anything about the terminal.

but I find it disappointing to completely disregard the feature itself

Looks like the issue is #44214, the main concern about features like this is that it's a bunch of code that the team then needs to maintain but the feature itself may only be used by a handful of people.

[71]

@Tyriar

Well not necessarily harder, it just needs to live in the terminal folder as the "editor" isn't allowed to know anything about the terminal.

Yep, I created a version that listens to the mouseenter event in TerminalInstance, but that means more code to maintain unfortunately.

Looks like the issue is #44214, the main concern about features like this is that it's a bunch of code that the team then needs to maintain but the feature itself may only be used by a handful of people.

I absolutely understand. I think it would be useful for many people, but I have no proof of this. In the end that's your call. I initially went with a contrib extension to avoid having to maintain code in many different files, but it wasn't enough. The whole feature only requires an option to be added and a few event listeners in Part, TerminalInstance and CodeEditor (iirc), but I definitely understand how that may become harder to maintain in the future and why you would refuse to implement it.

[ilude]

Any news on this? What is needed to get this merged and how can I help?

[71]

@ilude I have a fully working implementation on my end, but it modifies many core components, which is something that (understandably) bothers the VS Code team. Not a lot of work is needed now, but it still adds a good chunk of code we'll need to maintain in the future.

You could try to find a way that's easy to implement and lives on its own without having to be maintained in core components, but I'm not sure that's actually possible (at least I didn't manage to get it working).

[tobia]

I'm the OP of #25685. I've personally been using Focus Follows Mouse aka. Sloppy Focus for ages, since the XMouse utility came out with the Windows 98 TweakUI / PowerToys (wow, that was 20 years ago!) There are no stats on how many people use such a feature, which is certainly more popular in Linux circles than Windows. Most Linux window managers offer it as a feature, because that's how the original UNIX X-Windows behaved. Windows 10 still has it, by the way. It can be enabled through the same registry setting as in Windows 98, or with the same XMouse utility.

I could explain why it makes more sense (to me), is faster and more productive to just move my mouse into a window and start typing, instead of having to click, and with that click move the text cursor. But I'm not sure it would be of any help to the present discussion.

What I can do is point at the millions of pages about this feature on the web, mainly consisting of users asking how to enable it for various OSes.

[alexdima]

I tried to bring this back to life. I even merged it in master because it appeared to work fine, but I just realized that this cannot work in the current form, so I had to revert.

Our entire UI will be broken by this change, e.g. it is impossible to change the language mode with the mouse because the focus always moves which dismisses the quick open:

I believe a lot more work is needed to get this working as intended and unfortunately I cannot justify that we do this work.

[71]

Alright, I understand. Plus the code was quite old. If you ever change your mind please ping me, I'll do my best to get things up to date!