Selection threshold with mouse

Selection threshold with mouse

[Tak Kunihiro]

When I set region using mouse from left to right, region expands at
very end of each character.  Is it possible to set to threshold to the
middle of a character instead of very end of a character?
__        __
\ \      / /
 \ \ /\ / / 
  \ V  V /  
   \_/\_/   
--0123456789

With vanilla Emacs on selection of letter `W', region extends when
mouse cursor goes across `8'.  Instead, is it possible to make it
happen on `4'?

RE: Selection threshold with mouse

[Drew Adams]

> When I set region using mouse from left to right, region expands at
> very end of each character.  Is it possible to set to threshold to the
> middle of a character instead of very end of a character?

Not too sure what you mean, but the region (selection) is the
sequence of characters between two buffer positions (point and mark).

Emacs buffer positions are always between characters (or before the
first character or after the last character).  They are never "on" a
character.

Re: Selection threshold with mouse

[Barry Margolin]

In article <mailman.5704.1405791121.1147.help-gnu-emacs@gnu.org>,
 Drew Adams <drew.adams@oracle.com> wrote:

> > When I set region using mouse from left to right, region expands at
> > very end of each character.  Is it possible to set to threshold to the
> > middle of a character instead of very end of a character?
> 
> Not too sure what you mean, but the region (selection) is the
> sequence of characters between two buffer positions (point and mark).
> 
> Emacs buffer positions are always between characters (or before the
> first character or after the last character).  They are never "on" a
> character.

To expand on this, it's essentially the same as selecting a character 
with the mouse. If you click on a character, the cursor will be put on 
that character. But when the cursor is "on" a character, the point is 
actually to the left of that character -- if you set the mark and then 
move left, the highlighted character is not in the region.

So swiping works consistently with selecting a character. When you swipe 
to the right, the rightmost character isn't included in the region until 
you reach the space between it and the next character. When you swipe to 
the left, the character is included in the region as soon as you go past 
the space between it and the next character.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Barry Margolin <barmar@alum.mit.edu>
> Date: Sat, 19 Jul 2014 11:26:17 -0700
> 
> if you set the mark and then move left, the highlighted character is
> not in the region.

The highlighted characters are always part of the region.  Emacs never
highlights characters that are not part of the region: doing so would
be misleading and confusing.

RE: Selection threshold with mouse

[Drew Adams]

> > if you set the mark and then move left, the highlighted character is
> > not in the region.
> 
> The highlighted characters are always part of the region.  Emacs never
> highlights characters that are not part of the region: doing so would
> be misleading and confusing.

I think Barry meant that the char that appeared to be under the cursor
is not part of the region (in the scenario he described). Not that it
was highlighted using the region highlighting but that it was
"highlighted" by the (box) cursor (before moving point).

Re: Selection threshold with mouse

[Tak Kunihiro]

>> When I set region using mouse from left to right, region expands at
>> very end of each character.  Is it possible to set to threshold to the
>> middle of a character instead of very end of a character?

Let me rephrase my question.  I found it can be simplified to `click
and move point.  To make things clear, I set cursor-type to bar and
try to edit string `HELP' as shown below.

To set point in between E and L, I have to click space occupied by
letter L as shown by `***'.  However, I want to set the point by
clicking space occupied by last half of E and first half of L as shown
by `+++'.

 _   _   _____  v  _       ____  
| | | | | ____| | | |     |  _ \ 
| |_| | |  _|   | | |     | |_) |
|  _  | | |___  | | |___  |  __/ 
|_| |_| |_____| | |_____| |_|    
                ^
(now)            ********
(want)      +++++++++

Is it possible to change the sweet spot?  Now subtle difference in
location of mouse cursor when around point, changes consequence.

Re: Selection threshold with mouse

[Stefan Monnier]

> Is it possible to change the sweet spot?

Of course, it's possible, but Emacs currently does not provide
this option.  You'd have to change some of the C code for that.
Patches welcome.


        Stefan

Re: Selection threshold with mouse

[Michael Heerdegen]

Tak Kunihiro <tak.kunihiro@gmail.com> writes:

>  _   _   _____  v  _       ____  
> | | | | | ____| | | |     |  _ \ 
> | |_| | |  _|   | | |     | |_) |
> |  _  | | |___  | | |___  |  __/ 
> |_| |_| |_____| | |_____| |_|    
>                 ^
> (now)            ********
> (want)      +++++++++
>
> Is it possible to change the sweet spot?

AFAICT, it's not possible.  The character position is, at the end, taken
from the generated input event, and this can't be configured from
Elisp.

What you want could be very confusing in other situations.  When you
would click a button, the area of where the button is actually pressed
would differ from where you see the button on the screen.

For marking, I understand why one could prefer what you want, but it
would probably introduce serious inconsistencies.

Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 19 Jul 2014 21:22:28 -0400
> 
> > Is it possible to change the sweet spot?
> 
> Of course, it's possible, but Emacs currently does not provide
> this option.  You'd have to change some of the C code for that.
> Patches welcome.

We don't currently have a method to find the character to the left of
some screen coordinates (except some silly iteration that each time
sheds 1 pixel from the coordinates).  So it is not really easy to find
the character that is to the left of the given screen coordinates in a
way that will work with bidirectional display.

We could perhaps _approximate_ that by subtracting some fixed fraction
of the width of the character to the right of the mouse, but that
might mean some strange effects when the characters on the two sides
of the mouse pointer differ in size.  Maybe that's acceptable.  If
not, changing the current code that determines buffer position from
mouse coordinates would need a complete redesign (in a way I cannot
yet imagine) to support the required feature.

And yes, patches welcome.

Re: Selection threshold with mouse

[Stefan Monnier]

> We don't currently have a method to find the character to the left of
> some screen coordinates (except some silly iteration that each time
> sheds 1 pixel from the coordinates).

Can't we:
- get the posn-at-x-y.
- find the left and right pixel boundaries of the object at that posn.
- call posn-at-x-y again on those boundaries (+1 or -1)?

Hmm... so maybe it can be done in Elisp after all.

> So it is not really easy to find the character that is to the left of
> the given screen coordinates in a way that will work with
> bidirectional display.

Indeed, bidi makes it more fun.

And as pointed out by Michael, you'd probably not want this to be
enabled all the time.  IOW it probably shouldn't be controlled just by
a global variable.  Instead, specific commands should control
it individually.


        Stefan

Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 20 Jul 2014 10:37:26 -0400
> 
> > We don't currently have a method to find the character to the left of
> > some screen coordinates (except some silly iteration that each time
> > sheds 1 pixel from the coordinates).
> 
> Can't we:
> - get the posn-at-x-y.
> - find the left and right pixel boundaries of the object at that posn.
> - call posn-at-x-y again on those boundaries (+1 or -1)?

That's the "silly iteration" I had in mind: the 2nd part of this is
the tricky one, because all we know from posn-at-x-y and its ilk is
the pixel width of the object at the coordinates we pass to the
function; we don't know the coordinates where the object starts.

> And as pointed out by Michael, you'd probably not want this to be
> enabled all the time.

Actually, I disagree: every other GUI app I could try behaves like the
OP asked by default, so I see no reason for Emacs to offer an option
here.

The problem is to implement this in the first place.

Re: Selection threshold with mouse

[Stefan Monnier]

> That's the "silly iteration" I had in mind: the 2nd part of this is
> the tricky one, because all we know from posn-at-x-y and its ilk is
> the pixel width of the object at the coordinates we pass to the
> function; we don't know the coordinates where the object starts.

Hmm... but don't the display matrices contain the needed info (i.e. the
"left-pixel boundary position"), since it's needed to react to an
expose event?

> Actually, I disagree: every other GUI app I could try behaves like the
> OP asked by default, so I see no reason for Emacs to offer an option
> here.

They do, but not for all operations.  E.g. if you click on the rightmost
pixel of a hyperlink, your browser will happily consider that the click
was on the hyperlink, not on the position right after that one.


        Stefan

Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 20 Jul 2014 11:37:34 -0400
> 
> > That's the "silly iteration" I had in mind: the 2nd part of this is
> > the tricky one, because all we know from posn-at-x-y and its ilk is
> > the pixel width of the object at the coordinates we pass to the
> > function; we don't know the coordinates where the object starts.
> 
> Hmm... but don't the display matrices contain the needed info (i.e. the
> "left-pixel boundary position"), since it's needed to react to an
> expose event?

Not sure I follow (what does an expose event have to do with the issue
at hand?).  In any case, we cannot rely on glyph matrices alone,
because that would severely limit the usefulness of such an API.
E.g., you will be unable to use it in a function that is called
several times in a row, like via a numeric argument or from a keyboard
macro.  Also, some modes, like linum-mode, never let you have an
up-to-date glyph matrix.

For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but
instead simulate display.

> > Actually, I disagree: every other GUI app I could try behaves like the
> > OP asked by default, so I see no reason for Emacs to offer an option
> > here.
> 
> They do, but not for all operations.  E.g. if you click on the rightmost
> pixel of a hyperlink, your browser will happily consider that the click
> was on the hyperlink, not on the position right after that one.

I think hyperlinks are the odd one out, and not directly related to
the issue here, which is where to put point given a click, especially
in the context of highlighting the region.

Re: Selection threshold with mouse

[Stefan Monnier]

>> Hmm... but don't the display matrices contain the needed info (i.e. the
>> "left-pixel boundary position"), since it's needed to react to an
>> expose event?
> Not sure I follow (what does an expose event have to do with the issue
> at hand?).

An expose event comes with pixel coordinates and we need to respond by
drawing chars at the proper pixel positions, so we clearly need to be
able to find the chars placed at those pixel positions as well as their
pixel boundaries.

> In any case, we cannot rely on glyph matrices alone,
> because that would severely limit the usefulness of such an API.

Ah, I see.

> E.g., you will be unable to use it in a function that is called
> several times in a row, like via a numeric argument or from a keyboard
> macro.

We could make it update glyph matrices if/when needed.

> For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but
> instead simulate display.

Then I don't understand why the precise pixel position is not available.

> I think hyperlinks are the odd one out, and not directly related to
> the issue here, which is where to put point given a click, especially
> in the context of highlighting the region.

I don't know which one is the rule and which one is the exception.
I just know that the behavior should be decided on a case by case basis.


        Stefan

Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 20 Jul 2014 12:44:22 -0400
> 
> >> Hmm... but don't the display matrices contain the needed info (i.e. the
> >> "left-pixel boundary position"), since it's needed to react to an
> >> expose event?
> > Not sure I follow (what does an expose event have to do with the issue
> > at hand?).
> 
> An expose event comes with pixel coordinates and we need to respond by
> drawing chars at the proper pixel positions, so we clearly need to be
> able to find the chars placed at those pixel positions as well as their
> pixel boundaries.

Yes, but in these cases we can always err on the safe side,
i.e. redraw more than strictly needed.  We cannot use this strategy in
the case in point.

> > E.g., you will be unable to use it in a function that is called
> > several times in a row, like via a numeric argument or from a keyboard
> > macro.
> 
> We could make it update glyph matrices if/when needed.

That would make Emacs much slower than it is now, because now we never
enter redisplay as long as a command runs.  You suggest to interrupt a
running command by doing a large portion of redisplay, which will slow
us down.

> > For these reasons, posn-at-x-y etc. do not rely on glyph matrices, but
> > instead simulate display.
> 
> Then I don't understand why the precise pixel position is not available.

Because the existing methods are glyph-granular, not pixel-granular.
When you tell them to stop at pixel coordinate X, they move one
"display element" (e.g., character or image) at a time, and they stop
when they are _at_or_after_ the glyph whose pixel width includes the
coordinate X.  This doesn't reliably tell you where the glyph at X
starts on display.

These methods were never designed to return the kind of information
and with the kind of accuracy that is required for implementing the
requirement we are discussing.

Re: Selection threshold with mouse

[Stefan Monnier]

> Because the existing methods are glyph-granular, not pixel-granular.
> When you tell them to stop at pixel coordinate X, they move one
> "display element" (e.g., character or image) at a time,

But they need to keep track either of the "current pixel position" (to
compare against X) or (equivalently) of "remaining pixels until X".
So they should know the exact pixel position.


        Stefan

Re: Selection threshold with mouse

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 21 Jul 2014 10:20:25 -0400
> 
> > Because the existing methods are glyph-granular, not pixel-granular.
> > When you tell them to stop at pixel coordinate X, they move one
> > "display element" (e.g., character or image) at a time,
> 
> But they need to keep track either of the "current pixel position" (to
> compare against X) or (equivalently) of "remaining pixels until X".
> So they should know the exact pixel position.

Like I said, you cannot rely on that:

      else if ((op & MOVE_TO_X) && it->current_x >= to_x)
	{                                       ^^^^
	  result = MOVE_X_REACHED;
	  break;
	}

IOW, the exact pixel position is not always what you want in the case
in point.  All you know it's not _before_ X.

Re: Selection threshold with mouse

[Tak Kunihiro]

I am a little behind discussions.  To me for a first thought, to add
offset to click event on line 5116 of keyboard.c is a start.  I think
this is what Eli inferred.  However, I understand at the same time,
this leads mis-operation when follow hyperlink.

In regard to offset, reaction for drag (selection) matters more than
click.  If offset can be applied only for drag but click, hyperlink is
not concern.

on keyboard.c
 5114     if (part == ON_TEXT)
 5115   {
*5116    xret = XINT (x) - window_box_left (w, TEXT_AREA) + (FONT_WIDTH/2);
 5117     yret = wy - WINDOW_HEADER_LINE_HEIGHT (w);
 5118   }

Re: Selection threshold with mouse

[Eli Zaretskii]

> Date: Wed, 23 Jul 2014 09:27:01 +0900 (JST)
> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
> 
> I am a little behind discussions.  To me for a first thought, to add
> offset to click event on line 5116 of keyboard.c is a start.  I think
> this is what Eli inferred.

You cannot do that with a simple offset: it won't work in non-trivial
situations like with the first character on a display line or between
2 characters of a very different size.

Something more sophisticated and complex is required to do what you
want.

> In regard to offset, reaction for drag (selection) matters more than
> click.

I agree, but drag and click must be consistent, or else we will
confuse the users.