From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#10056: 24.0.91; Mark deactivation Date: Fri, 25 Jan 2013 11:34:18 -0800 Message-ID: <61EA87D1494E46E9AA03ACEDF88E7CD4@us.oracle.com> References: <87wqws48gn.fsf@mail.jurta.org><87pq2kvzix.fsf@mail.jurta.org><3A9C4978E1D547E291D780F57506CD26@us.oracle.com><0139B55A9A504DE180FC189491666C53@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1359142508 32384 80.91.229.3 (25 Jan 2013 19:35:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jan 2013 19:35:08 +0000 (UTC) Cc: 10056@debbugs.gnu.org To: "'Dani Moncayo'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 25 20:35:27 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Typ3c-0008U4-ON for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Jan 2013 20:35:24 +0100 Original-Received: from localhost ([::1]:47773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Typ3K-0001L9-Ny for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Jan 2013 14:35:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Typ3C-0001HV-HF for bug-gnu-emacs@gnu.org; Fri, 25 Jan 2013 14:35:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Typ36-00063Z-Q4 for bug-gnu-emacs@gnu.org; Fri, 25 Jan 2013 14:34:58 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Typ36-00063N-ML for bug-gnu-emacs@gnu.org; Fri, 25 Jan 2013 14:34:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Typ3F-0000ev-RW for bug-gnu-emacs@gnu.org; Fri, 25 Jan 2013 14:35:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Jan 2013 19:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10056 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10056-submit@debbugs.gnu.org id=B10056.13591424772503 (code B ref 10056); Fri, 25 Jan 2013 19:35:01 +0000 Original-Received: (at 10056) by debbugs.gnu.org; 25 Jan 2013 19:34:37 +0000 Original-Received: from localhost ([127.0.0.1]:49596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Typ2q-0000eJ-MG for submit@debbugs.gnu.org; Fri, 25 Jan 2013 14:34:37 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41981) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Typ2o-0000eB-62 for 10056@debbugs.gnu.org; Fri, 25 Jan 2013 14:34:35 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0PJYMC0032587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Jan 2013 19:34:23 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0PJYM9H016447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2013 19:34:22 GMT Original-Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0PJYMuu001818; Fri, 25 Jan 2013 13:34:22 -0600 Original-Received: from dradamslap1 (/10.159.189.45) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Jan 2013 11:34:22 -0800 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac37L0JrKtEs71iESdK4snXUcjR6uwAAdeMw In-Reply-To: X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:70316 Archived-At: > Well, the reason is the same for all commands I've mentioned: In my > experience (or my usage pattern), after defining an active region and > invoking a command to operate on it, it's much more likely that the > next commands have nothing to do with that active region. IOW, I > almost always set up an active region to do a single operation on it, > not several ones. So keeping the region active is, at best, counter > intuitive and visually annoying to me. I agree, and I think that's the general rule, i.e., the behavior by default. I think the command loop automatically does that, unless a given command explicitly inhibits it. And I have no objection to that general default behavior. I would object, though, if we were to somehow stop an individual command from inhibiting deactivation. Wrt `eval-region', I have no objection to deactivation. But I wonder why that does not happen automatically. I don't have the C code available, but presumably it explicitly inhibits deactivation (?). If so, I wonder what the designers had in mind, IOW, why that inhibition in this case? Maybe you can do some archaeology to find out the history? > > Wrt your footnote [2]: Why should we deactivate the region > > for _any_ command when it is called non-interactively? > > That doesn't make sense to me (yet - but I'm willing to learn why). > > That footnote is about `narrow-to-region', not about "any command". Yes, I understood that it is about `narrow-to-region'. I wondered why Yidong would bother to say that specifically about `narrow-to-region', since it should be true of _all_ commands, AFAIK. Unless a particular command is somehow a special case (are there any such?), we should not automatically deactivate the region for _any_ command when it is called non-interactively. If Lisp code that calls a command wants to deactivate the mark it can do that. _Automatic_ deactivation should be only for interactive invocation, IMO. > But, well, I'm thinking that perhaps the mark deactivation I'm > requesting should be specific to interactive calls. Yes. And I think that is the case wrt automatic deactivation. > After all, what I want to avoid is just the annoyance of having > to type `C-g' to deactivate the mark after realizing that Emacs > didn't do it for me. Yes, and that too should already be the case in general: automatic deactivation for any command that does not, itself, explicitly inhibit deactivation.