[Top][All Lists]

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

Re: Tabs

From: martin rudalics
Subject: Re: Tabs
Date: Wed, 9 Oct 2019 20:12:44 +0200

> Martin, can you please explain the rationale behind this code in
> x_change_tool_bar_height (and similar code in the w32 variant)?

It's also in GTK's update_frame_tool_bar.

>    /* Recalculate toolbar height.  */
>    f->n_tool_bar_rows = 0;
>    if (old_height == 0
>        && (!f->after_make_frame
>      || NILP (frame_inhibit_implied_resize)
>      || (CONSP (frame_inhibit_implied_resize)
>          && NILP (Fmemq (Qtool_bar_lines, frame_inhibit_implied_resize)))))
>      f->tool_bar_redisplayed = f->tool_bar_resized = false;
>    adjust_frame_size (f, -1, -1,
>                 ((!f->tool_bar_resized
>                   && (NILP (fullscreen =
>                             get_frame_param (f, Qfullscreen))
>                       || EQ (fullscreen, Qfullwidth))) ? 1
>                  : (old_height == 0 || height == 0) ? 2
>                  : 4),
>                 false, Qtool_bar_lines);
>    f->tool_bar_resized = f->tool_bar_redisplayed;
> Here are the questions that I couldn't answer myself:
>   . why the tool_bar_resized flag is reset when
>     frame-inhibit-implied-resize is nil, i.e. implied resizing is _NOT_
>     inhibited? shouldn't it be the other way around?

The original motivation was as follows.  A frame needs intially as
many text lines as the user wants.  On the Lucid, Motif, Windows
builds, as an ancient rule, a frame does not get resized when the tool
bar is activated or deactivated.  However, in the before make frame
phase the frame must be resized to get its number of lines.

So the idea was that redisplay eventually will set
tool_bar_redisplayed after calculating the tool bar height and that
value is copied to tool_bar_resized to make sure this frame never gets
resized again when the tool bar changes.  So these resets should
handle only this initial resize operation and no others.

In addition we should not resize if 'frame-inhibit-implied-resize' is
t, the frame is full height or full screen and the like.

>   . the above resets the tool_bar_redisplayed flag,

... conditionally, though ...

>     then uses it after
>     the call to adjust_frame_size; but nothing in that call can ever
>     change the value of the tool_bar_redisplayed flag, so I don't
>     understand what the code tries to accomplish.

It's at least badly documented and maybe also badly ordered.  The idea
is that eventually the tool_bar_redisplayed and the tool_bar_resized
flag get both set and in the default case the frame is never resized
after that when the number of tool bar lines changes.

>   . which code is supposed to reset the tool_bar_resized flag?  AFAICT,
>     once set, it stays set, at least in "emacs -Q".  Did I miss
>     something?  Same question regarding the tool_bar_redisplayed flag.

Once set for a particular frame, these are never reset.  The aim was
(after a row of complaints) a single one: To give all frames
regardless of build and window system the same initial number of text
lines regardless of whether tool bars are turned on or off initially.

> The real motivation for these questions is the problem with
> redisplaying the frame when tab-bar is turned on by "C-x 6 f", but
> since the tab-bar code was simply copied from the tool-bar code, I
> find myself wondering about the latter, and hope you can show me the
> light there.

As you mentioned earlier, tab bars are initially off and the tool bar
is on.  Maybe that's the cause of the problem.


reply via email to

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