GNU bug report logs - #46178
28.0.50; auto-resize-tool-bars / auto-resize-tab-bars grow-only

Previous Next

To reply to this bug, email your comments to 46178 AT debbugs.gnu.org.

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 28.0.50; auto-resize-tool-bars / auto-resize-tab-bars grow-only
Date: Fri, 29 Jan 2021 19:12:02 +0100

With emacs -Q run a graphical build with a tab bar or an internal tool
bar (motif, lucid, no toolkit have the latter).  Do

(setq auto-resize-tab-bars 'grow-only)

and/or

(setq auto-resize-tool-bars 'grow-only)

Now make the frame very narrow so the tool and/or tab bar wrap(s)
around.  Expand the frame again, so the items on the bar(s) occupy one
line only.  You will see empty lines below the lines showing the items.

According to the doc-strings of the above options and the Elisp manual
you should now be able to use 'recenter' to get rid of these empty
lines:

  If value is ‘grow-only’, the tab-bar’s height is only increased
  automatically; to decrease the tab-bar height, use M-x recenter.

However, this doesn't work by default since in the following part of
'recenter'

      if (!NILP (redisplay)
	  && !NILP (Vrecenter_redisplay)
	  && (!EQ (Vrecenter_redisplay, Qtty)
	      || !NILP (Ftty_type (selected_frame))))
	{
	  ptrdiff_t i;

	  /* Invalidate pixel data calculated for all compositions.  */
	  for (i = 0; i < n_compositions; i++)
	    composition_table[i]->font = NULL;
#if defined (HAVE_WINDOW_SYSTEM)
	  WINDOW_XFRAME (w)->minimize_tab_bar_window_p = 1;
#endif
#if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR)
	  WINDOW_XFRAME (w)->minimize_tool_bar_window_p = 1;
#endif
	  Fredraw_frame (WINDOW_FRAME (w));
	  SET_FRAME_GARBAGED (WINDOW_XFRAME (w));

Vrecenter_redisplay is by default 'tty' and Ftty_type (selected_frame)
is nil, so the conjunct never becomes true and minimize_tab_bar_window_p
is never set to 1.

So we'd have to mention in the docs of this option that one can regain
these lines only by setting 'recenter-redisplay' to anything but the
default.  Better IMHO would be to abolish the never used and completely
useless 'grow-only' value for these options.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46178 <at> debbugs.gnu.org
Subject: Re: bug#46178: 28.0.50;
 auto-resize-tool-bars / auto-resize-tab-bars grow-only
Date: Fri, 29 Jan 2021 22:09:06 +0200

> From: martin rudalics <rudalics <at> gmx.at>
> Date: Fri, 29 Jan 2021 19:12:02 +0100
> 
> So we'd have to mention in the docs of this option that one can regain
> these lines only by setting 'recenter-redisplay' to anything but the
> default.

The doc string already says that.

> Better IMHO would be to abolish the never used and completely
> useless 'grow-only' value for these options.

That's a separate issue.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46178 <at> debbugs.gnu.org
Subject: Re: bug#46178: 28.0.50; auto-resize-tool-bars / auto-resize-tab-bars
 grow-only
Date: Sat, 30 Jan 2021 11:18:09 +0100

>> So we'd have to mention in the docs of this option that one can regain
>> these lines only by setting 'recenter-redisplay' to anything but the
>> default.
>
> The doc string already says that.

That of 'recenter' does.  But since these options do not work out of the
box (a user has to customize the option 'recenter-redisplay' too), it
would be useful if the docs of 'auto-resize-tool-bars' and
'auto-resize-tab-bars' told so.  At the moment they just tell me to use
M-x recenter or C-l.  Also, the doc string of 'recenter' does not
mention the tab bar and its Elisp manual entry mentions neither the tab
nor the tool bar.

>> Better IMHO would be to abolish the never used and completely
>> useless 'grow-only' value for these options.
>
> That's a separate issue.

We could stop mentioning 'grow-only' in the doc-strings and manuals and
leave it in as an undocumented feature.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46178 <at> debbugs.gnu.org
Subject: Re: bug#46178: 28.0.50; auto-resize-tool-bars / auto-resize-tab-bars
 grow-only
Date: Sat, 30 Jan 2021 16:17:50 +0200

> Cc: 46178 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 30 Jan 2021 11:18:09 +0100
> 
>  >> So we'd have to mention in the docs of this option that one can regain
>  >> these lines only by setting 'recenter-redisplay' to anything but the
>  >> default.
>  >
>  > The doc string already says that.
> 
> That of 'recenter' does.  But since these options do not work out of the
> box (a user has to customize the option 'recenter-redisplay' too), it
> would be useful if the docs of 'auto-resize-tool-bars' and
> 'auto-resize-tab-bars' told so.  At the moment they just tell me to use
> M-x recenter or C-l.

OK, I fixed that.

> Also, the doc string of 'recenter' does not mention the tab bar and
> its Elisp manual entry mentions neither the tab nor the tool bar.

Not sure why that is a problem.  We don't have to have everything
mentioned in every possible place.

>  >> Better IMHO would be to abolish the never used and completely
>  >> useless 'grow-only' value for these options.
>  >
>  > That's a separate issue.
> 
> We could stop mentioning 'grow-only' in the doc-strings and manuals and
> leave it in as an undocumented feature.

You know me: I'm uneasy about downgrading features just because they
are awkward or inconvenient to document.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46178 <at> debbugs.gnu.org
Subject: Re: bug#46178: 28.0.50; auto-resize-tool-bars / auto-resize-tab-bars
 grow-only
Date: Sat, 30 Jan 2021 16:27:11 +0100

>> That of 'recenter' does.  But since these options do not work out of the
>> box (a user has to customize the option 'recenter-redisplay' too), it
>> would be useful if the docs of 'auto-resize-tool-bars' and
>> 'auto-resize-tab-bars' told so.  At the moment they just tell me to use
>> M-x recenter or C-l.
>
> OK, I fixed that.

Thanks.  You won't believe it but yesterday this would have saved me
half an hour poking around with this.  Until then I didn't know that
'recenter' is now our moral equivalent of 'redisplay'.

You might also reconsider the Elisp manual entry where it says

     If this variable is non-‘nil’, the tool bar automatically resizes
     to show all defined tool bar items—but not larger than a quarter of
     the frame’s height.

I've been digging through Gerd's and Kim's rewrites of
'redisplay_tool_bar' and nowhere found a reference to that "quarter".
Did that ever work and when?

>> We could stop mentioning 'grow-only' in the doc-strings and manuals and
>> leave it in as an undocumented feature.
>
> You know me: I'm uneasy about downgrading features just because they
> are awkward or inconvenient to document.

I stumbled across this feature because wrapping and unwrapping the tool
bar on Motif by changing the frame width shrinks the frame height for
inexplicable reasons until it is down to a few lines.  Lucid and
non-toolkit builds do not have this issue.  Currently, I just try to
understand the design considerations and whether they are responsible
for the behavior I see.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46178 <at> debbugs.gnu.org
Subject: Re: bug#46178: 28.0.50; auto-resize-tool-bars / auto-resize-tab-bars
 grow-only
Date: Sat, 30 Jan 2021 21:48:08 +0200

> Cc: 46178 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 30 Jan 2021 16:27:11 +0100
> 
> You might also reconsider the Elisp manual entry where it says
> 
>       If this variable is non-‘nil’, the tool bar automatically resizes
>       to show all defined tool bar items—but not larger than a quarter of
>       the frame’s height.
> 
> I've been digging through Gerd's and Kim's rewrites of
> 'redisplay_tool_bar' and nowhere found a reference to that "quarter".
> Did that ever work and when?

If the current behavior is that we allow any number of tool-bar lines,
then this text is inaccurate and should be fixed to describe the
current behavior.

Previous Next

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