emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rampant region highlighting


From: David De La Harpe Golden
Subject: Re: rampant region highlighting
Date: Sun, 06 Apr 2008 22:50:59 +0100
User-agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110)

Glenn Morris wrote:
> Current CVS trunk:
> 
> ./src/emacs -Q README  --eval '(transient-mark-mode -1)'
> 
> Double-click with left mouse to select the word "tree" from "This
> directory tree...". The word "tree" is highlighted with region face.
> 
> Scroll down with mouse-wheel so that "tree" goes off the top of the
> screen.
> 
> Scroll back up with mouse-wheel.
> 
> Now the region has been extended to cover a lot more text. The further
> I scroll down initially, the more is highlighted.
> 
> 
> If this is a feature, how do I turn it off, please?
> 
> 

This is a bit disjointed, sorry:

This is likely immediately "due" to transient-mark-mode being on, but
this is IMO NOT a case against t-m-m, it's a case for making emacs point
handling during scrolling more like other editors.

How is emacs point handling during scrolling different?
See this thread:
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

Unusual in Emacs is that the point is always kept on-screen by point
warping during scrolling.  This is something of a long-standing emacs
feature really, but means that if you scroll, the region as defined by
mark->point changes shape.   Other editors typically preserve point
position during scrolling.  Martin Rudalics wrote a hack to address this
as shown in the above thread*.

When t-m-m is OFF,  point movement after a mouse selection by mouse
dragging deactivates the mouse drag overlay, so you don't notice
anything amiss, but when t-m-m is on, mouse dragging defines /and
activates/ the "real" mark-point region, and it is not deactivated by
subsequent point movements (This also ties in to the shift-selection
discussion, as it could be deactivated by unshifted movements in those
cases, say).

If you make the mouse-drag-overlay and the region use different faces
you can see better what's going on.  line 751 ish of mouse.el, change
(overlay-put ol 'face 'region) to (overlay-put ol 'face highlight)
in the (defconst mouse-drag-overlay ...)

Then try mouse selection with t-m-m on, and off.  As you can
see, what you might have thought was a transient region is actually
a sort of separate thing...

But if point position wasn't warped by scrolling, then it would all be
okay...

Note that most text editors have a transient region.  Thomas Lord's talk
of "fat cursors" notwithstanding, in practice these are implemented by
their point (cursor) defining one edge of the region in those editors,
as you can see in kde's editor (cos they don't bother hiding their line
cursor), and you can infer in GNOME's (since when you move the cursor
after demarcating a region, it moves from one end of the region) - when
something affecting the point/region happens, the area is jump-scrolled
to visibility.

* Thinking about it, mostly emacs seems to be using explicit calls to
change point position, I'm wondering is a neater solution to martins to
just take/conditionalize some of the repositioning out of the code
paths, and just allow the point to go offscreen...












reply via email to

[Prev in Thread] Current Thread [Next in Thread]