[Top][All Lists]

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

Re: Tabs

From: Eli Zaretskii
Subject: Re: Tabs
Date: Thu, 10 Oct 2019 12:59:08 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Thu, 10 Oct 2019 11:15:55 +0200
> (3) Once the frame has been made and f->tool_bar_resized is set, the
>      latter is never reset again and it's really one-off in the sense
>      you described.

Thanks.  I will update the commentary for these members to reflect
your description.

>  > No, I think the cause of the problem is that we have no equivalent of
>  > "C-x 6 f" that turns on the tool bar as a side effect of a command
>  > that displays a buffer.
> I'm missing you here.  Do you mean that displaying a tool bar for the
> first time in an Emacs session on a specific frame when you display a
> certain buffer on that frame would have a similar dramatic effect?

That's my current theory, yes.  Although I'm nowhere near sure it's

> Couldn't you verify that?

I don't know how.  We don't have the equivalent of "C-x 6 f" that
turns on a tool bar that was off before that, do we?

> I'm still not entirely sure whether it was a good idea to cargo cult
> the tab bar code from the tool bar code.

As a first approximation, it wasn't a bad idea.  But it needs various
adjustments due to the tab-bar specifics (including, but not limited
to, tab bar on TTY frames, where there's no "prior art" in tool-bar
code), and that's what we are struggling with now.  Also, the default
GTK build has a tool bar that is displayed entirely unlike the tab
bar, and that is another difficulty.

Btw... why do we set frame_inhibit_implied_resize to nil in GTK
builds?  Shouldn't it be (tab-bar-lines) instead?  The tab bar in GTK
build uses our own window, doesn't it?

reply via email to

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