> Window selection is a natural extension of basic mouse usage. Resizing windows is a snap.
I don't think I can remember the last time I needed to resize a window in Emacs. I think. Also selecting window with a mouse simply would never work for me, because I need to select them by title in most cases. This claim OP makes is just absurd. If OP was honest, then they'd wrote "in some very special and simple cases, which don't happen in practice" using mouse for selecting and resizing windows may be faster." Which doesn't have the same ring to it, obviously.
> and drag and drop support
I don't feel like I'm missing something if I don't have this feature. Whenever I'm faced with this feature in other programs, I'm very much annoyed I cannot accomplish the action associated with this interface in a different way (unless performing the action precisely is somehow rewarded, as in maybe it's a part of the game where you have to prove you can do things very precisely)
> are very intuitive
I don't care. The point of using professional tools is that you learn and practice how to use them. Intuitive is for buy-in, it's not for being good at.
> The stopwatch consistently proves mousing is faster than keyboarding.
Did this measurement incorporate precision? I seriously doubt that. Most importantly, mouse is only a solution for things that are or can be made visible on the screen, and it also requires paying attention to what's going on on the screen. You cannot use your mouse while at the same time looking away from the screen (which I often do), or by trying to access functionality that isn't already on the screen (which is very often what I need to do, like, accessing a particular buffer, or calling a particular command).
In fact, mouse is so rarely a solution for anything I need to do during editing that even if it was faster for a very few things it can do, I still wouldn't care because I'd value uniformity of interface over negligible speedups in very few cases.
> When working on something that involves Emacs and one of these mouse driven applications, having to move over to the keyboard for the Emacs bit is exactly the friction we’d like to avoid.
This is some cooked-up case. No. This isn't needed. No, I don't feel like I need to botcher the way I use Emacs because I also like to play video games or do some digital drawing every now and then. There's absolutely no need for that. All the cases OP describes already work well without needing a mouse, or are just worthless. For example, when you want to clone a Git repository, you need to either set the current directory appropriately, or specify the directory you want to clone it to. In either case you'd be dealing with Emacs navigation in your preferred way, which would be the bulk of work necessary to accomplish the action. Then pasting something like a link to a Git repository is just one keypress (eg. Shift+Ins) and you are done.
Basically, someone got excited about Strokes library, even though it doesn't do anything useful. Maybe it was fun to write, or fun to theorize about how it could be useful in some counterfactual world... but, in reality, I'd never use that and wouldn't feel like I'm missing it, even after I've learned that such a thing exists and what it does.
I don't think I can remember the last time I needed to resize a window in Emacs. I think. Also selecting window with a mouse simply would never work for me, because I need to select them by title in most cases. This claim OP makes is just absurd. If OP was honest, then they'd wrote "in some very special and simple cases, which don't happen in practice" using mouse for selecting and resizing windows may be faster." Which doesn't have the same ring to it, obviously.
> and drag and drop support
I don't feel like I'm missing something if I don't have this feature. Whenever I'm faced with this feature in other programs, I'm very much annoyed I cannot accomplish the action associated with this interface in a different way (unless performing the action precisely is somehow rewarded, as in maybe it's a part of the game where you have to prove you can do things very precisely)
> are very intuitive
I don't care. The point of using professional tools is that you learn and practice how to use them. Intuitive is for buy-in, it's not for being good at.
> The stopwatch consistently proves mousing is faster than keyboarding.
Did this measurement incorporate precision? I seriously doubt that. Most importantly, mouse is only a solution for things that are or can be made visible on the screen, and it also requires paying attention to what's going on on the screen. You cannot use your mouse while at the same time looking away from the screen (which I often do), or by trying to access functionality that isn't already on the screen (which is very often what I need to do, like, accessing a particular buffer, or calling a particular command).
In fact, mouse is so rarely a solution for anything I need to do during editing that even if it was faster for a very few things it can do, I still wouldn't care because I'd value uniformity of interface over negligible speedups in very few cases.