Re: Preserving sanity in Emacs [Re: rampant region highlighting]

[David De La Harpe Golden]

Alan Mackenzie wrote:

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

From:   martin rudalics
Subject:  Re: Enabling Transient Mark Mode by default
Date:   Thu, 21 Feb 2008 08:30:11 +0100

I don't see the  Message-Id in the archive - I don't see why the
archive couldn't present them in principle, it just doesn't.
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

> 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'? 

What's more disturbing overall, jump scrolling (it could be
rapidly smooth-scrolled given today's hardware...) or emacs taking it
upon itself to move your chosen point position?

I acknowledge that having the point always on-screen has benefits too
(though e.g. a fringe indicator could "point towards the offscreen
point" to address some concerns there...), but what if I'm just
scrolling up to look at something?  Martin's hack ensured that I can
scroll away to have a look, and the point will reliably be where I left
it when I scrolled back.

Users are used to their editors' points staying where they left them
during scrolling these days-  you talk of losing mental context, well,
if your mind is used to the editor leaving the point where you left it
rather than having to remember, then emacs' point warping is a pretty
big context disruptor. BOOM! The word "you" (as represented by your boxy
3rd person avatar, the point) were "on" isn't the word you're on
anymore, you're on some completely different sentence!  Why should
scrolling, just sliding your viewpoint around, change that? Just
adjusting the camera position in a computer game doesn't usually make
your character randomly teleport to different platforms. Scrolling a
web page form doesn't make the cursor jump from form field to form
field, etc.

I'm quite used to emacs conventions, having literally grown up using it
(okay, beginning with amiga's bundled microemacs rather than gnu emacs),
so I'm playing devils advocate to an extent here, but it's not like it'd
be impossible for emacs to support both point-ensured-onscreen and
point-can-go-offscreen behaviours _anyway_.

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

Turns out it was wrong anyway for very recent CVS emacs as Chong Yidong
just pointed out, though the overlay face change I suggested was still
informative for helping me working out what was going on, as with a
emacs rebuilt from up-to-date CVS, I could see the drag-overlay->region
transition even with t-m-m off, only happening at a different time
to t-m-m on.

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

Nope, jump-scroll back to insertion point handily addresses that. :-)