From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Roehler Newsgroups: gmane.emacs.devel Subject: Re: Documentation of transient-mark-mode is sloppy, wrong, and confused. Date: Tue, 02 Jun 2009 08:23:45 +0200 Message-ID: <4A24C571.4070300@online.de> 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> <87vdngbs1w.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1243923742 18007 80.91.229.12 (2 Jun 2009 06:22:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Jun 2009 06:22:22 +0000 (UTC) Cc: Alan Mackenzie , Kevin Rodgers , Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 02 08:22:18 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 1MBNO1-0006ai-6f for ged-emacs-devel@m.gmane.org; Tue, 02 Jun 2009 08:22:13 +0200 Original-Received: from localhost ([127.0.0.1]:50367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBNO0-00071Y-46 for ged-emacs-devel@m.gmane.org; Tue, 02 Jun 2009 02:22:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBNNv-00071A-1v for emacs-devel@gnu.org; Tue, 02 Jun 2009 02:22:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBNNp-0006vK-BH for emacs-devel@gnu.org; Tue, 02 Jun 2009 02:22:05 -0400 Original-Received: from [199.232.76.173] (port=40246 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBNNp-0006vH-4e for emacs-devel@gnu.org; Tue, 02 Jun 2009 02:22:01 -0400 Original-Received: from moutng.kundenserver.de ([212.227.17.8]:53972) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBNNo-0005Ob-FX for emacs-devel@gnu.org; Tue, 02 Jun 2009 02:22:00 -0400 Original-Received: from [192.168.178.27] (p54BE9C0B.dip0.t-ipconnect.de [84.190.156.11]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MKt2u-1MBNNi36K5-0005RT; Tue, 02 Jun 2009 08:21:56 +0200 User-Agent: Thunderbird 2.0.0.19 (X11/20081227) In-Reply-To: <87vdngbs1w.fsf@uwakimon.sk.tsukuba.ac.jp> X-Provags-ID: V01U2FsdGVkX1/TcIweVYmF3drlFsiamQgXhTfxDwbClH18VSV D5pXVPjmPjhCacLE0P9q0NMYgiH9AWygSSkbTEawD10HS9wYXr O6lkIFoNLyx7trqjn+w03ec+XrECohbJL67FkS3FT0= X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:111280 Archived-At: Stephen J. Turnbull wrote: > 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. > > > IMHO XEmacs has another problem, see the docstrings of related functions ` ... (region-active-p) ... Return non-nil if the region is active in the current buffer. If `zmacs-regions' is true, this is equivalent to `region-exists-p'. Otherwise, this function always returns false. ` ... (region-exists-p) ... Return t if the region exists. If active regions are in use (i.e. `zmacs-regions' is true), this means that the region is active. Otherwise, this means that the user has pushed a mark in this buffer at some point in the past. AFAIU definitions (including zmacs-regions) are here intermixed. At least one may be dropped. For me GNU variable `mark-active' is more straightforward by its value, but should be named `mark-set' rather. Info about an existing extend I understand by `region-exists-p' in the word-sense (not the current definition). Writing `region-extends-p' might be still better. Third command may (but must not) require a visibility of region. Would leave that to the programmers to decide, delivering `region-visible-p' for the purpose. My wishlist so far for all Emacsen: `mark-set' `region-extends-p' `region-visible-p' Andreas