From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Documentation of transient-mark-mode is sloppy, wrong, and confused. Date: Mon, 01 Jun 2009 11:34:35 +0900 Message-ID: <87vdngbs1w.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20090528122927.GA2175@muc.de> <87fxepf9s8.fsf@cyd.mit.edu> <20090528201529.GA4605@muc.de> <87bppdx8c0.fsf@cyd.mit.edu> <20090528230359.GA1474@muc.de> <4A1F7706.80501@online.de> <878wkgco3b.fsf@uwakimon.sk.tsukuba.ac.jp> <20090529085852.GA2793@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1243823454 22714 80.91.229.12 (1 Jun 2009 02:30:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2009 02:30:54 +0000 (UTC) Cc: Kevin Rodgers , Andreas Roehler , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 01 04:30:50 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MAxIY-0000SF-Cu for ged-emacs-devel@m.gmane.org; Mon, 01 Jun 2009 04:30:50 +0200 Original-Received: from localhost ([127.0.0.1]:51167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAxIX-0003af-KL for ged-emacs-devel@m.gmane.org; Sun, 31 May 2009 22:30:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAxIT-0003aI-Mb for emacs-devel@gnu.org; Sun, 31 May 2009 22:30:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAxIO-0003Zq-Ab for emacs-devel@gnu.org; Sun, 31 May 2009 22:30:44 -0400 Original-Received: from [199.232.76.173] (port=54286 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAxIO-0003Zn-4B for emacs-devel@gnu.org; Sun, 31 May 2009 22:30:40 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:59161) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MAxIM-0006UH-AB for emacs-devel@gnu.org; Sun, 31 May 2009 22:30:39 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id E7E548212; Mon, 1 Jun 2009 11:30:33 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6BE32120C0B; Mon, 1 Jun 2009 11:34:35 +0900 (JST) In-Reply-To: <20090529085852.GA2793@muc.de> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111231 Archived-At: Alan Mackenzie writes: > Does XEmacs have a definition of an "active region"? ;-) Yes, although it's a little hard to find because of the heritage of XEmacs in the Lisp machine world. C-h v zmacs-regions RET sez: ------------------------------------------------------------------------ `zmacs-regions' is a built-in boolean variable. -- loaded from "/playpen/src/XEmacs/xemacs/src/editfns.c" Value: t Documentation: *Whether LISPM-style active regions should be used. This means that commands which operate on the region (the area between the point and the mark) will only work while the region is in the ``active'' state, which is indicated by highlighting. Executing most commands causes the region to not be in the active state, so (for example) C-w will only work immediately after activating the region. More specifically: - Commands which operate on the region only work if the region is active. - Only a very small set of commands cause the region to become active: Those commands whose semantics are to mark an area, like `mark-defun'. - The region is deactivated after each command that is executed, except that: - "Motion" commands do not change whether the region is active or not. set-mark-command (C-SPC) pushes a mark and activates the region. Moving the cursor with normal motion commands (C-n, C-p, etc) will cause the region between point and the recently-pushed mark to be highlighted. It will remain highlighted until some non-motion command is executed. exchange-point-and-mark (C-x C-x) activates the region. So if you mark a region and execute a command that operates on it, you can reactivate the same region with C-x C-x (or perhaps C-x C-x C-x C-x) to operate on it again. Generally, commands which push marks as a means of navigation (like beginning-of-buffer and end-of-buffer (M-< and M->)) do not activate the region. But commands which push marks as a means of marking an area of text (like mark-defun (M-C-h), mark-word (M-@) or mark-whole-buffer (C-x h)) do activate the region. The way the command loop actually works with regard to deactivating the region is as follows: - If the variable `zmacs-region-stays' has been set to t during the command just executed, the region is left alone (this is how the motion commands make the region stay around; see the `_' flag in the `interactive' specification). `zmacs-region-stays' is reset to nil before each command is executed. - If the function `zmacs-activate-region' has been called during the command just executed, the region is left alone. Very few functions should actually call this function. - Otherwise, if the region is active, the region is deactivated and the `zmacs-deactivate-region-hook' is called. ------------------------------------------------------------------------ > Here, it has manifestly lead to massive confusion. I suspect that is mostly just the unfortunate Emacs terminology, variable names, and documentation for the concept (sorry guys, but "unfortunate" is the nicest thing I can say about the stuff quoted in this thread), not because the word "active" itself is confusing. > "But EVERYBODY know what \"active\" means!" just won't do. I don't think XEmacs's definition has that problem.