From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Documentation of transient-mark-mode is sloppy, wrong, and confused. Date: Thu, 28 May 2009 23:03:59 +0000 Message-ID: <20090528230359.GA1474@muc.de> References: <20090528122927.GA2175@muc.de> <87fxepf9s8.fsf@cyd.mit.edu> <20090528201529.GA4605@muc.de> <87bppdx8c0.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1243551802 31674 80.91.229.12 (28 May 2009 23:03:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 May 2009 23:03:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 29 01:03: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 1M9od3-00046k-O5 for ged-emacs-devel@m.gmane.org; Fri, 29 May 2009 01:03:18 +0200 Original-Received: from localhost ([127.0.0.1]:48639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9od3-0004o8-93 for ged-emacs-devel@m.gmane.org; Thu, 28 May 2009 19:03:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9ocx-0004l4-IL for emacs-devel@gnu.org; Thu, 28 May 2009 19:03:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9oct-0004hB-Tz for emacs-devel@gnu.org; Thu, 28 May 2009 19:03:11 -0400 Original-Received: from [199.232.76.173] (port=42304 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9oct-0004h5-Q0 for emacs-devel@gnu.org; Thu, 28 May 2009 19:03:07 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1467 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M9oct-0000QK-1i for emacs-devel@gnu.org; Thu, 28 May 2009 19:03:07 -0400 Original-Received: (qmail 90216 invoked by uid 3782); 28 May 2009 23:03:05 -0000 Original-Received: from acm.muc.de (pD9E23E19.dip.t-dialin.net [217.226.62.25]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 29 May 2009 01:03:03 +0200 Original-Received: (qmail 2200 invoked by uid 1000); 28 May 2009 23:03:59 -0000 Content-Disposition: inline In-Reply-To: <87bppdx8c0.fsf@cyd.mit.edu> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:111165 Archived-At: Good midnight, Yidong! On Thu, May 28, 2009 at 04:48:15PM -0400, Chong Yidong wrote: > Alan Mackenzie writes: > > The essence of my unhappiness is that "active" isn't defined. You've > > put in a formal @dfn{active}, but weaselled out of actually defining > > it. You state what happens _when_ the mark is "active", but not what > > a mark has to do or to be to acquire or to lose the essence of > > "active"ness. > Good point; I've changed this accordingly. 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? 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. With an actual definition such as this, it becomes clear that when transient-mark-mode is disabled, the region and mark are always inactive. > As for changing the "active mark" terminology, that's not particularly > profitable, because it's already deeply embedded in the C and Lisp code > for over a decade. Bugs should be fixed, regardless of how long they've been in the source. What's new here is that the current bug is no longer a mere option, it's become a factory default. > (There are, of course, many other terminology problems of this sort in > Emacs.) Are there? I don't think there are. "of this sort" here means "so vague that you've got to struggle to pick up the meaning by osmosis". I can't think of any others, off hand. > The main thing that's important, I think, is that the description of > the "transient-mark-mode enabled" behavior and the "transient-mark-mode > disabled" behavior are each internally consistent; they aren't always > mutually consistent, but that's too bad. Manuals shouldn't be patronising. When a manual implicitly says "if you can't even figure out what I mean by \"active\", you're stupid", that's patronising. A concrete example of this is in T. Capers Jones's book "Estimating Software Costs", where he expounds expansively about "function points" (some sort of measurement of functional content), yet regards it as beneath him actually to say what a "function point" is, for the benefit of ignorant cretins like me. > > In *scratch*, disable Transient Mark Mode, write the following line > > and put the region as indicated: > > one two threeee > > ^ ^ > > | | > > point mark > > The mark is now active (since t-m-m is nil). Therefore the region is > > "active". Execute the command `ispell-word' with M-$; this is a command > > which supposedly works on the region when the region is "active". It > > fails to flag the non-word "threeee", suggesting that it regards the > > region as "inactive". > As described in the section about what happens when Transient Mark mode > is disabled: > Some commands, which ordinarily operate on the region when the mark is > active, instead act on the entire buffer. That is a definition of "active", surely, as I suggested above. Surely, it is better to regard the mark and region as being inactive when t-m-m is disabled? > For instance, @kbd{C-x u} normally reverses changes within the region > if the mark is active; when Transient Mark mode is off, it acts on > the entire buffer. However, you can type @kbd{C-u C-x u} to make it > operate on the region. @xref{Undo}. Other commands that act this > way are identified in their own documentation. -- Alan Mackenzie (Nuremberg, Germany).