[Top][All Lists]

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

bug#32956: 26.1.50; t-m-m mark deactivation documentation

From: Charles A. Roelli
Subject: bug#32956: 26.1.50; t-m-m mark deactivation documentation
Date: Sat, 06 Oct 2018 21:44:46 +0200

> Date: Sat, 6 Oct 2018 14:48:01 +0000 (UTC)
> From: Drew Adams <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> The Elisp manual, node `The Mark' has similar text, so if
> an update to the doc string is called for then maybe the
> manual text needs a similar update.

The manual looks correct to me.  I think in this case the manual has
been updated without an equivalent change to the docstring of t-m-m.

> BTW, this (the manual) might be a good place to mention
> to Elisp users that (in `transient-mark-mode', at least) the
> mark is also deactivated by default after each command,
> by the command loop. Some commands inhibit this
> automatic deactivation.
> This is a fairly common question by Elisp users who try to
> write a command that they think/hope will end with the
> region staying activated (e.g. for use by a follow-up command).
> This is maybe a good place to tell them about the automatic
> deactivation (by default), and maybe even let them know
> that they can use (setq deactivate-mark  nil) at the end of a
> command definition to inhibit automatic deactivation.

Hmm, deactivate-mark is nil by default -- what effect would setting it
to "nil" again have?  Is it to counteract the effect of previous
function calls within the command, which may have set
"deactivate-mark" to "t"?

> In fact, this bit of `The Mark' doesn't seem quite right:
>   A command can ... request deactivation of the mark upon
>   return to the editor command loop by setting the variable
>   'deactivate-mark' to a non-'nil' value.
> I think that's a bit backward, at least in `transient-mark-mode'.
> IIUC, the command loop automatically deactivates the mark
> after each command, unless `deactivate-mark' is non-nil.

Again, though, deactivate-mark is "nil" by default, so it seems that
some editing function has to set it to "t" for the mark to really be

reply via email to

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