GNU bug report logs - #68334
29.1; tool-bar-make-keymap-1 does not work on terminals

Previous Next

Full log

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

From: Jared Finder <jared <at> finder.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 68334 <at> debbugs.gnu.org
Subject: Re: bug#68334: 29.1; tool-bar-make-keymap-1 does not work on terminals
Date: Tue, 09 Jan 2024 11:28:17 -0800

On 2024-01-09 11:08, Stefan Kangas wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> I didn't intend to propose including the existing implementation as 
>>> is,
>>> which I hadn't looked closely at.  Having done that just now, it 
>>> seems
>>> like it's implemented on the tab bar, as Juri has pointed out.  I 
>>> think
>>> this is probably not the right thing for a feature in Emacs itself.
>> 
>> How else do you expect this to be implemented on TTY frames?  It can
>> either overwrite parts of the menu bar, or it could overwrite parts of
>> the tab bar.  Something's gotta give, no?
>> 
>> I also don't understand why the tab bar is deemed more important than
>> the tool bar.  Let's let users decide what they prefer.  (Of course,
>> if there's a way to let them have the cake and eat it, too, that would
>> be the best.)
>> 
>>> This feature would be most useful as a first class feature, but that
>>> might require C changes.
>> 
>> IMO, usurping one more screen line from TTY frames could be
>> problematic, especially on terminals that display a relatively small
>> number of lines.
> 
> You could add another line, so that you could use the tab-bar and the
> tool-bar at the same time.  That would provide the most flexibility for
> users, I think.  They would themselves get to decide how many lines to
> sacrifice.  (Many users also have huge screens these days, including
> vertical ones.)
> 
> That said, I don't at all object to the current implementation as an
> optional feature in core, if you think it's a good idea.  There's no
> reason to allow perfect to be the enemy of the good.

If this goes in core, I'd like to make window-tool-bar-mode and 
tab-line-mode work nicely together.  Right now they both just overwrite 
tab-line-format, but I think a better implementation would result in 
them both appears in the tab-line side by side when both are enabled.  
In other words, if both are enabled tab-line-format would have a value 
like

((:eval (tab-line-format)) " " (:eval (window-tool-bar-string))).


I'm also happy to also add an additional line.  At that point there'd be 
three lines, so would it be worth it to add an option to control the 
order of the lines?  I can imagine a variable that contains lines / 
prefix events for lines above a buffer and controls the order.  I 
certainly would appreciate this flexibility.

Let me know what you think is the right way to proceed.

  -- MJF

Previous Next

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