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: Sat, 8 Dec 2012 16:00:36 -0800 Message-ID: References: <87wqws48gn.fsf@mail.jurta.org> 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 1355011298 8829 80.91.229.3 (9 Dec 2012 00:01:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Dec 2012 00:01:38 +0000 (UTC) Cc: 10056@debbugs.gnu.org To: "'Juri Linkov'" , "'Dani Moncayo'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 09 01:01:51 2012 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 1ThUL8-0006C2-Tn for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Dec 2012 01:01:51 +0100 Original-Received: from localhost ([::1]:52804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThUKw-00062W-Kn for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Dec 2012 19:01:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThUKu-00062R-IB for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2012 19:01:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ThUKt-0006I8-Ci for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2012 19:01:36 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThUKt-0006I4-9D for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2012 19:01:35 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1ThULJ-0006QG-IH for bug-gnu-emacs@gnu.org; Sat, 08 Dec 2012 19:02: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: Sun, 09 Dec 2012 00:02: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.135501127824633 (code B ref 10056); Sun, 09 Dec 2012 00:02:01 +0000 Original-Received: (at 10056) by debbugs.gnu.org; 9 Dec 2012 00:01:18 +0000 Original-Received: from localhost ([127.0.0.1]:33303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ThUKb-0006PF-IK for submit@debbugs.gnu.org; Sat, 08 Dec 2012 19:01:17 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:19453) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ThUKY-0006P6-RN for 10056@debbugs.gnu.org; Sat, 08 Dec 2012 19:01:16 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB900kob012487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 9 Dec 2012 00:00:47 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qB900jd9014028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Dec 2012 00:00:46 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qB900jdB031259; Sat, 8 Dec 2012 18:00:45 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Dec 2012 16:00:45 -0800 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <87wqws48gn.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac3VmqVihkvBpi5ASG2oqo5VBmgDTAAAaOQQ X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:68208 Archived-At: > >> As I pointed out previously in this thread, the mark should be > >> deactivated (in general - there can be some exceptions) after any > >> command that operates on the active region. Not doing so > >> is annoying, > > The problem is how to implement a general rule "the mark should be > deactivated after any command that operates on the active region". To me, the question is why we would do that, and even what the latter part means. > One way to define "operates on the active region" is when a command > uses `region-beginning' and `region-end'. You can try this definition > by evaluating: > (defun deactivate-mark--advice () (setq deactivate-mark t)) > (advice-add 'region-beginning :after #'deactivate-mark--advice) > (advice-add 'region-end :after #'deactivate-mark--advice) > Does this do what you want with the following functions? > ... > Does this have a side effect undesirable for other functions? Please think again before doing this. "Operates on the active region" can mean just about anything, and I fear that such a blanket manipulation will have adverse affects here and there. And I expect in particular that any use of either `region-beginning' or `region-end' casts the net far too wide. Those functions are often used without making any changes to the text in the region (or even in the buffer). For one thing, any such blanket change would still need to respect (not override) a commands's explicit setting or let-binding of `deactivate-mark'. This has been the of policy ever since there was a notion of mark "activeness" (i.e., since `transient-mark-mode'): -- Variable: deactivate-mark If an editor command sets this variable non-`nil', then the editor command loop deactivates the mark after the command returns (if Transient Mark mode is enabled). All the primitives that change the buffer set `deactivate-mark', to deactivate the mark when the command is finished. To write Lisp code that modifies the buffer without causing deactivation of the mark at the end of the command, bind `deactivate-mark' to `nil' around the code that does the modification. For example: (let (deactivate-mark) (insert " ")) I, and I'm sure others too, have a certain amount of code that binds or sets `deactivate-mark'. Just grep the Emacs Lisp sources for examples. There are commands that use the region and are used as functions within other commands. There are commands that can be used repetitively and might expect to leave the region active between successive calls. There are commands whose purpose is to set the active region. Emacs is complex, and one size does not fit all for this kind of thing. If for some reason a particular Emacs command does not deactivate the mark when it is finished, but you think it should, then just deactivate it explicitly in that command. Just because you find some commands that should but do not yet do so is not a sufficient reason to try forcing this everywhere. Someone took the time to ensure that "All the primitives that change the buffer" DTRT in this regard, and that the command loop respects `deactivate-mark'. You have only to continue that policy carefully: if deactivating (or activating) needs doing here or there, then do it here or there, case by case. Otherwise, I think you're asking for trouble. I could be wrong, of course. But it seems a bit heavy-handed to set out on such a crusade just because this or that command might need fixing. Let's try first to fix (only) the commands that Dani or others report such have a problem.