[teddyh]

> 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.

[8456523]

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.)

[bitwize]

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.

[teddyh]

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.

[hollerith]

>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.)

[teddyh]

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/

[hollerith]

You've never used Emacs with Cocoa or looked at any source code integrating Emacs with Cocoa; have you?

[teddyh]

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.

[jlarocco]

The official Emacs release for OSX uses Cocoa.

For more info see the first answer here: https://emacs.stackexchange.com/questions/28840/os-x-emacs-d...

[tom_]

It does the same thing on Windows. This just appears to be how Emacs behaves.

[teddyh]

Huh. That does suggest that my initial assumption about Emacs adapting to its environment was incorrect.

I do know that Emacs did adapt a lot when coming to Unix/X11 from its initial roots on other systems, but maybe it has ossified since then.

[blackorzar]

Would you please share your code? I would like to have a similar setup for my emacs in windows.

[8456523]

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.

[blackorzar]

Just reminding you about this request :)