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

[Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On 2024-01-09 11:08, Stefan Kangas wrote:
> Eli Zaretskii <eliz@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