Re: Reopen bug 535: Problem with highlit regions on Linux virtual terminal

[Alan Mackenzie]

Hi, Stephen!

On Wed, Apr 08, 2009 at 02:35:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > The cons in the marked line is of the mark and the variable
>  > `mark-active'.  This variable doesn't have a coherent definition,
>  > but it causes the region to be highlit.  It is "defined" as

>  >     Non-nil means the mark and region are currently active in this
>  >     buffer.

>  > As I have pointed out before, this is Humpty Dumpty language,

> Not at all.  Active regions and the terminology go back twenty years
> or more.

I don't doubt this, but it has no bearing on the matter.

> If the mark is non-nil, then the region exists.  The region may be
> active, ....

What is the activity that this region does?  Does the region delete a
block of characters?  Does the region jump to the start of the next
defun?

Supposing you have a geologist inside a dead volcano, examining it,
measuring it, chipping bits out of it.  You would call this an "active
volcano", would you?

> ...., in which case operations on the region will succeed, or inactive,
> when such operations will fail.[1]

This is a misuse of the word "active", just as confusing as talking about
"protecting" a copyright work rather than "restricting" it.  In any
sentence with a verb of activity, "the region" is always in the object
position, never the subject position.

"Active" is the wrong word.  Possibly "Reactive" would be a suitable one
- a "reactive region" being one which reacts to commands directed at it.

> In transient-mark-mode, it is possible for the region to be inactive.
> Outside of transient- mark-mode, the region is always active.  (Or
> something like that, that's how zmacs-regions works in XEmacs,
> transient-mark-mode has some tiny differences that I never understood
> very well.)

> It sounds to me like there's a bug in desktop.el[2], and maybe a lack of
> documentation of active regions.  But the term is well-defined.

"Active region" is not well defined, which is what caused the bug in
desktop.  In particular, it is ill defined whilst transient-mark-mode is
not enabled.  Because "active" is here a purely conventional label,
disconnected from its normal semantics, hackers get confused as to what
they really mean by it.  Two competing definitions here are "highlit" and
"reacts to region commands"; one hacker understood the former meaning,
the other the latter.

I think that desktop needs to record whether a region is highlit.  Or
something like that.

Do you have definitions of (as contrasted to a discussion around) "active
region" and "active mark" that you could contribute to the Emacs manual?

> Footnotes: 

> [2]  I guess, as you say, it should record and check for
> transient-mark-mode before going ahead and highlighting regions.
> Personally, I would prefer desktop to have an option such that mark
> status is always reset across sessions.

Yes.  Maybe.  Perhaps....  transient-mark-mode is not simple.  

-- 
Alan Mackenzie (Nuremberg, Germany).