[Top][All Lists]

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

Re: Documentation of transient-mark-mode is sloppy, wrong, and confused.

From: Stefan Monnier
Subject: Re: Documentation of transient-mark-mode is sloppy, wrong, and confused.
Date: Thu, 28 May 2009 21:55:51 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)

> Hmmm.  No you haven't.  You have noted one of the circumstances in which
> a mark becomes active, yet haven't said what it is for a mark to BE
> active.  It is as though a young child has asked you what "pregnant"
> means, and the entire gist of your answer is "a woman becomes pregnant
> after a kissing and cuddling session".  Unless you mention the growing
> foetus, your answer is evasive and unhelpful, in fact not really an
> answer at all.  What, exactly, is the essence of "active"ness, in the
> same way that the foetus is the essence of pregnancy?

The problkem is that the activeness of the mark doesn't describe some
property of some other state.  It's a state itself.  In your analogy,
there's no foetus that would allow us to determine whether the mark
is active.  All we have is the `mark-active' variable, so in the end all
we can say is "the mark is active if the mark is active".

> I think the answer has got to be along the following lines:  "The region
> is called @dfn{active} when Emacs marks it internally as the portion of
> buffer which any of a certain set of commands is to work on, when
> otherwise the command would use the whole buffer, or a single word, or
> some other portion of buffer.  When the region is active, the mark is
> also said to be @dfn{active}." - essentially the (iii) from my previous
> email.  Sorry for the poor wording - it's late and I'm tired.

I would find this fairly confusing, giving the impression that Emacs
magically sometimes marks the region in some way outside of the
user's control.

> Surely, it is better to regard the mark and region as being inactive
> when t-m-m is disabled?

That's a delicate question, because mark-active sadly disagrees
with you.  Basically, I'd agree, but the code needs to be changed to
reflect that (by basically introducing a notion of "existing mark" as
distinct from "mark active").


reply via email to

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