unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Paul W. Rankin" via "Emacs development discussions." <emacs-devel@gnu.org>
To: "Paul W. Rankin" <pwr@bydasein.com>
Cc: emacs-devel@gnu.org
Subject: Re: src/nsterm.m: fix window tabbing on macOS
Date: Tue, 11 May 2021 15:45:08 +1000	[thread overview]
Message-ID: <39fa782b82e274d3e9c40e934df89d68@purelymail.com> (raw)
In-Reply-To: <YJmPUEkImBChplXE@idiocy.org>

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	other threads:[~2021-05-11  5:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08  9:26 src/nsterm.m: fix window tabbing on macOS Paul W. Rankin via Emacs development discussions.
2021-05-08 11:21 ` Alan Third
2021-05-08 12:27   ` Paul W. Rankin via Emacs development discussions.
2021-05-08 12:35     ` Paul W. Rankin via Emacs development discussions.
2021-05-10 19:53     ` Alan Third
2021-05-11  5:45       ` Paul W. Rankin via Emacs development discussions. [this message]
2021-05-11 19:20         ` chad
2021-05-12  9:47           ` Paul W. Rankin via Emacs development discussions.
2021-05-12 21:23         ` Alan Third
2021-05-13  5:46           ` Paul W. Rankin via Emacs development discussions.
2021-05-13 21:05             ` Alan Third
2021-05-16  9:16               ` Paul W. Rankin via Emacs development discussions.
2021-05-26 19:56                 ` Alan Third
2021-05-27 11:06                   ` Andrii Kolomoiets
2021-05-28  8:26                     ` martin rudalics
2021-05-28  8:28                       ` Paul W. Rankin via Emacs development discussions.
2021-05-28  8:36                         ` martin rudalics
2021-05-28  8:54                           ` Alan Third
2021-06-06  4:09                             ` Paul W. Rankin via Emacs development discussions.
2021-06-06  7:43                               ` martin rudalics
2021-05-28  9:07                           ` Andrii Kolomoiets
2021-05-28  9:21                             ` martin rudalics
2021-05-28  9:37                               ` Paul W. Rankin via Emacs development discussions.
2021-05-28  9:51                                 ` martin rudalics
2021-05-28 14:33                                   ` Paul W. Rankin via Emacs development discussions.
2021-05-28 20:52                                     ` Andrii Kolomoiets
2021-06-05 20:58                   ` Alan Third
2021-06-06  4:01                     ` Paul W. Rankin via Emacs development discussions.
2021-06-06  6:14                       ` Eli Zaretskii
2021-06-06  6:48                         ` Paul W. Rankin via Emacs development discussions.
2021-06-06  9:13                           ` Alan Third
     [not found]                             ` <8CCF969D-32AF-4542-8838-21DF4AA45523@yasufuku.dev>
2021-06-06 11:36                               ` Alan Third
2021-06-06 12:19                                 ` Paul W. Rankin via Emacs development discussions.
2021-06-06 18:56                                   ` Alan Third
2021-06-07  0:27                                     ` Paul W. Rankin via Emacs development discussions.
2021-06-07 22:13                                       ` Alan Third
2021-06-08  7:32                                         ` Paul W. Rankin via Emacs development discussions.
2021-06-08  8:59                                           ` Eli Zaretskii
2021-06-09  8:35                                         ` martin rudalics
2021-06-09  8:48                                           ` Alan Third
2021-06-09 12:20                                             ` martin rudalics
2021-06-09 12:29                                               ` Alan Third
     [not found] <65f1-60bcfd80-157-23301c40@168015757>
2021-06-07  0:11 ` Paul W. Rankin via Emacs development discussions.
2021-06-07 21:57   ` Alan Third

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39fa782b82e274d3e9c40e934df89d68@purelymail.com \
    --to=emacs-devel@gnu.org \
    --cc=pwr@bydasein.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).