bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Jared Finder
Subject: 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@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





reply via email to

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