emacs-devel
[Top][All Lists]
Advanced

[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 14:33:23 +0300

> Cc: address@hidden, address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Thu, 10 Oct 2019 12:38:01 +0200
> 
>  > 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?
> 
> Doesn't Juri's recipe from Bug#37609 work?  Start with
> 
> emacs -Q -f tool-bar-mode
> 
> and use some function that enables 'tool-bar-mode'.

I need a function that will turn on the tool bar from
switch-to-buffer-* family of functions, and then cause adjustment of
frame glyphs from set-window-buffer, via apply_window_adjustment.  If
you have a suggestion for how to do this, please tell.

>  > 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.
> 
> Shouldn't on a TTY the tab bar behave just like the menu bar?

Similar, yes.  But that a separate code, and it cannot be shared with
the menu bar, because the tab bar needs to know on the C level which
tab was clicked (the latter is a consequence of the fact that tab bar
support was copied from tool bar support code).

>  > Also, the default
>  > GTK build has a tool bar that is displayed entirely unlike the tab
>  > bar, and that is another difficulty.
> 
> Which difficulty?

That similar problems with tool bar might go unnoticed because the
code is never run.

>  > Btw... why do we set frame_inhibit_implied_resize to nil in GTK
>  > builds?  Shouldn't it be (tab-bar-lines) instead?
> 
> Now that you mention it, yes.

Will do.



reply via email to

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