[Top][All Lists]

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

Re: Proposal to change cursor appearance to indicate region activation

From: Kelly Dean
Subject: Re: Proposal to change cursor appearance to indicate region activation
Date: Thu, 22 Jan 2015 05:41:15 +0000

Drew Adams wrote on 20 Apr 2013:
> A block cursor itself is the cause of any such confusion, I think, regardless 
> of
> inverse video.  It sits on top of a char, so a priori it is ambiguous whether
> the region includes that character or not.

Right. That's why it makes sense to not use a block cursor when visually 
indicating the region.

> And a moment's thought would anyway reach the conclusion that choosing to
> include the char under the cursor would mean that the active region always has
> at least one char (the one under the cursor).

Right. That would be a bad design, which is why Emacs excludes that char. Using 
a bar cursor to visually indicate the region makes it clear that Emacs is 
excluding that char.

> I wouldn't have a problem with that being the default behavior, but I don't 
> see
> a crying need for it either.

Ok. My patch has a boolean defcustom for it.

> FWIW, I use code[*] that indicates the size of the active region in the mode
> line (using face `region').

That's a good idea, and I think Emacs should do it by default. But when I'm 
making a series of edits involving frequent activation/deactivation of the 
region, and my focus of attention is near the cursor, I'm not paying attention 
to the mode line. And a bar cursor for an active region still makes sense for 
the reason above. So your feature is a complement, not a substitute, for mine.

> I also use a dynamically changing cursor[**] for other purposes than 
> indicating
> the active region:

With my feature turned off, it won't interfere with other uses of cursor-type. 
You can also enable/disable it buffer-locally, and it won't interfere with 
cursor-type in other buffers.

> But there are multiple ways to skin the cat.  I'm neutral on your proposal wrt
> the resulting behavior, and slightly negative wrt the mechanism (hooks).

Ok. Stefan also suggested not using hooks, so my patch doesn't.

Drew Adams wrote on 23 Nov 2013:
> The proposal says that this "(speaking from experience) an Emacs
> newbie finds distracting, since it seems to indicate that that
> character is also part of the region, even though it actually
> isn't."
> In what way does it "seem to indicate" that the character under
> the cursor is part of the region?

The character under the cursor, like text in a highlighted region, is displayed 
with a different background than the rest of the text in the buffer is. And 
with the cursor at the end of the region, that non-standard background is 
visually suggestive of the character being in the region.

> Emacs provides plenty of visual feedback about what is the
> correct impression.  It doesn't take any thought to find out what
> is in the region and what is not.  It just takes one or two
> selections - an experimentation of maybe 20 seconds or so.
> Seriously, how long did it take you to figure out the truth here?

Of course, the truth quickly becomes clear. But it remains visually grating. 
Since this is just a matter of preference, there's an option to turn it on or 

> 2. The 2nd reason given for the proposal: "Neither is there
> indication of the active region if point is one less than mark and
> blink-cursor-mode is off."
> I don't see that.  For me, the active region is highlighted in that
> case.  Am I missing something?

You're not missing anything. I was.

> you can see the `region'
> face applied to it as foreground.  I.e., you see the character
> highlighted as part of the region, but you see it in inverse
> video.
> Admittedly, the `region' face as background instead of
> foreground is more obvious.  I'll grant you that.

Indeed, the region face as foreground is so un-obvious that I missed it until 
you pointed it out.

> But that alone
> does not justify this feature being hardcoded into Emacs, IMO.

You and Stefan both suggested not using hooks, so I don't see any other obvious 
way to implement it except by modifying activate-mark and deactivate-mark.

reply via email to

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