GNU bug report logs - #68765
30.0.50; Adding window-tool-bar package.

Previous Next

Full log

View this message in rfc822 format

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: philipk <at> posteo.net, 68765 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: bug#68765: 30.0.50; Adding window-tool-bar package.
Date: Sun, 02 Jun 2024 08:57:52 -0700

(I mistakenly sent this to just Eli.  Sorry about that!)

On 2024-06-02 08:56, Jared Finder wrote:
> On 2024-06-01 22:21, Eli Zaretskii wrote:
>>> Date: Sat, 01 Jun 2024 21:17:58 -0700
>>> From: Jared Finder <jared <at> finder.org>
>>> Cc: juri <at> linkov.net, 68765 <at> debbugs.gnu.org, philipk <at> posteo.net,
>>>  monnier <at> iro.umontreal.ca
>>> 
>>> > I'm beginning to think that the feature whereby we don't display the
>>> > window's tool bar under some conditions "to conserve space" is more
>>> > confusing and hard to document than is useful, and perhaps we should
>>> > simply show the window's tool bar unconditionally?
>>> 
>>> I find it really useful to have this auto-show/hide behavior.  As I
>>> wrote in the docs, "you can think of the window tool bar as showing a
>>> major mode specific tool bar if it exists".
>> 
>> That's okay, I'm just saying that if the window's major mode has its
>> own tool bar, we should show that tool bar on a window regardless of
>> whether the frame's tool bar shows the same buttons.
> 
> <and also from later on>
> 
>>> +  The command @code{global-window-tool-bar-mode} toggles the display 
>>> of
>>> +a tool bar at the top of each window.  When enabled, multiple 
>>> windows
>>> +can display their own tool bar simultaneously.  To conserve space, a
>>> +window tool bar is only shown if the tool bar for the window's 
>>> displayed
>>> +buffer has a different binding from the global (default) tool bar.  
>>> The
>> 
>> This should explain what does "global (default) tool bar" mean.  My
>> understanding is that this is the tool bar shown for the frame, which
>> will continue working as it does now, i.e. be determined by the major
>> mode of the frame's selected window.
> 
> <and also>
> 
>>> Having no space taken up when editing a text file, then having the
>>> tool bar appear when I hit C-s lines up with what I see in many
>>> other programs.  I'd be sad to see this behavior removed.
>> 
>> That's not what I'm talking about.  I'm talking about removing the
>> window's tool bar because the frame's tool bar became identical to it.
>> Here's a scenario:
>> 
>>   . you have a frame with Info mode and some other mode
>>   . the frame's tool bar is the default one, and the window under Info
>>     shows its own tool bar from info.el
>>   . now I type "C-h i" in the window that was previously in mode other
>>     than Info -- now the frame's tool bar is the one from Info mode,
>>     and suddenly the other window loses its window-specific tool bar!
>> 
>> IOW, what bothers me is that we _remove_ the window's tool bar because
>> the frame-global tool bar changed.  And you just confirmed above that,
>> while currently this is not the behavior, you'd like to fix the code
>> so it _is_ the behavior.
>> 
>> Am I missing something?
> 
> There's a misunderstanding here.  Can you please suggest how I can 
> change the documentation?  I'm not sure why the documentation I wrote 
> is confusing.
> 
> Let me explicitly describe the terms I am using:
> 
> When I write "the global (default) tool bar", that refers to the value 
> of (default-value 'tool-bar-map).  It's the tool bar with New File, 
> Open File, Open Directory, Kill Buffer, Save, Undo, Cut, Copy, Paste, 
> Isearch.  This doesn't change with major mode.  As far as I can tell, 
> it doesn't change during normal Emacs operations (unless a user chooses 
> to modify it, of course).
> 
> When I write "the frame tool bar", that refers to the tool bar 
> displayed at the top of a frame, as controlled by M-x tool-bar-mode.  
> There is no change of behavior here except for the new user option 
> tool-bar-always-show-default.
> 
> When I write "the window tool bar", that refers to the tool bar 
> displayed at the top of a window, as controlled by (newly added) M-x 
> window-tool-bar-mode or M-x global-window-tool-bar-mode.  The window 
> tool bar displays the value of tool-bar-map the window's displayed 
> buffer.  But it only displays that tool bar if it is not the same as 
> the global (default) tool bar.  It does not pay attention to the frame 
> tool bar.  Specifically, the test is:
> 
>  (eq tool-bar-map ;a buffer's tool bar
>      (default-value 'tool-bar-map) ;the global (default) tool bar
>   )
> 
> I hope from the above description it is clear that switching windows 
> does not cause the window tool bar to flicker as the window tool bar 
> doesn't care what the frame tool bar shows.
> 
>>> The most prominent other source of a custom tool bar is isearch.
>> 
>> Oh, there are many more modes that customize the tool bar in important
>> ways.  Help mode, Info mode, Customize, GUD modes, email modes, Grep,
>> and EWW, to name just a few popular ones.
> 
> Are there any others that are minor modes like isearch?  I ask because 
> the "only display when tool bar is different" check isn't run on minor 
> mode changes.  That's the bug I'm referring to that I'd like to fix.  
> Currently Window Tool Bar mode adds a function to isearch-mode-hook and 
> isearch-mode-end-hook to work properly with isearch.  I would prefer a 
> generic way to handle this.
> 
> 
> All other suggested changes I'll add to my next patch.  I'm just 
> waiting to figure out how to properly document the above 
> misunderstanding.
> 
>   -- MJF

Previous Next

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