unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: mouse-autoselect-window-select
Date: Thu, 15 Aug 2013 12:20:21 +0200	[thread overview]
Message-ID: <520CAB65.60303@gmx.at> (raw)
In-Reply-To: <838v04p2yx.fsf@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 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



  reply	other threads:[~2013-08-15 10:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-14 15:21 mouse-autoselect-window-select Eli Zaretskii
2013-08-14 15:36 ` mouse-autoselect-window-select martin rudalics
2013-08-14 15:59   ` mouse-autoselect-window-select Eli Zaretskii
2013-08-14 17:07     ` mouse-autoselect-window-select martin rudalics
2013-08-14 18:00       ` mouse-autoselect-window-select Eli Zaretskii
2013-08-15 10:20         ` martin rudalics [this message]
2013-08-15 14:59           ` mouse-autoselect-window-select Eli Zaretskii
2013-08-16 10:03             ` mouse-autoselect-window-select martin rudalics
2013-08-16 10:28               ` mouse-autoselect-window-select Eli Zaretskii
2013-08-15 15:45           ` mouse-autoselect-window-select Davis Herring
2013-08-16 10:03             ` mouse-autoselect-window-select martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=520CAB65.60303@gmx.at \
    --to=rudalics@gmx.at \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).