GNU bug report logs - #58917
28.2; Arm Build on Mac OS Monterey: Buffer Name is on the same line as Tool Bar Icons

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58917 in the body.
You can then email your comments to 58917 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Oliver Yang <oliver_hom <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2; Arm Build on Mac OS Monterey:  Buffer Name is on the same  line
 as Tool Bar Icons
Date: Sun, 30 Oct 2022 16:44:03 -0700

Same problem described in the thread
https://emacs.stackexchange.com/questions/64602/buffer-name-on-separate-row-from-toolbar-icons

The Arm Build of emacs on Mac OS 12.6 will have buffer name on the same
line as the toolbar icons.  This is not case with X86 version of 28.2 on
Mac OS 12.6.


In GNU Emacs 28.2 (build 1, aarch64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559))
of 2022-09-12 built on armbob.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  xterm-mouse-mode: t
  global-auto-revert-mode: t
  which-key-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: t
  treemacs-fringe-indicator-mode: t
  yas-global-mode: t
  projectile-mode: t
  clean-aindent-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  shell-dirtrack-mode: t
  helm-autoresize-mode: t
  helm--remap-mouse-mode: t
  async-bytecomp-package-mode: t
  minions-mode: t
  smartparens-global-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
~/.emacs.d/personal/misc hides /Applications/Emacs.app/Contents/Resources/lisp/misc
/Users/yangho/.emacs.d/elpa/transient-20220527.2213/transient hides /Applications/Emacs.app/Contents/Resources/lisp/transient

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epa derived
gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader sendmail mail-utils winner tramp-archive tramp-gvfs
dbus helm-command helm-elisp helm-eval edebug backtrace helm-info
highlight-symbol flymake-proc flymake warnings auto-complete popup
customized_builtin_functions color-mode ibuf-macs xt-mouse autorevert
misc exec-path-from-shell lsp-python-ms which-key dap-cpptools dap-utils
dom xml dap-mode dap-launch posframe dap-overlays helm-xref avy company
flycheck find-func hydra lsp-treemacs lsp-mode lsp-protocol tree-widget
wid-edit spinner network-stream puny nsm rmc markdown-mode rx noutline
outline lv ewoc epg rfc6068 epg-config lsp-treemacs-themes f f-shortdoc
shortdoc treemacs treemacs-header-line treemacs-compatibility
treemacs-mode treemacs-interface treemacs-extensions
treemacs-mouse-interface treemacs-tags imenu xref project
treemacs-persistence treemacs-filewatch-mode treemacs-follow-mode
treemacs-rendering treemacs-annotations treemacs-async
treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-scope pulse color treemacs-faces
treemacs-icons treemacs-themes treemacs-core-utils pfuture inline
hl-line ht treemacs-logging treemacs-customization treemacs-macros pcase
s display-fill-column-indicator yasnippet helm-projectile projectile
lisp-mnt mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr grep compile text-property-search clean-aindent-mode
helm-mode helm-misc helm-files image-dired image-mode dired
dired-loaddefs exif filenotify tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell pcomplete comint ring
parse-time iso8601 time-date ls-lisp helm-buffers helm-occur helm-tags
helm-locate helm-grep helm-regexp format-spec ansi-color helm-utils
helm-help helm-types helm helm-core async-bytecomp helm-global-bindings
helm-easymenu helm-source helm-multi-match helm-lib async minions compat
ibuffer-vc ibuf-ext ibuffer ibuffer-loaddefs ediff ediff-merg ediff-mult
ediff-wind ediff-diff ediff-help ediff-init ediff-util edmacro kmacro
smartparens thingatpt dash vlf-setup vlf advice vlf-base vlf-tune
cl-extra help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core finder-inf info package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 470427 102715)
(symbols 48 39006 25)
(strings 32 157849 13581)
(string-bytes 1 4739829)
(vectors 16 69396)
(vector-slots 8 772166 154569)
(floats 8 346 294)
(intervals 56 1380 750)
(buffers 992 14))

Message #8 received at 58917 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Oliver Yang <oliver_hom <at> yahoo.com>
Cc: 58917 <at> debbugs.gnu.org
Subject: Re: bug#58917: 28.2; Arm Build on Mac OS Monterey:  Buffer Name is
 on the same  line as Tool Bar Icons
Date: Tue, 01 Nov 2022 09:49:28 +0800

Oliver Yang <oliver_hom <at> yahoo.com> writes:

> Same problem described in the thread
> https://emacs.stackexchange.com/questions/64602/buffer-name-on-separate-row-from-toolbar-icons
>
> The Arm Build of emacs on Mac OS 12.6 will have buffer name on the same
> line as the toolbar icons.  This is not case with X86 version of 28.2 on
> Mac OS 12.6.
>
>
> In GNU Emacs 28.2 (build 1, aarch64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559))
> of 2022-09-12 built on armbob.lan
> Windowing system distributor 'Apple', version 10.3.2113
> System Description:  macOS 12.6

As usual, with Apple, this depends on what system you built Emacs on.

So my guess is you built the build exhibiting the new tool bar placement
on Mac OS 12, and the build that does not on some older version of Mac
OS.  There is nothing that we Emacs developers can do about this, I
think.

Message #11 received at 58917 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Oliver Yang <oliver_hom <at> yahoo.com>, 58917 <at> debbugs.gnu.org
Subject: Re: bug#58917: 28.2; Arm Build on Mac OS Monterey: Buffer Name is on
 the same line as Tool Bar Icons
Date: Sat, 12 Nov 2022 20:11:23 -0800

Po Lu <luangruo <at> yahoo.com> writes:

> Oliver Yang <oliver_hom <at> yahoo.com> writes:
>
>> Same problem described in the thread
>> https://emacs.stackexchange.com/questions/64602/buffer-name-on-separate-row-from-toolbar-icons
>>
>> The Arm Build of emacs on Mac OS 12.6 will have buffer name on the same
>> line as the toolbar icons.  This is not case with X86 version of 28.2 on
>> Mac OS 12.6.
>>
>>
>> In GNU Emacs 28.2 (build 1, aarch64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559))
>> of 2022-09-12 built on armbob.lan
>> Windowing system distributor 'Apple', version 10.3.2113
>> System Description:  macOS 12.6
>
> As usual, with Apple, this depends on what system you built Emacs on.
>
> So my guess is you built the build exhibiting the new tool bar placement
> on Mac OS 12, and the build that does not on some older version of Mac
> OS.  There is nothing that we Emacs developers can do about this, I
> think.

The linked thread suggests some solutions:

    It looks like you can change the default setting for whether or not
    the title (for Emacs, it's the buffer name) is over the toolbar with

        defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false

    [...]

    I think that something like the following code change to Emacs in
    the right place would change the default appearance always:

    if ( [NSToolbar instancesRespondToSelector:@selector(setToolbarStyle:)])
        [win setToolbarStyle: NSWindowToolbarStyleExpanded];

    for an NSWindow object win at an appropriate time.

There is also a link to:

    https://apple.stackexchange.com/questions/408475/revert-ui-on-big-sur

But people are also commenting that this no longer works on Monterey
(a.k.a. macOS 12, the latest version).  It is not clear to me if this
refers to the code change, or to the "defaults write" command only:

    Just an update for others who stumble across this: this setting
    seems to have been removed in Monterey (12.0). It doesn't work for
    me any longer, and that seems consistent with some other new web
    searches turning up similar results.

Perhaps we should test doing something like the code above, and if that
works make it into a defcustom?  If that's not possible for some reason,
perhaps it should be documented in PROBLEMS?

I don't really do Objective-C or macOS development, so I can't help with
this, I'm afraid.  I'm happy to test a solution if someone were to write
up a patch though.

Message #16 received at 58917 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Oliver Yang <oliver_hom <at> yahoo.com>, 58917 <at> debbugs.gnu.org
Subject: Re: bug#58917: 28.2; Arm Build on Mac OS Monterey: Buffer Name is
 on the same line as Tool Bar Icons
Date: Sun, 13 Nov 2022 12:45:57 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> The linked thread suggests some solutions:
>
>     It looks like you can change the default setting for whether or not
>     the title (for Emacs, it's the buffer name) is over the toolbar with
>
>         defaults write -g NSWindowSupportsAutomaticInlineTitle -bool false
>
>     [...]
>
>     I think that something like the following code change to Emacs in
>     the right place would change the default appearance always:
>
>     if ( [NSToolbar instancesRespondToSelector:@selector(setToolbarStyle:)])
>         [win setToolbarStyle: NSWindowToolbarStyleExpanded];
>
>     for an NSWindow object win at an appropriate time.
>
> There is also a link to:
>
>     https://apple.stackexchange.com/questions/408475/revert-ui-on-big-sur
>
> But people are also commenting that this no longer works on Monterey
> (a.k.a. macOS 12, the latest version).  It is not clear to me if this
> refers to the code change, or to the "defaults write" command only:
>
>     Just an update for others who stumble across this: this setting
>     seems to have been removed in Monterey (12.0). It doesn't work for
>     me any longer, and that seems consistent with some other new web
>     searches turning up similar results.
>
> Perhaps we should test doing something like the code above, and if that
> works make it into a defcustom?  If that's not possible for some reason,
> perhaps it should be documented in PROBLEMS?
>
> I don't really do Objective-C or macOS development, so I can't help with
> this, I'm afraid.  I'm happy to test a solution if someone were to write
> up a patch though.

Right.  The other question is whether or not we actually want to mess
with how Apple dictates the tool bar must be placed.

Message #19 received at 58917 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Oliver Yang <oliver_hom <at> yahoo.com>, 58917 <at> debbugs.gnu.org
Subject: Re: bug#58917: 28.2; Arm Build on Mac OS Monterey: Buffer Name is on
 the same line as Tool Bar Icons
Date: Sat, 12 Nov 2022 21:03:45 -0800

Po Lu <luangruo <at> yahoo.com> writes:

> Right.  The other question is whether or not we actually want to mess
> with how Apple dictates the tool bar must be placed.

FWIW, I'm perfectly fine with closing this as wontfix, while leaving
open the possibility to reevaluate the decision if someone presents a
working patch.

Message #26 received at 58917-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 58917-done <at> debbugs.gnu.org, Oliver Yang <oliver_hom <at> yahoo.com>
Subject: Re: bug#58917: 28.2; Arm Build on Mac OS Monterey: Buffer Name is on
 the same line as Tool Bar Icons
Date: Sat, 2 Sep 2023 09:42:25 -0700

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Po Lu <luangruo <at> yahoo.com> writes:
>
>> Right.  The other question is whether or not we actually want to mess
>> with how Apple dictates the tool bar must be placed.
>
> FWIW, I'm perfectly fine with closing this as wontfix, while leaving
> open the possibility to reevaluate the decision if someone presents a
> working patch.

No further comments within 10 months.

I'm therefore closing this bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.