emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: src/nsterm.m: fix window tabbing on macOS


From: Paul W. Rankin
Subject: Re: src/nsterm.m: fix window tabbing on macOS
Date: Tue, 11 May 2021 15:45:08 +1000
User-agent: Purely Mail via Roundcube/1.4.10

On 2021-05-11 05:53, Alan Third wrote:
On Sat, May 08, 2021 at 10:27:13PM +1000, Paul W. Rankin wrote:
I reckon this is probably OK, but I'll leave it a bit longer to see if
anyone else has an opinion.

If I'm not mistaken, it is the fourth commandment of emacs-devel that someone must raise an objection. Especially if the change does not affect them.

IIRC, it would just crash pretty much at random, and without much
prompting, so you'd likely know if it was still a problem.

Most likely the fullscreen crash fixes from a couple of years ago
solved it.

I'm on macOS 10.13 Hi Sarah and previously was on 10.14 and 10.15, but if anyone is on macOS 11 Big Slurp it may be worth building/testing.

The user choice I refer to resides in the odd place of System Preferences > Dock > Prefer tabs when opening documents: [Always | In Full Screen Only |
Manually]. The behaviour I've experienced with each of these is:

- Always: invoking `make-new-frame' will always create a frame in a new tab - In Full Screen Only: invoking `make-new-frame' will create a frame in a
new tab only when `(frame-parameter nil 'fullscreen)' is non-nil
- Manually: `make-new-frame' will never create new tabs

I should clarify here that the macOS window manager is not querying Emacs frame parameters. Correlation not causation!

That location really doesn't much sense! Certainly explains why I've
never seen it before. :)

This is really my lastremaining concern, that it's such an obscure
setting that we'll get a lot of bug reports about Emacs-doing-tabs
when-I-don't-want-it-to. I'm not sure there's a good solution to that
other than perhaps putting a note in the NS port documentation (which
afaict nobody ever reads anyway).

You are correct. I only looked at the nextstep/README file today.

Given that tabs look much a part of the macOS window system I think/hope a person's first assumption would be that it's an Apple thing and hopefully first burn out their ire on Apple forums/reddits/etc. Nevertheless, we shouldn't inhibit all for the failings of a few.

The only thing that's a little weird is that this tab bar is not visible when in full screen, requiring moving the mouse up to reveal it. It would clearer what's happening if the tab bar behaved more like Terminal.app when in full screen: opening more than a single tab keeps the tab bar visible (in full screen or windowed).

Apple's documentation on this is very thin, so I doubt it's a simple boolean switch: https://developer.apple.com/documentation/appkit/nswindowtabgroup

BTW, is there an advantage to explicitly enabling the default setting
over just removing the code that disables it?

Sorry I am unqualified to offer an opinion here, other than if someone wants to change it the code is already there for them to easily make the change and rebuild Emacs.

Tangentially, this lead me to read a little about GNUstep. Does GNUstep provide the same kind of tabbing as macOS?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]