RE: [External] : Re: Moving point after character when clicking latter half of it

[Drew Adams]

> > > I personally find this an anti-feature.
> >
> > I understand that the feature would be optional.
> > Still, I tend to agree with you (Benjamin).
> >
> > I can imagine editing text with a very large font
> > (I use larger fonts as time goes by...), and in
> > that case I'd see better which half of a char I
> > was clicking.  IOW, that would allow me to take
> > advantage of such half-char clicking.
> >
> > Nevertheless, I don't really see what the feature
> > adds.  You can already precisely click here or
> > there to place point or select whichever starting
> > (with (mouse-1) or ending (with mouse-3) char you
> > like.
> 
> It allows people to not have to shift mental models when interacting with
> GUI Emacs vs. other GUI applications deadling with text.

Thanks for making that explicit.

So that's it?  Whether it's a useful feature
in its own right or not?

So this would be analogous to Emacs's optional
support for CUA, etc.  If optional, OK by me,
but I'd like to see the doc for it point this
out explicitly: that other than perhaps giving
you behavior you might be used to from outside
Emacs, this behavior provides no advantage.
And it introduces the disadvantage of making
you distinguish the click position even more
precisely (smaller click radius, to get the
given effect).

> > It seems like all this would do is to halve the
> > distance between such click positions - in essence
> > _requiring_ even better visibility/sensing of the
> > positions.
> 
> Clicking the latter half of glyph n, as well as the first half of glyph
> n+1 would result in the point being but between glyph n and n+1. The total
> length of the selection range remains the same, it is only shifted half a 
> glyph
> to the left.

That description sounds like a (less-clear)
repeat of what I said.

> I ask that you try my poc patch out before
> making such strong claims.

I didn't make any claim.  I tried to imagine
the behavior, based on your description.

I don't build Emacs, so I won't be trying
your C patch.

> > And thus requiring even a closer zoom
> > of the text.  IOW, instead of having to feel/find
> > the start or end of a char you'd have to do that
> > for the start, the end, and the middle.
> >
> > Sounds like multiplying things unnecessarily,
> > making poor Occam roll over in the grave.  What,
> > exactly, is the improvement or use case?  Could
> > someone please describe a scenario where this
> > would actually help someone more?
> 
> The use case is described in my very first post,

No, I don't think so, if you intend the
use to be more than providing the behavior
you see outside Emacs: click left or right
of the center line of a char, rather than
clicking left or right of the start of a
char.

(It's true that that's the same zoom or
resolution requirement.  But I'd argue
that the start of a char may be generally
easier to discern than its midline.)

> but I'll go into more detail:
> Every other GUI application dealing with text I'm using already works this
> way, including e.g. KMail (which I'm typing this email in). When using
> emacs, I have to switch my mental model from "normal GUI application" to 
> "Emacs
> GUI" and still often misclick due to Emacs' behaving differently from other 
> GUI
> applications.

That repeats what you said in your first
mail: the aim is to provide the same
behavior you see outside Emacs.  Nothing
wrong with offering that option, IMO.

> That being said, if there's wide opposition of this being included in
> Emacs, I'll maintain it as a downstream patch as Emacs' current default 
> behavior,
> to me, is unacceptable.

Please reread what I wrote.  I, for one,
didn't express any opposition to such an
optional feature being added.  But if the
only benefit is matching non-Emacs behavior
then let's please make that clear in the
doc.  IOW, if this is analogous to, say,
CUA support, then - just as we do for CUA
support - let's make that clear.

I'm guessing there will be others who also
appreciate having Emacs match outside
click behavior, in which case this is a
good thing.  To me, on its own, midline as
frontier is less desirable than char start
(or end), as it's less discernible.  But
matching outside behavior might be more
important for some users (such as you).

Thanks for making clear what this is about.
It gets my vote.  (I take your word that
the described behavior is a common one
outside Emacs.)