Preserving sanity in Emacs [Re: rampant region highlighting]

[Alan Mackenzie]

Hi, David!

On Sun, Apr 06, 2008 at 10:50:59PM +0100, David De La Harpe Golden wrote:

> 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.

I think we're gradually sinking deeper and deeper into a tarpit of
kludges.  Transient Mark Mode, getting shifty to mark regions, ....  I
think backing off and thinking what we're actually turning Emacs into,
before we get mired any further, would be a good idea.

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

PLEASE STOP DOING THIS!!!  This is a _mailing_ _list_, not a web forum.
Quote the Subject:, Date:, and Message-Id: at the very least, please, for
heaven's sake!  Better still, summarise what you're so aggravatingly
referring to.  Please!

I haven't gone to the trouble of looking up that web reference.

> 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.

Yes.  Point is the place on the screen you're looking at.  That's part of
the point.  At least one end of the region is on the screen.

> Other editors typically preserve point position during scrolling.
> Martin Rudalics wrote a hack to address this as shown in the above
> thread*.

So, point disappears off your screen.  How are you supposed to get back
there?  What key sequence would you suggest for the new command
`scroll-to-pont'?  The "booby trap bomb" solution implemented by lesser
editors (you touch certain random keys, like an arrow or a self-insert
key, often by accident, and the screen goes BOOOOMM!!!, completely losing
your mental context) isn't acceptable to Emacs, where minimal disturbance
of the user is an overriding principle.

> 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).

That's too complicated for me at this time of night.  Notice just how
remote all this is from the beautiful, compelling, effective simplicity
of the traditional Emacs point and mark.  Why are we in this tarpit?

> 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...

The point is the place on the screen that you're looking at, where new
text appears when you type.  Are you suggesting that when you type, you
shouldn't see anything, because "point" isn't on the screen?

> 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.

That counts as cruel and unusual treatment, and violates the Geneva
convention of hackers' rights.

> * 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...

No.

-- 
Alan Mackenzie (Nuremberg, Germany).