I admit that I have spent a lot of time adjusting Emacs to my preferences (by writing Emacs Lisp code that gets loaded automatically every time my Emacs starts). I am not particularly unhappy about that fact however and will probably spend a lot of time writing code that runs inside vscode if it becomes my daily driver.
Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.
Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.
I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.
Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.
> f there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI
Emacs does that in X11 because that is (or at least was) the standard behavior for text selection in X11. Emacs is simply conforming to the environment it is running within.
Emacs's Mac (graphical) interface does that, too, which is not conforming to the environment it is running in.
And there is no user option for changing it to a contextual menu containing Cut, Copy, Paste, etc. (I changed it for myself by writing about 100 lines of Emacs Lisp.)
Emacs was taught to run graphically with X11 first, and presumably operates that way across platforms for a consistent interface irrespective of platform.
Even iTerm supports middle-click paste. Unix people are used to it.
I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa, and Emacs is simply using macOS’ X11 compatibility system.
If you could fix that behavior so that Emacs behaves more like a native Cocoa application, I see no reason that the Emacs maintainers should reject a patch. Emacs has, as far as I can tell, always strived to use as much of a native system’s interface and conventions as possible. Emacs is very big, so it might seem to be a self-contained world of its own, but it’s trying not to be too idiosyncratic.
>I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa
You would guess wrong.
(If you install an X server, you can run Emacs on X11 on a Mac, but if you do, the text looks radically different from the text in other Mac apps. ADDED. whereas if you run Emacs directly on Cocoa, the way most Emacs users on Mac do it excepting the ones running Emacs inside a terminal environment, the text looks exactly the same as the text in, e.g., Textmate or Terminal.app.)
Hmm. I would then assume that Emacs has rudimentary rendering support in Cocoa, but is otherwise treating it as a variant of X11, and not the fully different graphical system it presumably is. Emacs still has no full-fledged Cocoa integration. That is still only available in the Aquamacs fork, as far as I know: http://aquamacs.org/
This is true. I hope I did not give a contrary impression? I was, somewhat briefly, aware of some of the complexities of Emacs running under NeXTSTEP (not the text-only Emacs 18 included with NeXTSTEP, but proper Emacs 19 with NeXTSTEP windowing support), but that was (obviously) many years ago, and I don’t claim to remember any of it. And I was certainly not involved in implementing any of it.
It's on a different computer than the one I am using now, so it is going to take me at least a few hours to share it. I will make another reply to your comment when I have it.
Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.
Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.
I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.
Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.