mouse-autoselect-window-select

mouse-autoselect-window-select

[Eli Zaretskii]

This change in window.el:

	(mouse-autoselect-window-select): Autoselect only if we are in the
	text portion of the window.

should IMO also trigger auto-selection when the mouse is in the
display margin area of the window.  That's because from the user
perspective the margins are an integral part of the text displayed in
a window, not one of the decorations.  Excluding display margins will
probably surprise users.

Re: mouse-autoselect-window-select

[martin rudalics]

 > This change in window.el:
 >
 > 	(mouse-autoselect-window-select): Autoselect only if we are in the
 > 	text portion of the window.
 >
 > should IMO also trigger auto-selection when the mouse is in the
 > display margin area of the window.  That's because from the user
 > perspective the margins are an integral part of the text displayed in
 > a window, not one of the decorations.  Excluding display margins will
 > probably surprise users.

We can do that, obviously.  But then, if `fringes-outside-margins' is
non-nil, I would have to trigger autoselection for fringes as well.  So
I'd like to wait until someone really finds the new behavior annoying.

The rationale behind the change is that when someone wants to drag the
modeline or the scrollbar of another window and hovers too long around
the sides of that window she will get an unwanted selection.

martin

Re: mouse-autoselect-window-select

[Eli Zaretskii]

> Date: Wed, 14 Aug 2013 17:36:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > This change in window.el:
>  >
>  > 	(mouse-autoselect-window-select): Autoselect only if we are in the
>  > 	text portion of the window.
>  >
>  > should IMO also trigger auto-selection when the mouse is in the
>  > display margin area of the window.  That's because from the user
>  > perspective the margins are an integral part of the text displayed in
>  > a window, not one of the decorations.  Excluding display margins will
>  > probably surprise users.
> 
> We can do that, obviously.  But then, if `fringes-outside-margins' is
> non-nil, I would have to trigger autoselection for fringes as well.  So
> I'd like to wait until someone really finds the new behavior annoying.

You could exclude the case of fringes-outside-margins.  No need to
wait for a complaint to DTRT.

Re: mouse-autoselect-window-select

[martin rudalics]

 > You could exclude the case of fringes-outside-margins.  No need to
 > wait for a complaint to DTRT.

What is TRT?  According to what you say here the following text from the
Elisp manual which informally mentions the "text area" of a window

      The "body height" of a window is the height of its text area, which
   does not include the mode or header line.  Similarly, the "body width"
   is the width of the text area, which does not include the scroll bar,
   fringes, or margins.

is incorrect.

martin

Re: mouse-autoselect-window-select

[Eli Zaretskii]

> Date: Wed, 14 Aug 2013 19:07:08 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > You could exclude the case of fringes-outside-margins.  No need to
>  > wait for a complaint to DTRT.
> 
> What is TRT?  According to what you say here the following text from the
> Elisp manual which informally mentions the "text area" of a window
> 
>       The "body height" of a window is the height of its text area, which
>    does not include the mode or header line.  Similarly, the "body width"
>    is the width of the text area, which does not include the scroll bar,
>    fringes, or margins.
> 
> is incorrect.

That's "text area" overloaded for you.  From the technical POV of the
display engine, text area indeed does not include the display
margins.  But from the user's POV, I think it surely does, because it
displays the same objects as the text area does: text and images, and
that display is created the same way as you'd display an overlay or
display string in the "text area".

Re: mouse-autoselect-window-select

[martin rudalics]

 > That's "text area" overloaded for you.  From the technical POV of the
 > display engine, text area indeed does not include the display
 > margins.  But from the user's POV, I think it surely does, because it
 > displays the same objects as the text area does: text and images, and
 > that display is created the same way as you'd display an overlay or
 > display string in the "text area".

The user's POV is that of one who uses `mouse-autoselect-window'.  I
don't know if you do or ever did - if so, please tell me your settings
and why you think that the new behavior may cause you troubles.
Otherwise please read on.

I use `mouse-autoselect-window' for a long time.  My value is -0.5 so I
consider myself a fairly cautious user.  Nevertheless, behavior broke
twice recently due to changes in `mouse-drag-line' and I was the only
one to complain so I think few people rely on it as much as I do.

The idea of moused autoselection is to make it possible to select a
window with a mouse without simultaneously setting point in that window.
Such selection should occur without intervening with mouse dragging of
modelines, dividers and/or scrollbars or selecting items from menus.
That's why Simon and I provided to delay autoselection until the mouse
pointer has stabilized in some way.

Unfortunately, some objects that shall be dragged can be difficult to
localize with the mouse as, for example, the one-pixel divider between
windows when scrollbars are absent.  In such cases one window can get
inadvertently selected even when selection is delayed.  Disabling
selection when the mouse is over a margin or fringe does help here.  I
invite you to experiment with the old and new behavior to either confirm
my claim or provide evidence against it.

Otherwise, I would have to add a new option to specify an area at the
borders of each window and disallow mouse selection there.  Doing that
is non-trivial because mouse-selecting a one line window should be still
possible.

By no means the behavior provided by my change was to convey semantics
that autoselection should be possible for "text areas" only.  I used
such a term in the ChangeLog because the area that is now sensitive to
mouse selection is congruent with the portion spanned by a window's body
and that portion is also referred to as the window's "text area".

martin

Re: mouse-autoselect-window-select

[Eli Zaretskii]

> Date: Thu, 15 Aug 2013 12:20:21 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > That's "text area" overloaded for you.  From the technical POV of the
>  > display engine, text area indeed does not include the display
>  > margins.  But from the user's POV, I think it surely does, because it
>  > displays the same objects as the text area does: text and images, and
>  > that display is created the same way as you'd display an overlay or
>  > display string in the "text area".
> 
> The user's POV is that of one who uses `mouse-autoselect-window'.  I
> don't know if you do or ever did - if so, please tell me your settings
> and why you think that the new behavior may cause you troubles.
> Otherwise please read on.

I don't see what my usage patterns and settings have to do with the
issue at hand.

The issue at hand is whether it is reasonable to NOT auto-select a
window when the mouse hovers over the display margin of that window.
I think this will be perceived as a misfeature, e.g. consider a buffer
under linum-mode, or vc-annotate.  The margins could be quite large,
and they definitely are part of the window from users' perspective.

If some user finds that auto-selecting a window when the mouse is over
the display margins is inconvenient for her for some reason, then
perhaps this feature is not for that user, and we should advise her to
turn this feature off.  But forcing personal preferences on others on
these grounds is not right, I think.

If you still don't agree, then I guess we will have to agree to
disagree.

Re: mouse-autoselect-window-select

[martin rudalics]

 > If some user finds that auto-selecting a window when the mouse is over
 > the display margins is inconvenient for her for some reason, then
 > perhaps this feature is not for that user, and we should advise her to
 > turn this feature off.  But forcing personal preferences on others on
 > these grounds is not right, I think.

It makes me sad to read an insinuation like this from you.  I never use
display margins and always keep personal preferences in my local Emacs.

 > If you still don't agree, then I guess we will have to agree to
 > disagree.

Although it completely defies my original change I modified the code in
your sense now.  Please have a look.

martin

Re: mouse-autoselect-window-select

[Eli Zaretskii]

> Date: Fri, 16 Aug 2013 12:03:33 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > If some user finds that auto-selecting a window when the mouse is over
>  > the display margins is inconvenient for her for some reason, then
>  > perhaps this feature is not for that user, and we should advise her to
>  > turn this feature off.  But forcing personal preferences on others on
>  > these grounds is not right, I think.
> 
> It makes me sad to read an insinuation like this from you.

I'm sorry this sounded as some kind of insinuation.  I certainly
didn't mean anything anywhere near that, and I apologize for whatever
it was that made that impression.  You cited your own experience,
which led me to a conclusion that the change is based on that
experience.  If I was mistaken, I'm sorry.

> Although it completely defies my original change I modified the code in
> your sense now.  Please have a look.

Thanks, this is what I meant.

I don't see how this defies your change, but I probably should shut up
before I offend you again.

Re: mouse-autoselect-window-select

[Davis Herring]

> Unfortunately, some objects that shall be dragged can be difficult to
> localize with the mouse as, for example, the one-pixel divider between
> windows when scrollbars are absent.  In such cases one window can get
> inadvertently selected even when selection is delayed.  Disabling
> selection when the mouse is over a margin or fringe does help here.  I
> invite you to experiment with the old and new behavior to either confirm
> my claim or provide evidence against it.

Is that true even when it is required that the mouse be completely still
for the delay?  I would think that the user would be trembling the mouse
around continuously trying to find the small drag target.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: mouse-autoselect-window-select

[martin rudalics]

 >> Unfortunately, some objects that shall be dragged can be difficult to
 >> localize with the mouse as, for example, the one-pixel divider between
 >> windows when scrollbars are absent.  In such cases one window can get
 >> inadvertently selected even when selection is delayed.  Disabling
 >> selection when the mouse is over a margin or fringe does help here.  I
 >> invite you to experiment with the old and new behavior to either confirm
 >> my claim or provide evidence against it.
 >
 > Is that true even when it is required that the mouse be completely still
 > for the delay?  I would think that the user would be trembling the mouse
 > around continuously trying to find the small drag target.

There's a short period while waiting for the mouse cursor to change
shape on vertical dividers where a user would not tremble the mouse.
And since there's no change of the shape for the mode and headerlines,
people used to see such a change from other applications might not
tremble the mouse there either.

martin