Toolbar redraw causes unwanted selection

Toolbar redraw causes unwanted selection

[JD Smith]

When two windows in a single frame have different toolbars displayed
which occupy a different number of rows, changing input focus between
them by clicking with the mouse causes an unwanted selection to occur.

Steps to reproduce:

- Open two files in two windows split vertically in a single frame.

- In the bottom window, M-x gdb [Ret]

- Resize the frame horizontally so that the GDB toolbar icons just fit
  in a single row.

- Switch to the top window in the frame by clicking on it with the
  mouse, without dragging.

Since the normal editing toolbar now occupies *two* rows, the text is
shifted down as the toolbar is redrawn, and several lines of text are
selected, even though no drag was performed.

This has real-world applicability for idlwave, since its toolbars
occupy two rows even with normal frame widths.

JD

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    - Open two files in two windows split vertically in a single frame.

    - In the bottom window, M-x gdb [Ret]

    - Resize the frame horizontally so that the GDB toolbar icons just fit
      in a single row.

    - Switch to the top window in the frame by clicking on it with the
      mouse, without dragging.

    Since the normal editing toolbar now occupies *two* rows, the text is
    shifted down as the toolbar is redrawn, and several lines of text are
    selected, even though no drag was performed.

This is clearly a bug.  The question is, what is the right approach
for fixing it.  We could fix it at the narrow level by making the
mouse tracking code note that the mouse didn't actually move, and not
treat this as a drag.  But maybe the right fix is not to change the
height of the toolbar.  Maybe once the tool bar gets bigger it should
keep its new size until the user does something to let it shrink again.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> This is clearly a bug.  The question is, what is the right approach
> for fixing it.  We could fix it at the narrow level by making the
> mouse tracking code note that the mouse didn't actually move, and not
> treat this as a drag.  

That would be the right fix.  I'll take a look at it.

>                        But maybe the right fix is not to change the
> height of the toolbar.  Maybe once the tool bar gets bigger it should
> keep its new size until the user does something to let it shrink again.

And what should that action be?  

IMO, this would be a gigantic step backwards -- since the toolbar
resizing code (after a lot of work) actually works correctly now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> This is clearly a bug.  The question is, what is the right approach
>> for fixing it.  We could fix it at the narrow level by making the
>> mouse tracking code note that the mouse didn't actually move, and not
>> treat this as a drag.  
>
> That would be the right fix.  I'll take a look at it.

I have just installed a fix for this.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    >                        But maybe the right fix is not to change the
    > height of the toolbar.  Maybe once the tool bar gets bigger it should
    > keep its new size until the user does something to let it shrink again.

    And what should that action be?  

Perhaps (recenter nil), i.e., typing C-l.

    IMO, this would be a gigantic step backwards -- since the toolbar
    resizing code (after a lot of work) actually works correctly now.

It's good that the resizing code works, because we certainly want
automatic resizing when the tool bar wants to get bigger.  And if we
change to waiting for C-l to make it smaller, that will use the
automatic resizing code too.

The reason I suggest waiting for C-l (or maybe for something else)
before making it smaller is that I think the frequent changes
in tool bar size, when switching back and forth between two windows,
could be annoying for the user.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> The reason I suggest waiting for C-l (or maybe for something else)
> before making it smaller is that I think the frequent changes
> in tool bar size, when switching back and forth between two windows,
> could be annoying for the user.

I don't see an easy way to implement the "wait for C-l" -- and for the
case at hand, it doesn't even solve the problem, as the abnormal
behaviour happens when the toolbar size is increased.

And there are no _frequent_ changes in tool-bar size; it happens when
users change buffers/windows ... which is the right/only time to do
it.

In any case, I've fixed the reported bug, so I don't see a need
to change tool-bar functionality now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> The reason I suggest waiting for C-l (or maybe for something else)
>> before making it smaller is that I think the frequent changes
>> in tool bar size, when switching back and forth between two windows,
>> could be annoying for the user.
>
> I don't see an easy way to implement the "wait for C-l" -- and for the
> case at hand, it doesn't even solve the problem, as the abnormal
> behaviour happens when the toolbar size is increased.
>
> And there are no _frequent_ changes in tool-bar size; it happens when
> users change buffers/windows ... which is the right/only time to do
> it.

Uh, no frequent changes?  The minibuffer is, after all, a separate
buffer with its own toolbar and maps.

-- 
David Kastrup

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> And there are no _frequent_ changes in tool-bar size; it happens when
>> users change buffers/windows ... which is the right/only time to do
>> it.
>
> Uh, no frequent changes?  The minibuffer is, after all, a separate
> buffer with its own toolbar and maps.

You are right.  I'll take that back.

Still, I prefer that automatic resizing of the tool-bar is ...
.. automatic.

If people don't like that, turn off auto-resize-tool-bars.

After the release, we can consider implementing a "grow-only" setting
of auto-resize-tool-bars.  Not now!


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    If people don't like that, turn off auto-resize-tool-bars.

    After the release, we can consider implementing a "grow-only" setting
    of auto-resize-tool-bars.  Not now!

I don't think so, because I think this feature is probably essentially
crippled by this annoyance.  And this ought to be easy enough.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     If people don't like that, turn off auto-resize-tool-bars.
>
>     After the release, we can consider implementing a "grow-only" setting
>     of auto-resize-tool-bars.  Not now!
>
> I don't think so, because I think this feature is probably essentially
> crippled by this annoyance.  And this ought to be easy enough.

Are you serious?

ONE user has complained about a specific buggy aspect of the
auto-resize feature ... which I fixed.  Now you say the whole
functionality is ESSENTIALLY CRIPPLED.  Come on.

Have *YOU* ever noticed/been annoyed by a toolbar changing size??
If so, why didn't you complain about it before (years ago)?

Would it be possible to _focus_ on the REAL problems blocking the
release?  E.g. the TOTALLY CRIPPLED FONT-LOCK performance.


But ok, if you want to lift the feature freeze, I have several
features I would like to add.  

For example, the animated gif support I have ready to install -- and
which is a really annoying lack of functionality when reading my Xmas
mails in Gnus.


Anybody else here getting a bit tired... ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Werner LEMBERG]

> But ok, if you want to lift the feature freeze, I have several
> features I would like to add.
>
> For example, the animated gif support I have ready to install -- and
> which is a really annoying lack of functionality when reading my Xmas
> mails in Gnus.

:-)  Jingle bells, j
                      i
                        n
                         g

                          l



                            e




                               b



     Werner

Re: Toolbar redraw causes unwanted selection

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Sat, 16 Dec 2006 00:42:18 +0100
> Cc: emacs-devel@gnu.org
> 
> Have *YOU* ever noticed/been annoyed by a toolbar changing size??

I certainly never noticed this alleged annoyance.

> Would it be possible to _focus_ on the REAL problems blocking the
> release?  E.g. the TOTALLY CRIPPLED FONT-LOCK performance.
> [...]
> Anybody else here getting a bit tired... ?

What _I_ am tired of is of explaining on help-gnu-emacs that various
features that are buggy or don't work or are unavailable in Emacs 21.x
will be better off in Emacs 22.

We should release Emacs 22.1 ASAP, IMO, and for that to happen, we
should move away and/or reject any non-essential change, bug-fix, or
``annoyance-fix'' such as this one.  I submit that any misfeature that
was present in Emacs for a long time cannot be an essential fix that
we must make before the release.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

> What _I_ am tired of is of explaining on help-gnu-emacs that various
> features that are buggy or don't work or are unavailable in Emacs 21.x
> will be better off in Emacs 22.

Yes it is getting really silly ...  our typical advice to anyone who
complains about problems in emacs 21.x is to try "CVS emacs aka Emacs
22.1"

So in effect, Emacs 22.1 has already been "released" for _years_ in an
infinite number of different versions.

> We should release Emacs 22.1 ASAP, IMO, and for that to happen, we
> should move away and/or reject any non-essential change, bug-fix, or
> ``annoyance-fix'' such as this one.  I submit that any misfeature that
> was present in Emacs for a long time cannot be an essential fix that
> we must make before the release.

I only see ONE problem remaining ... the slow font-lock in C mode.
And it seems there is a good change it will be fixed (to some
tolerable level) soon.

.. we still have 2 weeks left to make a release in 2006 !!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Jan Djärv]

Kim F. Storm skrev:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> What _I_ am tired of is of explaining on help-gnu-emacs that various
>> features that are buggy or don't work or are unavailable in Emacs 21.x
>> will be better off in Emacs 22.
> 
> Yes it is getting really silly ...  our typical advice to anyone who
> complains about problems in emacs 21.x is to try "CVS emacs aka Emacs
> 22.1"
> 
> So in effect, Emacs 22.1 has already been "released" for _years_ in an
> infinite number of different versions.

Ubunty Edgy has emacs-snapshot (a CVS version from September) in its distribution.

	Jan D.

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    Have *YOU* ever noticed/been annoyed by a toolbar changing size??
    If so, why didn't you complain about it before (years ago)?

I have not noticed it change size because I don't have one.  I
normally edit on a text console.  So my experience doesn't directly
prove anything.

But your argument may be a good point.  If a substantial number of
people have been using cases which make this size change back and
forth happen, and not complaining, it can't be a big pain for most
users.

How long has the auto-resze code been in place?  Also, for how long
have the modes which currently need a bigger toolbar needed that?

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> How long has the auto-resze code been in place?  

1998-10-19  Gerd Moellmann  <gerd@gnu.org>

	* xdisp.c (toolbar_lines_needed): New.
	(auto-resize-toolbars): New.

>                                                  Also, for how long
> have the modes which currently need a bigger toolbar needed that?

Don't know, but IIRC someone spoke about IDLWAVE, and was in 21.1

1999-12-20  Carsten Dominik  <cd@gnu.org>

	* progmodes/idlwave.el: New file.

	* progmodes/idlwave-rinfo.el: New file.

	* progmodes/idlwave-shell.el: New file.

	* progmodes/idlwave-toolbar.el: New file.



The "only" changes I have made are to actually make the resizing work
-- so that it don't draw more toolbar lines than needed, doesn't omits
some icons, doesn't forget to redraw the toolbar when needed, and to
evenly distribute the icons on the toolbar lines to get rid of the "filler
line" between the toolbar and the top-most text window.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    The "only" changes I have made are to actually make the resizing work
    -- so that it don't draw more toolbar lines than needed, doesn't omits
    some icons, doesn't forget to redraw the toolbar when needed, and to
    evenly distribute the icons on the toolbar lines to get rid of the "filler
    line" between the toolbar and the top-most text window.

If Idlwave uses as many icons in Emacs 21 as it does now,
then I think your argument is airtight.  It would look uglier
in Emacs 21 without your fixes, so if no one has complained,
we can ignore it.

Could you (or someone) verify that Idlwave causes toolbar size changes
in Emacs 21 in the same case where it does now?  If so, that will
settle the question conclusively.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The "only" changes I have made are to actually make the resizing work
>     -- so that it don't draw more toolbar lines than needed, doesn't omits
>     some icons, doesn't forget to redraw the toolbar when needed, and to
>     evenly distribute the icons on the toolbar lines to get rid of the "filler
>     line" between the toolbar and the top-most text window.
>
> If Idlwave uses as many icons in Emacs 21 as it does now,
> then I think your argument is airtight.  It would look uglier
> in Emacs 21 without your fixes, so if no one has complained,
> we can ignore it.

When I try IDLWAVE, in either 21 or 22, the tool-bar icons easily fit on
one line.  So I don't know what the problem is...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     The "only" changes I have made are to actually make the resizing work
>>     -- so that it don't draw more toolbar lines than needed, doesn't omits
>>     some icons, doesn't forget to redraw the toolbar when needed, and to
>>     evenly distribute the icons on the toolbar lines to get rid of the "filler
>>     line" between the toolbar and the top-most text window.
>>
>> If Idlwave uses as many icons in Emacs 21 as it does now,
>> then I think your argument is airtight.  It would look uglier
>> in Emacs 21 without your fixes, so if no one has complained,
>> we can ignore it.
>
> When I try IDLWAVE, in either 21 or 22, the tool-bar icons easily fit on
> one line.  So I don't know what the problem is...

People use different font sizes in order to fit more frames on a
screen.  The toolbar might not fit then.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    > If Idlwave uses as many icons in Emacs 21 as it does now,
    > then I think your argument is airtight.  It would look uglier
    > in Emacs 21 without your fixes, so if no one has complained,
    > we can ignore it.

    When I try IDLWAVE, in either 21 or 22, the tool-bar icons easily fit on
    one line.  So I don't know what the problem is...

The problem must depend on circumstances, and it does not occur for you.

Since Smith has been seeing this all along, and says it is just a
small annoyance, I now accept your argument that this isn't a serious
problem and we don't need to do anything about it now.

After the release, I would like to add the short-term grow-only feature
we've discussed.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > If Idlwave uses as many icons in Emacs 21 as it does now,
>     > then I think your argument is airtight.  It would look uglier
>     > in Emacs 21 without your fixes, so if no one has complained,
>     > we can ignore it.
>
>     When I try IDLWAVE, in either 21 or 22, the tool-bar icons easily fit on
>     one line.  So I don't know what the problem is...
>
> The problem must depend on circumstances, and it does not occur for you.
>
> Since Smith has been seeing this all along, and says it is just a
> small annoyance, I now accept your argument that this isn't a serious
> problem and we don't need to do anything about it now.

Well, he just said that he got many bad reactions to the resizing from
his users of IDL mode.  So it doesn't seem to be a minor annoyance.

>
> After the release, I would like to add the short-term grow-only feature
> we've discussed.

I went ahead and implemented it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    > The reason I suggest waiting for C-l (or maybe for something else)
    > before making it smaller is that I think the frequent changes
    > in tool bar size, when switching back and forth between two windows,
    > could be annoying for the user.

    I don't see an easy way to implement the "wait for C-l" -- and for the
    case at hand, it doesn't even solve the problem, as the abnormal
    behaviour happens when the toolbar size is increased.

You are right; this bug would still have to be fixed at the low level.

Nonetheless, the change I suggest in the auto-resize behavior would
avoid a behavior that might be quite annoying.  It only takes two
characters to switch windows, and I often do that a few times in a
row.  If the toolbar were to change size each time, it would be
very distracting.  If it were to remain enlarged until I type C-l
to let it shrink back down, that distraction would be gone.

Re: Toolbar redraw causes unwanted selection

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > The reason I suggest waiting for C-l (or maybe for something else)
>     > before making it smaller is that I think the frequent changes
>     > in tool bar size, when switching back and forth between two windows,
>     > could be annoying for the user.
>
>     I don't see an easy way to implement the "wait for C-l" -- and for the
>     case at hand, it doesn't even solve the problem, as the abnormal
>     behaviour happens when the toolbar size is increased.
>
> You are right; this bug would still have to be fixed at the low level.
>
> Nonetheless, the change I suggest in the auto-resize behavior would
> avoid a behavior that might be quite annoying.  It only takes two
> characters to switch windows,

I count M-x as _one_ character, and the combination v q from dired
switches buffers on every keystroke.

> and I often do that a few times in a row.  If the toolbar were to
> change size each time, it would be very distracting.  If it were to
> remain enlarged until I type C-l to let it shrink back down, that
> distraction would be gone.

Possibly.  One would need to try it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Toolbar redraw causes unwanted selection

[JD Smith]

On Dec 15, 2006, at 2:24 PM, Richard Stallman wrote:

>> The reason I suggest waiting for C-l (or maybe for something else)
>> before making it smaller is that I think the frequent changes
>> in tool bar size, when switching back and forth between two windows,
>> could be annoying for the user.
>
>     I don't see an easy way to implement the "wait for C-l" -- and  
> for the
>     case at hand, it doesn't even solve the problem, as the abnormal
>     behaviour happens when the toolbar size is increased.
>
> You are right; this bug would still have to be fixed at the low level.
>
> Nonetheless, the change I suggest in the auto-resize behavior would
> avoid a behavior that might be quite annoying.  It only takes two
> characters to switch windows, and I often do that a few times in a
> row.  If the toolbar were to change size each time, it would be
> very distracting.  If it were to remain enlarged until I type C-l
> to let it shrink back down, that distraction would be gone.

As someone who often switches rapidly between row and 1-row toolbar  
windows (a C buffer and an IDLWAVE buffer, for instance), I can  
confirm that the constant resizing is a bit annoying -- though much  
less than the original unintended selection.  One toolbar size per  
frame would seem a good idea, based on the maximum number of rows  
required for all windows in that frame.  This way, as buffers are  
switched to other modes/etc., the toolbar resizes, but simply  
switching windows (by clicking, C-x o, etc.) won't trigger the resize.

Post-release, it would also be very nice to be able to specify the  
addition of a new row of toolbar buttons independent of frame width,  
for modes which append to the original set of buttons.  This would  
also result in less churn in toolbar height, and would be more  
visually appealing for modes which add a themed set of icons.

JD

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

> On Dec 15, 2006, at 2:24 PM, Richard Stallman wrote:
>
>>> The reason I suggest waiting for C-l (or maybe for something else)
>>> before making it smaller is that I think the frequent changes
>>> in tool bar size, when switching back and forth between two windows,
>>> could be annoying for the user.
>>
>>     I don't see an easy way to implement the "wait for C-l" -- and
>> for the
>>     case at hand, it doesn't even solve the problem, as the abnormal
>>     behaviour happens when the toolbar size is increased.
>>
>> You are right; this bug would still have to be fixed at the low level.
>>
>> Nonetheless, the change I suggest in the auto-resize behavior would
>> avoid a behavior that might be quite annoying.  It only takes two
>> characters to switch windows, and I often do that a few times in a
>> row.  If the toolbar were to change size each time, it would be
>> very distracting.  If it were to remain enlarged until I type C-l
>> to let it shrink back down, that distraction would be gone.
>
> As someone who often switches rapidly between row and 1-row toolbar
> windows (a C buffer and an IDLWAVE buffer, for instance), I can
> confirm that the constant resizing is a bit annoying -- though much
> less than the original unintended selection.  

So why don't you turn it off then?

>                                               One toolbar size per
> frame would seem a good idea, 

That's already what tool-bar-lines in frame-paramteres do.

>                               based on the maximum number of rows
> required for all windows in that frame.  This way, as buffers are
> switched to other modes/etc., the toolbar resizes, but simply
> switching windows (by clicking, C-x o, etc.) won't trigger the resize.

That's a nice idea, but quite impractical.  The tool-bar may depend on
a keymap property at specific buffer positions, so how can you know
what's needed?

I think the only practical approach is an explicit "grow-only" setting
for auto-resize-tool-bars, and then define some specific commands
which may reduce the toolbar size (e.g. C-l as RMS suggested).

> Post-release, it would also be very nice to be able to specify the
> addition of a new row of toolbar buttons independent of frame width,
> for modes which append to the original set of buttons.  This would
> also result in less churn in toolbar height, and would be more
> visually appealing for modes which add a themed set of icons.

I'm not sure I understand.  Do you want a "line break" in the toolbar
lines or ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[JD Smith]

On Dec 19, 2006, at 3:02 AM, Kim F. Storm wrote:
>> As someone who often switches rapidly between row and 1-row toolbar
>> windows (a C buffer and an IDLWAVE buffer, for instance), I can
>> confirm that the constant resizing is a bit annoying -- though much
>> less than the original unintended selection.
>
> So why don't you turn it off then?

That's what I end up doing.  Many users prefer the toolbar (which has  
some conveniences), and don't know how to turn it off.  And I might  
actually use it more if not for these twin inconveniences.

>>                                               One toolbar size per
>> frame would seem a good idea,
>
> That's already what tool-bar-lines in frame-paramteres do.

Hadn't heard of it, but if this is optional, I suppose all modes  
would need to set it to be effective.

>>                               based on the maximum number of rows
>> required for all windows in that frame.  This way, as buffers are
>> switched to other modes/etc., the toolbar resizes, but simply
>> switching windows (by clicking, C-x o, etc.) won't trigger the  
>> resize.
>
> That's a nice idea, but quite impractical.  The tool-bar may depend on
> a keymap property at specific buffer positions, so how can you know
> what's needed?

That's a good point.  I suppose Richard's "grow but don't shrink"  
method is the only suitable approach in light of this.  If the  
toolbar grew too large due to some over-eager mode, that would also  
be frustrating.  The current behavior may be the least of the various  
evils.

> I think the only practical approach is an explicit "grow-only" setting
> for auto-resize-tool-bars, and then define some specific commands
> which may reduce the toolbar size (e.g. C-l as RMS suggested).
>
>> Post-release, it would also be very nice to be able to specify the
>> addition of a new row of toolbar buttons independent of frame width,
>> for modes which append to the original set of buttons.  This would
>> also result in less churn in toolbar height, and would be more
>> visually appealing for modes which add a themed set of icons.
>
> I'm not sure I understand.  Do you want a "line break" in the toolbar
> lines or ?

Basically, yes.  One row of default editing icons.  One row of mode- 
specific icons.

Thanks,

JD

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

> On Dec 19, 2006, at 3:02 AM, Kim F. Storm wrote:
>>> As someone who often switches rapidly between row and 1-row toolbar
>>> windows (a C buffer and an IDLWAVE buffer, for instance), I can
>>> confirm that the constant resizing is a bit annoying -- though much
>>> less than the original unintended selection.

Have you added more icons to the IDLWAVE tool-bar ?
The default tool-bar doesn't need extra lines ...

>> So why don't you turn it off then?
>
> That's what I end up doing.  Many users prefer the toolbar (which has
> some conveniences), and don't know how to turn it off.  And I might
> actually use it more if not for these twin inconveniences.

I meant turn off just auto-resize-tool-bars ...


>> That's already what tool-bar-lines in frame-paramteres do.
>
> Hadn't heard of it, but if this is optional, I suppose all modes
> would need to set it to be effective.

Modes don't normally mess with frame parameters like that.
Only you can know (for sure) what is needed here.

You can just add it to default-frame-alist.


>>> Post-release, it would also be very nice to be able to specify the
>>> addition of a new row of toolbar buttons independent of frame width,
>>> for modes which append to the original set of buttons.  This would
>>> also result in less churn in toolbar height, and would be more
>>> visually appealing for modes which add a themed set of icons.
>>
>> I'm not sure I understand.  Do you want a "line break" in the toolbar
>> lines or ?
>
> Basically, yes.  One row of default editing icons.  One row of mode- 
> specific icons.

Let's take that after the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[JD Smith]

On Dec 19, 2006, at 9:09 AM, Kim F. Storm wrote:

> JD Smith <jdsmith@as.arizona.edu> writes:
>
>> On Dec 19, 2006, at 3:02 AM, Kim F. Storm wrote:
>>>> As someone who often switches rapidly between row and 1-row toolbar
>>>> windows (a C buffer and an IDLWAVE buffer, for instance), I can
>>>> confirm that the constant resizing is a bit annoying -- though much
>>>> less than the original unintended selection.
>
> Have you added more icons to the IDLWAVE tool-bar ?
> The default tool-bar doesn't need extra lines ...

None have been added in several years.  Perhaps you have the default  
Emacs editing toolbar icons disabled?  Normally, IDLWAVE's icons are  
appended to these (since they are valid in an idlwave-mode buffer),  
causing the toolbar resize for normal frame widths and font sizes.   
Is it possible this is the only mode which appends enough to the  
normal editing set to wrap?  I find it hard to believe.

>>> So why don't you turn it off then?
>>
>> That's what I end up doing.  Many users prefer the toolbar (which has
>> some conveniences), and don't know how to turn it off.  And I might
>> actually use it more if not for these twin inconveniences.
>
> I meant turn off just auto-resize-tool-bars ...

Aha, I see.  But then I'd have to go around with a 2 row toolbar all  
the time, even when it was mostly blank.

JD

Re: Toolbar redraw causes unwanted selection

[Nick Roberts]

 > > Have you added more icons to the IDLWAVE tool-bar ?
 > > The default tool-bar doesn't need extra lines ...
 > 
 > None have been added in several years.  Perhaps you have the default  
 > Emacs editing toolbar icons disabled?  Normally, IDLWAVE's icons are  
 > appended to these (since they are valid in an idlwave-mode buffer),  
 > causing the toolbar resize for normal frame widths and font sizes.   
 > Is it possible this is the only mode which appends enough to the  
 > normal editing set to wrap?  I find it hard to believe.

How about making IDLWAVE *replace* the default icons?  I don't know if
it's a good analogy but that's what I do in GUD.  The default icons could
be used in the source buffers but I don't think they're as useful, and when
the debug session is killed the default icons appear again.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Toolbar redraw causes unwanted selection

[JD Smith]

On Dec 28, 2006, at 10:57 PM, Nick Roberts wrote:

>>> Have you added more icons to the IDLWAVE tool-bar ?
>>> The default tool-bar doesn't need extra lines ...
>>
>> None have been added in several years.  Perhaps you have the default
>> Emacs editing toolbar icons disabled?  Normally, IDLWAVE's icons are
>> appended to these (since they are valid in an idlwave-mode buffer),
>> causing the toolbar resize for normal frame widths and font sizes.
>> Is it possible this is the only mode which appends enough to the
>> normal editing set to wrap?  I find it hard to believe.
>
> How about making IDLWAVE *replace* the default icons?  I don't know if
> it's a good analogy but that's what I do in GUD.  The default icons  
> could
> be used in the source buffers but I don't think they're as useful,  
> and when
> the debug session is killed the default icons appear again.

The IDLWAVE icons appear whenever a shell session is running, not  
just when debugging, since they can be used to set and modify  
breakpoints, compile the file, examine variables, etc.  Appending to  
the existing icon set is intentional, since the user can still do all  
the normal editing things.  A better solution than appending, which  
isn't yet possible, is to place the IDLWAVE icons on a separate row  
of the toolbar.

Thanks,

JD

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

> On Dec 19, 2006, at 9:09 AM, Kim F. Storm wrote:
>
>> JD Smith <jdsmith@as.arizona.edu> writes:
>>
>>> On Dec 19, 2006, at 3:02 AM, Kim F. Storm wrote:
>>>>> As someone who often switches rapidly between row and 1-row toolbar
>>>>> windows (a C buffer and an IDLWAVE buffer, for instance), I can
>>>>> confirm that the constant resizing is a bit annoying -- though much
>>>>> less than the original unintended selection.
>>
>> Have you added more icons to the IDLWAVE tool-bar ?
>> The default tool-bar doesn't need extra lines ...
>
> None have been added in several years.  Perhaps you have the default
> Emacs editing toolbar icons disabled?  Normally, IDLWAVE's icons are
> appended to these (since they are valid in an idlwave-mode buffer),
> causing the toolbar resize for normal frame widths and font sizes.
> Is it possible this is the only mode which appends enough to the
> normal editing set to wrap?  I find it hard to believe.

I just did M-x idlwave-mode in an empty buffer.  If that's not enough
to make the extra icons appear, that's why I didn't see them.

>>>> So why don't you turn it off then?
>>>
>>> That's what I end up doing.  Many users prefer the toolbar (which has
>>> some conveniences), and don't know how to turn it off.  And I might
>>> actually use it more if not for these twin inconveniences.
>>
>> I meant turn off just auto-resize-tool-bars ...
>
> Aha, I see.  But then I'd have to go around with a 2 row toolbar all
> the time, even when it was mostly blank.

Well, you can make a command which toggle between 1 and 2 toolbar rows.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[JD Smith]

>
> I just did M-x idlwave-mode in an empty buffer.  If that's not enough
> to make the extra icons appear, that's why I didn't see them.

Right, the icons appear only if the shell is running (which won't  
work without IDL installed).  Sorry for the confusion.  I have  
received numerous reports from users annoyed with the toolbar  
behavior, and have typically just instructed them how to disable to  
toolbar altogether.

Regarding the original spurious selection bug, I tried out your fix,  
and it does indeed defeat the selection when toolbar size changes.   
However, I noticed two issues with the implementation:

1.  When you click to switch to another window within the frame, and  
the toolbar height changes, the point moves to the location of the  
cursor *after* the text is shifted.  Ideally, the point would be  
placed exactly where the user clicks (i.e. the click location before  
the toolbar resize occurs).

2. Clicking to drag a selection is now defeated when toolbar size  
changes.  Normally, if the focus is in a given window, click-dragging  
in another window in the frame immediately begins defining a  
selection.  With your fix in place, for windows with different  
toolbar heights, no selection is created when dragging in this manner  
(you must first give that window focus).

Thanks,

JD

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

>> I just did M-x idlwave-mode in an empty buffer.  If that's not enough
>> to make the extra icons appear, that's why I didn't see them.
>
> Right, the icons appear only if the shell is running (which won't
> work without IDL installed).  Sorry for the confusion.  I have
> received numerous reports from users annoyed with the toolbar
> behavior, and have typically just instructed them how to disable to
> toolbar altogether.

Ok, so the current behaviour is not really acceptable.

I just implemented the `grow-only' setting for auto-resize-tool-bars,
and the use of C-l to reduce the height as suggested by RMS.

> Regarding the original spurious selection bug, I tried out your fix,
> and it does indeed defeat the selection when toolbar size changes.

Good!

> > However, I noticed two issues with the implementation:
>
> 1.  When you click to switch to another window within the frame, and
> the toolbar height changes, the point moves to the location of the
> cursor *after* the text is shifted.  Ideally, the point would be
> placed exactly where the user clicks (i.e. the click location before
> the toolbar resize occurs).

Yes.  I have noticed this too, but doing the right thing seems quite hard.

The problem is that the window+toolbar is redrawn before emacs sees
the mouse-up event -- so the position of the "up" event is the NEW
position.  We might find some way to DTRT, but it must wait until
after the release!

>
> 2. Clicking to drag a selection is now defeated when toolbar size
> changes.  Normally, if the focus is in a given window, click-dragging
> in another window in the frame immediately begins defining a
> selection.  With your fix in place, for windows with different
> toolbar heights, no selection is created when dragging in this manner
> (you must first give that window focus).

The problem is the same as above ... but it is even harder to do
right, as the position of the down event is handled before we update
the display, so if we have to handle this, we somehow have to go back
and patch that event to the new position ...  Not trivial!  So the
patch I made to fix the selection bug actually was an explicit flag to
ignore the the "drag" event imposed by the "down" event position
being at a different position that the new position after redisplay
has modified the toolbar height.

This is even harder to handle that 1, so it must also wait.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    I just implemented the `grow-only' setting for auto-resize-tool-bars,
    and the use of C-l to reduce the height as suggested by RMS.

Thanks.  Could you see if anything in the Emacs manual calls for
change for this?

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I just implemented the `grow-only' setting for auto-resize-tool-bars,
>     and the use of C-l to reduce the height as suggested by RMS.
>
> Thanks.  Could you see if anything in the Emacs manual calls for
> change for this?

Done.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    Is it possible this is the only mode which appends enough to the  
    normal editing set to wrap?  I find it hard to believe.

It seems quite plausible to me, because I think very few parts of
Emacs add any tool bar icons.

The idea of putting a "line break" into the tool bar sounds interesting
for after the release.

RE: Toolbar redraw causes unwanted selection

[Drew Adams]

> The idea of putting a "line break" into the tool bar sounds
> interesting for after the release.

Sorry, I have not been following this thread, but by adding a "line break"
do you mean incrementing `tool-bar-lines'? Do you mean something else that
would at least include incrementing `tool-bar-lines'?

The reason I ask is that I have code that examines `tool-bar-lines' to guess
at the frame height taken up by the tool bar. If the effective tool-bar
height gets increased without `tool-bar-lines' being incremented, that would
mess up the measurement.

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    > The idea of putting a "line break" into the tool bar sounds
    > interesting for after the release.

    Sorry, I have not been following this thread, but by adding a "line break"
    do you mean incrementing `tool-bar-lines'?

No, it means putting something into the list of toolbar icons which
says "make a line break here".  Like a newline character in text.

RE: Toolbar redraw causes unwanted selection

[Drew Adams]

>     > The idea of putting a "line break" into the tool bar sounds
>     > interesting for after the release.
>
>     Sorry, I have not been following this thread, but by adding a
>     "line break" do you mean incrementing `tool-bar-lines'?
>
> No, it means putting something into the list of toolbar icons which
> says "make a line break here".  Like a newline character in text.

Could you also please increment `tool-bar-lines' when you do that, so that
`tool-bar-lines' continues to reflect the visual appearance (addition of
another line of tool bars)?

IIUC, you are talking about changing the number of visual tool-bar lines
without also changing the frame parameter `tool-bar-lines'. Doing that will
make it difficult to guess at the frame height used by the tool bar. I
currently estimate that at 2 * frame-char-height * tool-bar-lines, and that
works well. (I treat a nil value as 0.)

As long as `set-frame-size' includes the tool-bar height in its effect, I
will need to account for the tool-bar height when I fit a frame to its
(sole) buffer. (`set-frame-size' does not include the menu-bar height, but
it does include the tool-bar height.)

RE: Toolbar redraw causes unwanted selection

[Drew Adams]

I said:

> I currently estimate [tool-bar height] at 2 * frame-char-height *
> tool-bar-lines, and that works well. (I treat a nil value as 0.)

Before someone else jumps in to say that the tool-bar height is unrelated to
the frame-char-height: yes, I realize that. That formula works well for some
common character sizes, but it would perhaps be better to use a constant.

It would be great if there were a variable or frame parameter that reflected
the tool-bar height or the height of a single tool-bar line (so height would
be that times `tool-bar-lines'). I imagine that such a height could be
different for different toolkits etc.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> IIUC, you are talking about changing the number of visual tool-bar lines
> without also changing the frame parameter `tool-bar-lines'.

No.  

Changing the height of the tool bar is actually done by modifying the
tool-bar-lines frame parameter.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: Toolbar redraw causes unwanted selection

[Drew Adams]

> > IIUC, you are talking about changing the number of visual tool-bar lines
> > without also changing the frame parameter `tool-bar-lines'.
> 
> No.  
> 
> Changing the height of the tool bar is actually done by modifying the
> tool-bar-lines frame parameter.

That reassures me. I must have misunderstood Richard's reply. Thx.

Re: Toolbar redraw causes unwanted selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > The idea of putting a "line break" into the tool bar sounds
>     > interesting for after the release.
>
>     Sorry, I have not been following this thread, but by adding a "line break"
>     do you mean incrementing `tool-bar-lines'?
>
> No, it means putting something into the list of toolbar icons which
> says "make a line break here".  Like a newline character in text.

This is quite easy for the native tool-bar, but it requires special
treatment for each of the various tool-kits and ports.  So this is
definitely for after the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

    > No, it means putting something into the list of toolbar icons which
    > says "make a line break here".  Like a newline character in text.

    This is quite easy for the native tool-bar, but it requires special
    treatment for each of the various tool-kits and ports.  So this is
    definitely for after the release.

I agree.

Re: Toolbar redraw causes unwanted selection

[Richard Stallman]

      One toolbar size per  
    frame would seem a good idea, based on the maximum number of rows  
    required for all windows in that frame.  This way, as buffers are  
    switched to other modes/etc., the toolbar resizes, but simply  
    switching windows (by clicking, C-x o, etc.) won't trigger the resize.

That sounds like a good plan.  However, it seems you don't find this
problem unbearable even now.  So we can postpone any further change
here to after the release.

Re: Toolbar redraw causes unwanted selection

[JD Smith]

On Dec 20, 2006, at 6:00 AM, Richard Stallman wrote:

>       One toolbar size per
>     frame would seem a good idea, based on the maximum number of rows
>     required for all windows in that frame.  This way, as buffers are
>     switched to other modes/etc., the toolbar resizes, but simply
>     switching windows (by clicking, C-x o, etc.) won't trigger the  
> resize.
>
> That sounds like a good plan.  However, it seems you don't find this
> problem unbearable even now.  So we can postpone any further change
> here to after the release.

Yes, definitely, along with a means to specify a "newline" for  
breaking toolbar rows.