bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Basil L. Contovounesios]

X-Debbugs-Cc: Juri Linkov <juri@linkov.net>, Martin Rudalics <rudalics@gmx.at>

In a build --without-x:

0. ./src/emacs -Q
1. (frame-inner-height) C-j

  Debugger entered--Lisp error: (void-function tab-bar-height)
    tab-bar-height(#<frame F1 0x55aeb85320a0> t)
    frame-inner-height()
    (progn (frame-inner-height))
    eval((progn (frame-inner-height)) t)
    elisp--eval-last-sexp(t)
    eval-last-sexp(t)
    eval-print-last-sexp(nil)
    funcall-interactively(eval-print-last-sexp nil)
    call-interactively(eval-print-last-sexp nil nil)
    command-execute(eval-print-last-sexp)

The obvious band-aid is to check (fboundp 'tab-bar-height) in
frame-inner-height, but shouldn't we count 1 line when tab-bar-mode is
enabled even --without-x?  IOW, can/should tab-bar-height or similar be
defined regardless of HAVE_WINDOW_SYSTEM?  What's TRT here?

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu)
 of 2021-03-18 built on tia
Repository revision: ce1b4acd71e962b6a72a779ee04cb5aeb6ceb6f2
Repository branch: master
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --program-suffix=-nox
 --enable-checking=structs --with-file-notification=yes
 --with-x-toolkit=no --without-x'

Configured features:
ACL DBUS GMP GNUTLS GPM JSON LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NOTIFY INOTIFY PDUMPER SOUND THREADS XIM ZLIB

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Debugger

Minor modes in effect:
  mouse-wheel-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-fns radix-tree cl-print debug backtrace
help-mode tool-bar find-func cl-loaddefs cl-lib term/xterm xterm
byte-opt gv bytecomp byte-compile cconv regexp-opt mwheel iso-transl
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select 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 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 dbusbind inotify lcms2 multi-tty make-network-process
emacs)

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Thu, 18 Mar 2021 13:41:04 +0000
> Cc: juri linkov <juri@linkov.net>
> 
> In a build --without-x:
> 
> 0. ./src/emacs -Q
> 1. (frame-inner-height) C-j
> 
>   Debugger entered--Lisp error: (void-function tab-bar-height)
>     tab-bar-height(#<frame F1 0x55aeb85320a0> t)
>     frame-inner-height()
>     (progn (frame-inner-height))
>     eval((progn (frame-inner-height)) t)
>     elisp--eval-last-sexp(t)
>     eval-last-sexp(t)
>     eval-print-last-sexp(nil)
>     funcall-interactively(eval-print-last-sexp nil)
>     call-interactively(eval-print-last-sexp nil nil)
>     command-execute(eval-print-last-sexp)
> 
> The obvious band-aid is to check (fboundp 'tab-bar-height) in
> frame-inner-height, but shouldn't we count 1 line when tab-bar-mode is
> enabled even --without-x?  IOW, can/should tab-bar-height or similar be
> defined regardless of HAVE_WINDOW_SYSTEM?  What's TRT here?

TRT is to teach Emacs to return the tab-bar height on TTY frames as
well.  But I don't think defining tab-bar-height on TTY frames is the
right way: the tab-bar is always 1 line high on those frames, so we
could simply use that hardcoded value instead of signaling an error, I
think.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Date: Thu, 18 Mar 2021 13:41:04 +0000
>> Cc: juri linkov <juri@linkov.net>
>> 
>> The obvious band-aid is to check (fboundp 'tab-bar-height) in
>> frame-inner-height, but shouldn't we count 1 line when tab-bar-mode is
>> enabled even --without-x?  IOW, can/should tab-bar-height or similar be
>> defined regardless of HAVE_WINDOW_SYSTEM?  What's TRT here?
>
> TRT is to teach Emacs to return the tab-bar height on TTY frames as
> well.  But I don't think defining tab-bar-height on TTY frames is the
> right way: the tab-bar is always 1 line high on those frames, so we
> could simply use that hardcoded value instead of signaling an error, I
> think.

I'm not familiar with the tab bar, but I get the impression it's not
that simple.  IIUC no lines should be subtracted if tab-bar-mode is off,
and even if it's on, the tab bar can be hidden subject to tab-bar-show.
That's why I was wondering whether this logic can/should be packed into
a single place (whether Ftab_bar_height or other I don't know).

Is the following close to TRT?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-bar.diff --]
[-- Type: text/x-diff, Size: 527 bytes --]

diff --git a/lisp/frame.el b/lisp/frame.el
index b5a8e0ed72..f4b8f1c418 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -1370,7 +1370,9 @@ frame-inner-height
 FRAME defaults to the selected frame."
   (setq frame (window-normalize-frame frame))
   (- (frame-native-height frame)
-     (tab-bar-height frame t)
+     (if (fboundp 'tab-bar-height)
+         (tab-bar-height frame t)
+       (frame-parameter frame 'tab-bar-lines))
      (* 2 (frame-internal-border-width frame))))
 
 (defun frame-outer-width (&optional frame)

[-- Attachment #3: Type: text/plain, Size: 20 bytes --]


Thanks,

-- 
Basil

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: 47234@debbugs.gnu.org,  juri@linkov.net
> Date: Thu, 18 Mar 2021 14:57:52 +0000
> 
> > TRT is to teach Emacs to return the tab-bar height on TTY frames as
> > well.  But I don't think defining tab-bar-height on TTY frames is the
> > right way: the tab-bar is always 1 line high on those frames, so we
> > could simply use that hardcoded value instead of signaling an error, I
> > think.
> 
> I'm not familiar with the tab bar, but I get the impression it's not
> that simple.

To be sure, I didn't mean to use just the number 1 there.

> IIUC no lines should be subtracted if tab-bar-mode is off,
> and even if it's on, the tab bar can be hidden subject to tab-bar-show.
> That's why I was wondering whether this logic can/should be packed into
> a single place (whether Ftab_bar_height or other I don't know).
> 
> Is the following close to TRT?

If it produces the right result under all of the complications you
mentioned, sure.

Thanks.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: 47234@debbugs.gnu.org,  juri@linkov.net
>> Date: Thu, 18 Mar 2021 14:57:52 +0000
>> 
>> > TRT is to teach Emacs to return the tab-bar height on TTY frames as
>> > well.  But I don't think defining tab-bar-height on TTY frames is the
>> > right way: the tab-bar is always 1 line high on those frames, so we
>> > could simply use that hardcoded value instead of signaling an error, I
>> > think.
>> 
>> I'm not familiar with the tab bar, but I get the impression it's not
>> that simple.
>
> To be sure, I didn't mean to use just the number 1 there.

I assumed you meant something like:

  (cond ((fboundp 'tab-bar-height) (tab-bar-height frame t))
        (tab-bar-mode 1)
        (0))

(At least that was my first thought.)

>> IIUC no lines should be subtracted if tab-bar-mode is off,
>> and even if it's on, the tab bar can be hidden subject to tab-bar-show.
>> That's why I was wondering whether this logic can/should be packed into
>> a single place (whether Ftab_bar_height or other I don't know).
>> 
>> Is the following close to TRT?
>
> If it produces the right result under all of the complications you
> mentioned, sure.

Thanks, it does AFAICT.  Hopefully Juri can confirm/deny for certain.
(For example, I don't know when one would pick Ftab_bar_height over the
frame property tab-bar-lines - maybe the latter can be used
unconditionally?)

-- 
Basil

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[martin rudalics]

 > Is the following close to TRT?
 >
 > +     (if (fboundp 'tab-bar-height)
 > +         (tab-bar-height frame t)
 > +       (frame-parameter frame 'tab-bar-lines))

I think that `tab-bar-height' should be bound and return a meaningful
value everywhere.  The frame parameters (in particular for the menu and
tool bar) are only a meaningless pain in this regard.

Many thanks for spotting and working on this, martin

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: 47234@debbugs.gnu.org,  juri@linkov.net
> Date: Thu, 18 Mar 2021 15:22:48 +0000
> 
> (For example, I don't know when one would pick Ftab_bar_height over the
> frame property tab-bar-lines - maybe the latter can be used
> unconditionally?)

Not AFAIU, because Ftab_bar_height returns its result in pixels, not
in lines.  On TTY frames, each line is 1 pixel.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Juri Linkov]

>>> Is the following close to TRT?
>>
>> If it produces the right result under all of the complications you
>> mentioned, sure.
>
> Thanks, it does AFAICT.  Hopefully Juri can confirm/deny for certain.
> (For example, I don't know when one would pick Ftab_bar_height over the
> frame property tab-bar-lines - maybe the latter can be used
> unconditionally?)

I agree with Martin that `tab-bar-height' should return a meaningful value
on --without-x builds too.

Please note this should be fixed on the release branch in Emacs 27.2
because the change in commit 6c5ddf0e0b was recently made in emacs-27.

I wonder why only tab-bar-height was added to frame-inner-height,
why not menu-bar-height as well?  Moreover, such function as
menu-bar-height doesn't exist at all.  Why only tab-bar-height is needed?

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Juri Linkov]

> In a build --without-x:
>
> 0. ./src/emacs -Q
> 1. (frame-inner-height) C-j
>
>   Debugger entered--Lisp error: (void-function tab-bar-height)
>     tab-bar-height(#<frame F1 0x55aeb85320a0> t)

There are the following warnings on the emacs-27 branch with --without-x:

frame.el:2749:1:Warning: the following functions are not known to be defined:
    tab-bar-height, x-display-list

tab-bar-height is handled here in bug#47234, and x-display-list in bug#29713.

There are more warnings, I don't know how important they are:

image.el:1145:1:Warning: the function `image-transforms-p' is not known to be
    defined.

gnus/gnus-util.el:1734:1:Warning: the function `image-size' is not known to be
    defined.
org/org-macs.el:1277:1:Warning: the function `image-size' is not known to be
    defined.

international/mule-diag.el:1188:1:Warning: the function `x-list-fonts' is not
    known to be defined.
term/w32-win.el:622:1:Warning: the function `x-list-fonts' is not known to be
    defined.

emulation/edt-mapper.el:521:1:Warning: the function `x-server-vendor' is not
    known to be defined.
emulation/edt.el:2546:1:Warning: the function `x-server-vendor' is not known
    to be defined.

gnus/nnimap.el:2273:1:Warning: the function `x-server-version' is not known to
    be defined.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[martin rudalics]

 > I wonder why only tab-bar-height was added to frame-inner-height,
 > why not menu-bar-height as well?

And `tool-bar-height' as well.  Darn.

 > Please note this should be fixed on the release branch in Emacs 27.2
 > because the change in commit 6c5ddf0e0b was recently made in emacs-27.

Then it's best to revert the frame.el part of 6c5ddf0e0b.

martin

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: martin rudalics <rudalics@gmx.at>,  Eli Zaretskii <eliz@gnu.org>,  47234@debbugs.gnu.org
> Date: Thu, 18 Mar 2021 19:07:55 +0200
> 
> >>> Is the following close to TRT?
> >>
> >> If it produces the right result under all of the complications you
> >> mentioned, sure.
> >
> > Thanks, it does AFAICT.  Hopefully Juri can confirm/deny for certain.
> > (For example, I don't know when one would pick Ftab_bar_height over the
> > frame property tab-bar-lines - maybe the latter can be used
> > unconditionally?)
> 
> I agree with Martin that `tab-bar-height' should return a meaningful value
> on --without-x builds too.

How do you propose to do that?  The design and implementation of the
code in tab-bar-height was stolen from the tool bar, and that was
written for GUI frames.  The text-mode tab bar has an entirely
different design and implementation, similar to the text-mode menu
bar.  There's almost nothing in common between these two.

> Please note this should be fixed on the release branch in Emacs 27.2
> because the change in commit 6c5ddf0e0b was recently made in emacs-27.

Why does it have to be done in Emacs 27.2?

Please be aware that Emacs 27.2 is all but released at this point.

> I wonder why only tab-bar-height was added to frame-inner-height,
> why not menu-bar-height as well?  Moreover, such function as
> menu-bar-height doesn't exist at all.  Why only tab-bar-height is needed?

Maybe tab-bar-height is not needed in this case, either.  We could
instead modify the code that attempts to call it.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 47234@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 18 Mar 2021 18:51:51 +0100
> 
>  > Please note this should be fixed on the release branch in Emacs 27.2
>  > because the change in commit 6c5ddf0e0b was recently made in emacs-27.
> 
> Then it's best to revert the frame.el part of 6c5ddf0e0b.

Ugh!

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Juri Linkov]

>> I agree with Martin that `tab-bar-height' should return a meaningful value
>> on --without-x builds too.
>
> How do you propose to do that?  The design and implementation of the
> code in tab-bar-height was stolen from the tool bar, and that was
> written for GUI frames.  The text-mode tab bar has an entirely
> different design and implementation, similar to the text-mode menu
> bar.  There's almost nothing in common between these two.

Then the fix is not straightforward, indeed.

>> Please note this should be fixed on the release branch in Emacs 27.2
>> because the change in commit 6c5ddf0e0b was recently made in emacs-27.
>
> Why does it have to be done in Emacs 27.2?
>
> Please be aware that Emacs 27.2 is all but released at this point.

Martin said that the commit 6c5ddf0e0b added recently in emacs-27
should be reverted from Emacs 27.2.

>> I wonder why only tab-bar-height was added to frame-inner-height,
>> why not menu-bar-height as well?  Moreover, such function as
>> menu-bar-height doesn't exist at all.  Why only tab-bar-height is needed?
>
> Maybe tab-bar-height is not needed in this case, either.  We could
> instead modify the code that attempts to call it.

Grepping shows that the only code that calls frame-inner-height
is mouse-drag-frame-resize.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: contovob@tcd.ie,  rudalics@gmx.at,  47234@debbugs.gnu.org
> Date: Thu, 18 Mar 2021 21:00:41 +0200
> 
> >> Please note this should be fixed on the release branch in Emacs 27.2
> >> because the change in commit 6c5ddf0e0b was recently made in emacs-27.
> >
> > Why does it have to be done in Emacs 27.2?
> >
> > Please be aware that Emacs 27.2 is all but released at this point.
> 
> Martin said that the commit 6c5ddf0e0b added recently in emacs-27
> should be reverted from Emacs 27.2.
> 
> >> I wonder why only tab-bar-height was added to frame-inner-height,
> >> why not menu-bar-height as well?  Moreover, such function as
> >> menu-bar-height doesn't exist at all.  Why only tab-bar-height is needed?
> >
> > Maybe tab-bar-height is not needed in this case, either.  We could
> > instead modify the code that attempts to call it.
> 
> Grepping shows that the only code that calls frame-inner-height
> is mouse-drag-frame-resize.

Thanks.

After thinking some more about this, I think we should leave the
frame.el part of 6c5ddf0e0b alone, but augment it with the fboundp
test, such that on TTY frames the tab bar would be included in the
frame's inner height, like the menu bar is.  This is also consistent
with what happens on TTY frames in a build with X: tab-bar-height
returns zero.

Basil, can you please install such a change on the emacs-27 branch?  I
will then make another RC.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

> After thinking some more about this, I think we should leave the
> frame.el part of 6c5ddf0e0b alone, but augment it with the fboundp
> test, such that on TTY frames the tab bar would be included in the
> frame's inner height, like the menu bar is.  This is also consistent
> with what happens on TTY frames in a build with X: tab-bar-height
> returns zero.
>
> Basil, can you please install such a change on the emacs-27 branch?  I
> will then make another RC.

Done:

Fix frame-inner-height in non-GUI builds
bd991e3c9b 2021-03-18 22:13:05 +0000
https://git.sv.gnu.org/cgit/emacs.git/commit/?id=bd991e3c9bc9c26e641036f52adf82e052d4319c

Is there anything left to address here on the master branch, or can this
report be closed?

The other --without-x warnings in frame.el are benign, and I'll try to
look into the rest of them soon, but none of them sound too alarming at
first glance (famous last words).

Thanks,

-- 
Basil

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Juri Linkov <juri@linkov.net>,  rudalics@gmx.at,  47234@debbugs.gnu.org
> Date: Thu, 18 Mar 2021 22:24:18 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > After thinking some more about this, I think we should leave the
> > frame.el part of 6c5ddf0e0b alone, but augment it with the fboundp
> > test, such that on TTY frames the tab bar would be included in the
> > frame's inner height, like the menu bar is.  This is also consistent
> > with what happens on TTY frames in a build with X: tab-bar-height
> > returns zero.
> >
> > Basil, can you please install such a change on the emacs-27 branch?  I
> > will then make another RC.
> 
> Done:

Thanks.

> Is there anything left to address here on the master branch, or can this
> report be closed?

I don't think we should do anything different on master, no.  At least
not without a good reason and/or a valid use case where this gets in
the way.

Martin, do you agree?

> The other --without-x warnings in frame.el are benign, and I'll try to
> look into the rest of them soon, but none of them sound too alarming at
> first glance (famous last words).

The only kind of problem they could reveal is if those functions are
actually called at run time in a build --without-x.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[martin rudalics]

 >> Then it's best to revert the frame.el part of 6c5ddf0e0b.
 >
 > Ugh!

My apologies.  I didn't expect anyone to care about this.

For the interested, a short history of that function: When I started to
implement child frames for Emacs, I noticed that while on Windows
everything worked OOTB, the various GNU/Linux systems I use provided no
mouse support for them at all.  So to avoid any unpleasant discussions,
I had to emulate the entire functionality in Elisp, several hundred
lines of code in mouse.el.

There, to make sure that child frames don't get too small during
dragging, I added a test where I compare the inner height of a frame
with that of the minimum size of its root window.  It's the inner height
because I have to drag the inner border of a frame - GNU/Linux doesn't
give me another choice.  And I wrote a separate function for retrieving
the inner height because `frame-edges' then appeared to expensive for a
function running in a tight loop like `mouse-drag-frame-resize'.

I didn't care about the menu bar (GNU/Linux generally doesn't like menu
bars on child frames) and the tool bar (so far I've not been able to
make a tool bar reliably show up on a GTK child frame).  So I silently
ignored these in `frame-inner-height'.  But I did notice recently, that
there's no reason why a child frame should _not_ have a tab bar and
that's why I made the change.

Hence, basically `frame-inner-height' is just an internal function (it
lacks the second "-" because it's defined in frame.el and used in
mouse.el) supposed to work exclusively in the very limited context of
frame dragging.  It's of absolutely no use on TTY frames but something
born out of the necessity to make Emacs work on systems lacking support
for certain features.

martin

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[martin rudalics]

 > I don't think we should do anything different on master, no.  At least
 > not without a good reason and/or a valid use case where this gets in
 > the way.
 >
 > Martin, do you agree?

Yes.

martin

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Eli Zaretskii]

> Cc: juri@linkov.net, contovob@tcd.ie, 47234@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 19 Mar 2021 09:14:50 +0100
> 
>  >> Then it's best to revert the frame.el part of 6c5ddf0e0b.
>  >
>  > Ugh!
> 
> My apologies.  I didn't expect anyone to care about this.

I care because this change, which was made 1.5 months ago, popped up
just hours after I made RC1, which I hoped could become Emacs 27.2.
Murphy's law in its finest, I guess.

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Basil L. Contovounesios]

tags 47234 fixed
close 47234 27.2
quit

martin rudalics <rudalics@gmx.at> writes:

>> I don't think we should do anything different on master, no.  At least
>> not without a good reason and/or a valid use case where this gets in
>> the way.
>>
>> Martin, do you agree?
>
> Yes.

Thanks, then I'm closing this report.

-- 
Basil

bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[Basil L. Contovounesios]

Juri Linkov <juri@linkov.net> writes:

> There are the following warnings on the emacs-27 branch with --without-x:

Thanks, should now be pacified on master:

Address some --without-x byte-compilation warnings
331ddd803a 2021-03-26 17:35:34 +0000
https://git.sv.gnu.org/cgit/emacs.git/commit/?id=331ddd803a72056d0f0c70e5a677e0d4a6300584

-- 
Basil