rampant region highlighting

rampant region highlighting

[Glenn Morris]

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?

Re: rampant region highlighting

[David De La Harpe Golden]

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

Re: rampant region highlighting

[Glenn Morris]

David De La Harpe Golden wrote:

>> ./src/emacs -Q README  --eval '(transient-mark-mode -1)'
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is likely immediately "due" to transient-mark-mode being on, but

If it is, it shouldn't be.

Re: rampant region highlighting

[David De La Harpe Golden]

Glenn Morris wrote:
> David De La Harpe Golden wrote:
> 
>>> ./src/emacs -Q README  --eval '(transient-mark-mode -1)'
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> This is likely immediately "due" to transient-mark-mode being on, but
> 
> If it is, it shouldn't be.

Oops. Idiocy on my part, misread that - of course t-m-m
is on by default recently, why would you be turning it on...

- but what you described _does_ sound like "normal" behaviour when t-m-m
is _on_...

Re: rampant region highlighting

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

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

Not true in Emacs 23.

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

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

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

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

As I explained elsewhere on this thread, this is really an issue of
mouse selection, not transient mark mode.  Since Emacs 22 or even
earlier, mouse selection has required somewhat intricate machinery to
DTRT (see mouse.el).  The recent change to the tmm-only mechanism
necessitates some tweaking of this machinery, that's all.

If you want to avoid tmm entirely, you could, y'know, avoid using the
mouse...

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

[Alan Mackenzie]

Hi, Yidong!

On Sun, Apr 06, 2008 at 07:01:51PM -0400, Chong Yidong wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> If you want to avoid tmm entirely, you could, y'know, avoid using the
> mouse...

Yes, of course.  And I will.

But that's not the point.  I _care_ deeply about Emacs, like everybody
else on this mailing list.  Not just about how you can configure it, but
how it appears to the new user.  I want the hacker who takes up Emacs
23, or 24, or 25, to get that same "Eureka!" feeling that I got way back
when.  The feeling that Emacs is _different_, that it's _right_, that
it's _special_ - that when you ask a question, the answer is "yes".

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Glenn Morris]

Alan Mackenzie wrote:

> The feeling that Emacs is _different_, that it's _right_, that it's
> _special_ - that when you ask a question, the answer is "yes".

Do you and Emacs need to be alone right now? ;)

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

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

[Lennart Borgman (gmail)]

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

And C-x C-x too?

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

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:
>>> 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. :-)
> 
> And C-x C-x too?

Not 100% sure what you mean:

You could have some commands cause a display to jump back to point,
others not - as Martin's scroll-restore.el implemented.  I imagine
C-x C-x would be one of the ones that should warp the display to
wherever the point ends up.

C-x C-x as a "workaround" (or perhaps "usual emacsy way to do it"!) in
existing emacs for scrolling warping the point is quite relevant -
obviously, if you just have the slightest foresight and get into the
habit of setting a mark before ever scrolling away into the wide blue
yonder*, then you can always just warp back to the precise position the
point was at before you scrolled  with C-u C-SPC and C-x C-x as
appropriate to reestablish your pre-scrolling point and mark positions.
(of course, that kinda leads into Thomas Lord's point about emacs
conflating marking and region-selecting mechanisms...  Aside: I wonder
if the mark ring would be more appreciated as a bookmarking mechanism
if it were visually represented, maybe little display blips.)

* Why not just open another frame/window on the same buffer?  Why not
indeed?

visual marks [was: Preserving sanity in Emacs [Re: rampant region highlighting]

[Drew Adams]

> Aside: I wonder
> if the mark ring would be more appreciated as a bookmarking mechanism
> if it were visually represented, maybe little display blips.)

FWIW: There are a couple libraries on Emacs Wiki that are related to that idea: 

. http://www.emacswiki.org/cgi-bin/wiki/VisibleBookmarks (bookmarks, not marks,
but could serve as inspiration)

. http://www.emacswiki.org/cgi-bin/wiki/VisibleMark - highlights only the
(current) mark, not multiple marks on mark-ring.

Re: visual marks [was: Preserving sanity in Emacs [Re: rampant region highlighting]

[David De La Harpe Golden]

Drew Adams wrote:
>> Aside: I wonder
>> if the mark ring would be more appreciated as a bookmarking mechanism
>> if it were visually represented, maybe little display blips.)
> 

> . http://www.emacswiki.org/cgi-bin/wiki/VisibleMark - highlights only the
> (current) mark, not multiple marks on mark-ring.

Cool, should have thought to check there...

It can highlight multiple marks, if you adjust visible-mark-max to =
mark-ring-max you get all marks.  Quite nice as it is, even though it's
very simple - though when it's showing multiple marks, you'd definitely
really want the current mark to be specially indicated unless you've
also got t-m-m highlighting on (which I do of course, but it would also
be useful as an alternative to t-m-m highlighting).

The mark ring marks of course aren't necessarily in display order,
they're in the order you set them, so without any visual differentiation
between the different mark ring mark highlights, you can't really tell
from the display which mark you'll end up at when you hit C-u C-SPC, you
just know it's one of 'em - once I could see the marks, I found myself
wanting "jump to next/prev mark relative to point, in display order"
more than "pop mark".

Re: visual marks [was: Preserving sanity in Emacs [Re: rampant region highlighting]

[Lennart Borgman (gmail)]

David De La Harpe Golden wrote:
> The mark ring marks of course aren't necessarily in display order,
> they're in the order you set them, so without any visual differentiation
> between the different mark ring mark highlights, you can't really tell
> from the display which mark you'll end up at when you hit C-u C-SPC, you
> just know it's one of 'em - once I could see the marks, I found myself
> wanting "jump to next/prev mark relative to point, in display order"
> more than "pop mark".


Interesting, the visual clues are very powerful and I guess they can 
twist your memory. Maybe it is hard to keep a more abstract view of the 
marks simultaneously?

Re: visual marks [was: Preserving sanity in Emacs [Re: rampant region highlighting]

[David De La Harpe Golden]

Lennart Borgman (gmail) wrote:
> David De La Harpe Golden wrote:
>> The mark ring marks of course aren't necessarily in display order,
>> they're in the order you set them, so without any visual differentiation
>> between the different mark ring mark highlights, you can't really tell
>> from the display which mark you'll end up at when you hit C-u C-SPC, you
>> just know it's one of 'em - once I could see the marks, I found myself
>> wanting "jump to next/prev mark relative to point, in display order"
>> more than "pop mark".
> 
> 
> Interesting, the visual clues are very powerful and I guess they can
> twist your memory. Maybe it is hard to keep a more abstract view of the
> marks simultaneously?

Not sure I ever really remembered the order I placed the marks on the
mark ring beyond 1 or 2 though, just that I did add a mark, so I just
kept hitting C-u C-SPC  until I was where I wanted (the ring being a
ring, that always works, at least until you make so many marks that old
marks start disappearing from the finite-size ring...).

RE: visual marks [was: Preserving sanity in Emacs [Re: rampant region highlighting]

[Drew Adams]

> The mark ring marks of course aren't necessarily in display order,
> they're in the order you set them, so without any visual 
> differentiation between the different mark ring mark highlights,
> you can't really tell from the display which mark you'll end up
> at when you hit C-u C-SPC, you just know it's one of 'em - once
> I could see the marks, I found myself wanting "jump to next/prev
> mark relative to point, in display order" more than "pop mark".

OT, FWIW: 

In Icicles, you can "see" the list of marks (the text of their lines) as a set
of completions in *Completions*. And you can sort them in various ways (so you
can access them in various orders). By default, they are in buffer order
(position), not mark-ring order.

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

[Robert J. Chassell]

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

And some are not connected to the Internet all the time and do not
read items on the Web.  Often, they cannot read such items.  When past
remarks are important, please summarize them briefly in your
electronic mail message.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

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

[Alan Mackenzie]

Hi, David!

On Mon, Apr 07, 2008 at 12:50:42AM +0100, David De La Harpe Golden wrote:
> 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

Thanks!  Sorry, I've not been able to reply earlier.  My ISP's mail
server crashed, and I was having to read the conversation via the HTML
archive.  ;-)

> 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

Possibly because the Message-Id offers the server name to harvesting
spammers.

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

Jump scrolling.  Emacs never autonomously move point.  The user does.

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

The functions you're talking about are fulfilled in Emacs by the mark,
not the point.  I frequently scoll a bit to look at things.  Then I
scroll back to get where I was, unless I want to stay where I've got to.

The point is, by your mechanism, having scrolled away from point (leaving
point off the screen), how do you then indicate where on the screen you
want point to be set to, and how do you set point there?  The general
Emacs answer is that you indicate a position by setting point.  Hmm.
We're going round in circles.  (You're presumably going to say "you click
the mouse to set point."  This violates the Emacs principle that
everything must be doable without a mouse.)

> Users are used to their editors' points staying where they left them
> during scrolling these days-

Emacs users aren't.  Are you arguing that we should change Emacs merely
to follow the fashion of the day?

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

Not that big.  For a start, you notice it before you've gone very far.
Pressing <page down> _always_ takes point away from where it was.  With
LCD[*] editors, sometimes pressing 'a' will teleport you to far off
place, sometimes not.  This is one more item of state you've got to
retain in your head with an LCD editor - whether a random key will cause
a context explosion or not.  This is an example of Emacs's instrinsic
superiority.

[*] "lowest common denominator"

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

Because the purpose of point in Emacs is to indicate where you're doing
something.  Here, "doing" includes "looking at".  The thing that
remembers a position to go back to is the mark - This is deliberate
design, as evidenced by M->, C-s, and friends setting the mark.

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

In a computer game, say a flight simulator, moving the joystick doesn't
suddenly jerk the scenery back to the place where you last moved it.  As
for web pages, they are a user interface disaster, practically for
anything.

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

I think it would be fairly close to impossible.  The rule that point is
always on the screen is so deeply embedded, mostly implicitly, that you
might as well write a new editor core than try and adapt the existing
Emacs.

[ .... ]

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

So, how do you move point rapidly to somewhere else in a buffer?  There's
not much point using the <page down> key, if the moment you try to do
something you're jump-scrolled back to where you started.  (Remember,
there might not be a usable mouse, and the user might not want to have to
use one even if there is.)

It was such a bloody relief to get away from that misfeature when I came
to Emacs. 

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
>> 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.
> 
> The functions you're talking about are fulfilled in Emacs by the mark,
> not the point.  I frequently scoll a bit to look at things.  Then I
> scroll back to get where I was, unless I want to stay where I've got to.
> 
> The point is, by your mechanism, having scrolled away from point (leaving
> point off the screen), how do you then indicate where on the screen you
> want point to be set to, and how do you set point there?  The general
> Emacs answer is that you indicate a position by setting point.  Hmm.
> We're going round in circles.  (You're presumably going to say "you click
> the mouse to set point."  This violates the Emacs principle that
> everything must be doable without a mouse.)

Another way to look at this would perhaps be too:

- Regard the buffer in a kind of read-only state when the window-point 
is outside the window ;-)

- If a command concerns the current buffer and it is not a scroll 
command then just bring back window-point to where it was inside the 
window before scrolling. Don't do more (ie do not execute the command), 
just tell that point was outside of the window therefore have been 
brought back.

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

[Alan Mackenzie]

Morning, Lennart!

On Mon, Apr 07, 2008 at 11:37:09PM +0200, Lennart Borgman (gmail) wrote:
> Alan Mackenzie wrote:
> >>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.

> >The functions you're talking about are fulfilled in Emacs by the mark,
> >not the point.  I frequently scoll a bit to look at things.  Then I
> >scroll back to get where I was, unless I want to stay where I've got to.

> >The point is, by your mechanism, having scrolled away from point (leaving
> >point off the screen), how do you then indicate where on the screen you
> >want point to be set to, and how do you set point there?  The general
> >Emacs answer is that you indicate a position by setting point.  Hmm.
> >We're going round in circles.  (You're presumably going to say "you click
> >the mouse to set point."  This violates the Emacs principle that
> >everything must be doable without a mouse.)

> Another way to look at this would perhaps be to:

> - Regard the buffer in a kind of read-only state when the window-point 
> is outside the window ;-)

Hmm.

> - If a command concerns the current buffer and it is not a scroll 
> command then just bring back window-point to where it was inside the 
> window before scrolling.

Sorry, I can't parse that.  What is "window-point"?  Does "where it was"
refer to the buffer position, or the position on the screen relative to
the top of the window?

> Don't do more (ie do not execute the command), just tell that point was
> outside of the window therefore have been brought back.

Don't execute the command?  Yikes!!  Yet one more frivolous item of state
to clog up one's brain.  And a few million "..., except when ...."s to
clog up commands' doc strings.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> Morning, Lennart!

Morning, Alan!

> On Mon, Apr 07, 2008 at 11:37:09PM +0200, Lennart Borgman (gmail) wrote:
>> Alan Mackenzie wrote:
>>>> 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.
> 
>>> The functions you're talking about are fulfilled in Emacs by the mark,
>>> not the point.  I frequently scoll a bit to look at things.  Then I
>>> scroll back to get where I was, unless I want to stay where I've got to.
> 
>>> The point is, by your mechanism, having scrolled away from point (leaving
>>> point off the screen), how do you then indicate where on the screen you
>>> want point to be set to, and how do you set point there?  The general
>>> Emacs answer is that you indicate a position by setting point.  Hmm.
>>> We're going round in circles.  (You're presumably going to say "you click
>>> the mouse to set point."  This violates the Emacs principle that
>>> everything must be doable without a mouse.)
> 
>> Another way to look at this would perhaps be to:
> 
>> - Regard the buffer in a kind of read-only state when the window-point 
>> is outside the window ;-)
> 
> Hmm.
> 
>> - If a command concerns the current buffer and it is not a scroll 
>> command then just bring back window-point to where it was inside the 
>> window before scrolling.
> 
> Sorry, I can't parse that.  What is "window-point"?  Does "where it was"
> refer to the buffer position, or the position on the screen relative to
> the top of the window?

window-point? Just a little joke. We are talking about the buffer point 
in the current window. The function window-point returns that. 
window-point may in the situation pictured above still return the point, 
but it is outside the window ... (or maybe it could return nil?)

"where it was": I meant the position on the screen.

>> Don't do more (ie do not execute the command), just tell that point was
>> outside of the window therefore have been brought back.
> 
> Don't execute the command?  Yikes!!  Yet one more frivolous item of state
> to clog up one's brain.

Yes, I think that must be the price if you always want to be able to see 
what you are doing. (This could be made an option - perhaps.)

> And a few million "..., except when ...."s to
> clog up commands' doc strings.

Not much to add there I think. A note somewhere about scrolling is all I 
can see is really needed.

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

[Richard Stallman]

    >> I acknowledge that having the point always on-screen has benefits too

The idea of changing this is a non-starter, so let's please
not spend time arguing about it.

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

[David De La Harpe Golden]

Alan Mackenzie wrote:

> With LCD[*] editors, sometimes pressing 'a' will teleport you to far
> off place, sometimes not.

"a" is still always inserted where the point is...

> Not that big.  For a start, you notice it before you've gone very far.
> Pressing <page down> _always_ takes point away from where it was. 

> So, how do you move point rapidly to somewhere else in a buffer?  There's
> not much point using the <page down> key, if the moment you try to do
> something you're jump-scrolled back to where you started.  

That just depends on whether you conceptualise a "page down" keypress as
"move the point down by a page, and scroll to follow" or "scroll the
viewport down (or up) by a page".

Actually, both would be possible from the keyboard- in most X11 terminal
emulators, shift-pgup/dn scrolls without moving the point.  (though I
guess that should be for shift-selection by pages in emacs, and
M-pgdn/up for scroll-other-window is handy.  C-pgdn/up is taken too, for
scroll-left/right (not the most intuitive binding, that, byt hey, I tend
to use line wrapping anyway), but that really only leaves C-M-pgdn/up
for page-up-leaving-point-where-it-is.

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

[Alan Mackenzie]

Morning, David!

On Tue, Apr 08, 2008 at 12:07:44AM +0100, David De La Harpe Golden wrote:
> Alan Mackenzie wrote:

> > With LCD[*] editors, sometimes pressing 'a' will teleport you to far
> > off place, sometimes not.

> "a" is still always inserted where the point is...

... and sometimes has the side-effect of completely overwriting the
screen with the text from a different part of the buffer, sometimes not.

> > So, how do you move point rapidly to somewhere else in a buffer?
> > There's not much point using the <page down> key, if the moment you
> > try to do something you're jump-scrolled back to where you started.  

> That just depends on whether you conceptualise a "page down" keypress
> as "move the point down by a page, and scroll to follow" or "scroll the
> viewport down (or up) by a page".

No it doesn't.  You should be a politician.  ;-)  The key sequences you
need depend on what has been implemented, not the conceptualisation which
gave rise to that implementation.  I want to scroll with <page down> and
then type text at the place I've scrolled to.  How?

In Emacs, point is where you do things.  To indicate where something is
to be done, you put point there.  So you need to put point at the
position to indicate where you want to put point.  I don't think you've
answered this, er, point in what follows.

> Actually, both would be possible from the keyboard- in most X11 terminal
> emulators, shift-pgup/dn scrolls without moving the point.

AArrrggghhhh!  That's meaningless without saying whether the "moving" is
relative to the buffer position or the visible position on the screen.
I'm guessing you're meaning "relative to the screen".

> (though I guess that should be for shift-selection by pages in emacs,
> and M-pgdn/up for scroll-other-window is handy.  C-pgdn/up is taken
> too, for scroll-left/right (not the most intuitive binding, that, byt
> hey, I tend to use line wrapping anyway), but that really only leaves
> C-M-pgdn/up for page-up-leaving-point-where-it-is.

Exactly!  Bindings involving arrow keys and scrolling keys are precious.

So lets get back to the point.  Do you have a mechanism, not involving
the mouse, by which, having scrolled and left point not on the visible
part of the buffer in the window, you can indicate a position to move
point to and then move it there?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[David De La Harpe Golden]

Alan Mackenzie wrote:
> Morning, David!

Morning. Ish. (I'm largely nocturnal by default)

>>> So, how do you move point rapidly to somewhere else in a buffer?
>>> There's not much point using the <page down> key, if the moment you
>>> try to do something you're jump-scrolled back to where you started.  
> 
>> That just depends on whether you conceptualise a "page down" keypress
>> as "move the point down by a page, and scroll to follow" or "scroll the
>> viewport down (or up) by a page".
> 
> No it doesn't.  You should be a politician.  ;-)  The key sequences you
> need depend on what has been implemented, not the conceptualisation which
> gave rise to that implementation.  I want to scroll with <page down> and
> then type text at the place I've scrolled to.  How?
> 

Maybe I wasn't clear:

PgUp/Dn would still move the point around the buffer, as I would
consider them analogous to cursor keys (cursor keys also move the point
around the buffer in emacs - and when they move the point to somewhere
currently offscreen, emacs scrolls the viewport to bring it back on...).
 i.e. PgUp/Dn means "move the point one page up or down"

C-M-Pgdown mightn't move the point, but only scroll the viewport.


viewport here is ancient amiga terminology, no idea what the youngsters
call it, I mean in a (perhaps virtual) 2D plane, the viewport is the
"window" onto the plane that is viewed.

+---Plane=----------------+
|                         |
|    +-VP-+               |
|    |    |               |
|    +----+               |
|                         |
|                         |
+-------------------------+


2D scrolling is moving a viewport around a 2D plane,
or equivalently, moving the 2D plane around beneath the viewport.

Note that I mean that's the model that is desired - in programming
terms, the 2D plane might be an entirely fictional entity, contents of
the viewport JIT rendered into place.  That's AFAIK what emacs basically
does, the current viewport position over the buffer being "window-start".

>> (though I guess that should be for shift-selection by pages in emacs,
>> and M-pgdn/up for scroll-other-window is handy.  C-pgdn/up is taken
>> too, for scroll-left/right (not the most intuitive binding, that, byt
>> hey, I tend to use line wrapping anyway), but that really only leaves
>> C-M-pgdn/up for page-up-leaving-point-where-it-is.
> 
> Exactly!  Bindings involving arrow keys and scrolling keys are precious.
> 
> So lets get back to the point.  Do you have a mechanism, not involving
> the mouse, by which, having scrolled and left point not on the visible
> part of the buffer in the window, you can indicate a position to move
> point to and then move it there?


Not as such, but one could easily be imagined, like a keypress. However,
I think you've missed the point - if I'm scrolling with the mouse wheel
or scroll bar, my hand is already on the mouse, so clicking is hardly
a chore, and mouse scrolling can thus be a viewport scroll by default,
with a click to summon the point to the current viewport location.

If I'm "scrolling" with PgUp/Dn, by the above, the "scrolling" is just a
side effect, the PgUp/Dn can be conceptualised as /moving the point/ up
or down by one page in the buffer, and emacs then happens to autoscroll
the viewport to bring the point back onscreen.

So a keybinding for moving the point onscreen to the current viewport
position would only be "needed" for the C-M-pgdn/up (just calling it
that for example purposes) case, to be equivalent to the mouse click.
  And I don't think the need is  particularly strong, because it would
only apply when you decide to C-M-pgdn/up to gawk at something, but
then change your mind and want to move the point to it - when
you start out wanting to move the point up and down by pages, you just
PgUp/PgDn.

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

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

> PgUp/Dn would still move the point around the buffer, as I would
> consider them analogous to cursor keys (cursor keys also move the
> point around the buffer in emacs - and when they move the point to
> somewhere currently offscreen, emacs scrolls the viewport to bring it
> back on...).  i.e. PgUp/Dn means "move the point one page up or down"
>
> C-M-Pgdown mightn't move the point, but only scroll the viewport.
>
> viewport here is ancient amiga terminology, no idea what the
> youngsters call it, I mean in a (perhaps virtual) 2D plane, the
> viewport is the "window" onto the plane that is viewed.

This isn't going to be implemented in the forseeable future, and there
are more urgent things to work on.  Let's stop wasting bandwidth on
this.

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

[Mathias Dahl]

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

May I suggest you have a look at unscroll.el, which lets you
"unscroll" back to where you were, should you by mistake or on purpose
scroll far far away in the buffer:

;;; Commentary:

;; To use: (require 'unscroll) in your .emacs.

;; This file uses "advice" to modify the scrolling commands such that
;; the screen appearance is preserved at the start of each series of
;; scrolls.  Ever press C-v C-v C-v when you meant C-b C-b C-b?
;; That's what this is meant to remedy.

;; After scrolling (intentionally or otherwise), you can restore the
;; display with M-x unscroll RET, which I like to bind to C-M-v using
;; (define-key global-map "\C-\M-v" 'unscroll).

http://se.aminet.net/pub/gnu/emacs-lisp/incoming/unscroll.el

When I was new to Emacs it happened from time to time that I used some
movement command by mistake. I would have needed this hack then.
Nowadays I don't have that problem anymore and if it happens C-u C-SPC
often takes me close to where I was. Still, I like the idea and it
would be neat if it were built-in.

Re: rampant region highlighting

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

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

I guess mwheel-scroll should unconditionally deactivate the mark when
tmm is active.  I'll take a look.

Re: rampant region highlighting

[Glenn Morris]

Chong Yidong wrote:

>> ./src/emacs -Q README  --eval '(transient-mark-mode -1)'
[...]
> I guess mwheel-scroll should unconditionally deactivate the mark when
> tmm is active.  I'll take a look.

If `(transient-mark-mode -1)' isn't enough to completely disable tmm,
then please tell we what is. I already have this from some time back:

(defadvice set-mark-command (after no-bloody-t-m-m activate)
  "Prevent consecutive marks activating bloody `transient-mark-mode'."
  (if (eq transient-mark-mode 'lambda)
      (setq transient-mark-mode nil)))

(defadvice mouse-set-region-1 (after no-bloody-t-m-m activate)
  "Prevent mouse commands activating bloody `transient-mark-mode'."
  (if (eq transient-mark-mode 'only)
      (setq transient-mark-mode nil)))

Re: rampant region highlighting

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> If `(transient-mark-mode -1)' isn't enough to completely disable tmm,
> then please tell we what is. I already have this from some time back:
>
> (defadvice set-mark-command (after no-bloody-t-m-m activate)
>   "Prevent consecutive marks activating bloody `transient-mark-mode'."
>   (if (eq transient-mark-mode 'lambda)
>       (setq transient-mark-mode nil)))
>
> (defadvice mouse-set-region-1 (after no-bloody-t-m-m activate)
>   "Prevent mouse commands activating bloody `transient-mark-mode'."
>   (if (eq transient-mark-mode 'only)
>       (setq transient-mark-mode nil)))

This is a temporary transient-mark-mode (`only' mode) which is set by
the mouse.  This was recently changed to make the temporary mark less
fragile, so that it persists for some commands instead of deactivating
after the next command.  As a result, there are some commands that now
need to turn off the temporary tmm explicitly.

Re: rampant region highlighting

[Stefan Monnier]

> If `(transient-mark-mode -1)' isn't enough to completely disable tmm,
> then please tell we what is. I already have this from some time back:

> (defadvice set-mark-command (after no-bloody-t-m-m activate)
>   "Prevent consecutive marks activating bloody `transient-mark-mode'."
>   (if (eq transient-mark-mode 'lambda)
>       (setq transient-mark-mode nil)))

> (defadvice mouse-set-region-1 (after no-bloody-t-m-m activate)
>   "Prevent mouse commands activating bloody `transient-mark-mode'."
>   (if (eq transient-mark-mode 'only)
>       (setq transient-mark-mode nil)))

I'm surprised: if you don't like transient-mark-mode, why didn't you write:

(defadvice set-mark-command (after no-bloody-t-m-m activate)
  "Prevent consecutive marks activating bloody `transient-mark-mode'."
  (if transient-mark-mode (setq transient-mark-mode nil)))

(defadvice mouse-set-region-1 (after no-bloody-t-m-m activate)
  "Prevent mouse commands activating bloody `transient-mark-mode'."
  (if transient-mark-mode (setq transient-mark-mode nil)))

Or even do away with the `if'?  That would not suffer from the problem
you're seeing.


        Stefan

Re: rampant region highlighting

[Glenn Morris]

Stefan Monnier wrote:

> I'm surprised: if you don't like transient-mark-mode, why didn't you write:
[...]
>   (if transient-mark-mode (setq transient-mark-mode nil)))

Perhaps one day in a fit of madness I will actually want to enable t-m-m...

I should change it to:

(or (eq transient-mark-mode t) (setq transient-mark-mode nil))

> Or even do away with the `if'?  That would not suffer from the problem
> you're seeing.

Shouldn't we be criticising the fact that I have to jump through such
hoops at all, not the fact that I made them square? It's clearly a
very polarizing feature, so a standard way to totally disable it would
seem a good idea.

Re: rampant region highlighting

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Stefan Monnier wrote:
>
>> I'm surprised: if you don't like transient-mark-mode, why didn't you write:
> [...]
>>   (if transient-mark-mode (setq transient-mark-mode nil)))
>
> Perhaps one day in a fit of madness I will actually want to enable t-m-m...
>
> I should change it to:
>
> (or (eq transient-mark-mode t) (setq transient-mark-mode nil))
>
>> Or even do away with the `if'?  That would not suffer from the problem
>> you're seeing.
>
> Shouldn't we be criticising the fact that I have to jump through such
> hoops at all, not the fact that I made them square? It's clearly a
> very polarizing feature, so a standard way to totally disable it would
> seem a good idea.

You mean something like this?

(global-unset-key [down-mouse-1])
(global-unset-key [drag-mouse-1])

Re: rampant region highlighting

[Glenn Morris]

Chong Yidong wrote:

<elsewhere>
> If you want to avoid tmm entirely, you could, y'know, avoid using
> the mouse...

> You mean something like this?
>
> (global-unset-key [down-mouse-1])
> (global-unset-key [drag-mouse-1])

I avoided rising to the bait the first time, but no, I don't mean
something like that. Is that really your policy, or are you joking?
I'm either annoyed or not amused, accordingly.

(setq transient-mark-mode 'never)

would be an acceptable solution.

Re: rampant region highlighting

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>> (global-unset-key [down-mouse-1])
>> (global-unset-key [drag-mouse-1])
>
> I avoided rising to the bait the first time, but no, I don't mean
> something like that. Is that really your policy, or are you joking?
> I'm either annoyed or not amused, accordingly.
>
> (setq transient-mark-mode 'never)
>
> would be an acceptable solution.

I suppose I don't understand what you're trying to do.  What you seem to
be saying is that you want a way to disable all occurrences of active
region highlighting, even the momentary highlighting induced by dragging
the mouse (or double-clicking the mouse).  In that case, why not avoid
dragging or double-clicking the mouse?

Re: rampant region highlighting

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> I suppose I don't understand what you're trying to do.  What you seem to
> be saying is that you want a way to disable all occurrences of active
> region highlighting, even the momentary highlighting induced by dragging
> the mouse (or double-clicking the mouse).  In that case, why not avoid
> dragging or double-clicking the mouse?

Also, if you want to disable all instances of region highlighting, what
should mouse dragging and mouse double-clicking do?  Do you want them to
be no-ops?

If this is something people really desire, we could package the relevant
mouse bindings into a minor mode, so that turning off the minor mode
disables the mouse commands.  But that just seems strange to me.

Re: rampant region highlighting

[Glenn Morris]

Chong Yidong wrote:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> I suppose I don't understand what you're trying to do.  What you seem to
>> be saying is that you want a way to disable all occurrences of active
>> region highlighting, even the momentary highlighting induced by dragging
>> the mouse (or double-clicking the mouse).  In that case, why not avoid
>> dragging or double-clicking the mouse?
>
> Also, if you want to disable all instances of region highlighting, what
> should mouse dragging and mouse double-clicking do?  Do you want them to
> be no-ops?

I don't want to disable all instances of region highlighting.
I basically want it to act exactly like it did before tmm was thought of.

I have forgotten what the mouse-set-region-1 advice was supposed to do
(it dates from some time ago). I was clearly trying to disable
whatever the tmm stuff in mouse-set-region-1 does, but I've forgotten
what that might be.

I know what the set-mark-command advice was supposed to do: stop
consecutive marks briefly turning on tmm. So I do personally think
there should be an easier way to disable that feature, but that may be
a very minority opinion not worth bothering about.

It's possible the mouse-set-region-1 advice was just an allergic
reaction to anything that seemed to do with transient-mark-mode, and
serves no useful purpose. So don't worry about it.

Re: rampant region highlighting

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> 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.
>
> I guess mwheel-scroll should unconditionally deactivate the mark when
> tmm is active.  I'll take a look.

I think the way to handle this is to make mouse wheel scrolling preserve
any temporarily active region iff point isn't moved.  Does this patch
give good results for you?

*** trunk/lisp/mwheel.el.~1.44.~	2008-01-08 15:44:42.000000000 -0500
--- trunk/lisp/mwheel.el	2008-04-07 00:26:48.000000000 -0400
***************
*** 190,195 ****
--- 190,201 ----
                       (prog1
                           (selected-window)
                         (select-window (mwheel-event-window event)))))
+ 	 (buffer (window-buffer curwin))
+ 	 ;; If there is a temporarily active region, we may want to
+ 	 ;; deactivate it.  Save the original value of point.
+ 	 (opoint (with-current-buffer buffer
+ 		   (when (eq (car-safe transient-mark-mode) 'only)
+ 		     (point))))
           (mods
  	  (delq 'click (delq 'double (delq 'triple (event-modifiers event)))))
           (amt (assoc mods mouse-wheel-scroll-amount)))
***************
*** 224,230 ****
                     ;; Make sure we do indeed scroll to the end of the buffer.
                     (end-of-buffer (while t (scroll-up)))))
  		(t (error "Bad binding in mwheel-scroll"))))
!       (if curwin (select-window curwin))))
    (when (and mouse-wheel-click-event mouse-wheel-inhibit-click-time)
      (if mwheel-inhibit-click-event-timer
  	(cancel-timer mwheel-inhibit-click-event-timer)
--- 230,240 ----
                     ;; Make sure we do indeed scroll to the end of the buffer.
                     (end-of-buffer (while t (scroll-up)))))
  		(t (error "Bad binding in mwheel-scroll"))))
!       (if curwin (select-window curwin)))
!     (when opoint
!       (with-current-buffer buffer
! 	(when (/= opoint (point))
! 	  (deactivate-mark)))))
    (when (and mouse-wheel-click-event mouse-wheel-inhibit-click-time)
      (if mwheel-inhibit-click-event-timer
  	(cancel-timer mwheel-inhibit-click-event-timer)

Re: rampant region highlighting

[Glenn Morris]

Chong Yidong wrote:

> I think the way to handle this is to make mouse wheel scrolling preserve
> any temporarily active region iff point isn't moved.  Does this patch
> give good results for you?

Seems to work, thanks.

Re: rampant region highlighting

[Thomas Lord]

Glenn Morris wrote:
> If this is a feature, how do I turn it off, please?
>
>
>   


Emacs is built that way and the key decisions are wedged in
there good and tight but people tend to overestimate those things
and then constrain themselves to perpetuate the harm done.

But: It's not hard to fix.  It's easy if you try.

-t