[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#68765: 30.0.50; Adding window-tool-bar package.
From: |
Eli Zaretskii |
Subject: |
bug#68765: 30.0.50; Adding window-tool-bar package. |
Date: |
Tue, 04 Jun 2024 18:59:21 +0300 |
> Date: Mon, 03 Jun 2024 22:24:55 -0700
> From: Jared Finder <jared@finder.org>
> Cc: juri@linkov.net, 68765@debbugs.gnu.org, philipk@posteo.net,
> monnier@iro.umontreal.ca
>
> > How about if we make the behavior simpler and more predictable:
> >
> > If a window's buffer has a non-nil value of window-toolbar-mode,
> > show the window-specific tool bar regardless of what it is and
> > whether it is the same as the default.
> >
> > Why is this not good enough?
>
> I want the window-specfic tool bar to never be shown if there are no
> tool bar buttons, to conserve space. However, if tab-line-format is non
> nil, the tab line takes up space even if the resulting tab line is nil.
> This can happen if one sets the default tool bar to nil, while keeping
> the mode specific tool bars.
If the issue is not to show an empty tool bar, then this could be done
by a special test, without affecting behavior in other cases. And
having the tool bar completely empty is such a rare and strange
situation that we could even leave it alone, under the assumption that
such a "tool bar" is simply a bug of sorts.
Complicating the overall behavior, let alone the difficulties of
explaining the behavior in documentation, on behalf of such rare and
very special cases is hardly a good tradeoff, won't you agree?
> I think there's also a useful case where the frame tool bar is used to
> show a "global" tool bar with buttons that do not act on the current
> buffer (in the current default tool bar: new file, open file, open
> directory, all the modifier tool bar buttons) and the window tool bar is
> used to show buttons that act on the buffer. In this case, you don't
> want the "global" tool bar to change based on frame's selected window.
> The "tool-bar-always-show-default" variable I added as well as the logic
> with ignoring the default value of tool-bar-map was to enable this use
> case. I treat the default value of tool-bar-map as "no tool bar buttons
> for this window" since all those buttons are for the global tool bar.
> It'd be fine to limit behavior to only when tool-bar-always-show-default
> was set.
I'm not against tool-bar-always-show-default and its effect. But
introducing that optional behavior doesn't require any particular
behavior from window-specific tool bars, it's almost an orthogonal
feature.
My conclusion from this is that the two considerations you provided
in favor of a much more complex behavior do not contradict my
suggestion. The first consideration is about a very rare case, which
we could simply ignore (but if you feel strongly about detecting
empty tool bars and not displaying them, I won't object), while the
second consideration does not require the complicated behavior of
window-specific tool bars.
If I missed something, or if you still disagree, please tell what and
why.
Thanks.