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#11520: 24.1.50; delete-selection-mode conflicts with electric-pair-mode Date: Sun, 20 May 2012 09:31:50 -0700 Message-ID: <52696FFEBE154517A60576312AEEEE22@us.oracle.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1337531557 21016 80.91.229.3 (20 May 2012 16:32:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 May 2012 16:32:37 +0000 (UTC) Cc: 11520@debbugs.gnu.org To: "'Stefan Monnier'" , "'Simon Law'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 20 18:32:36 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 1SW93c-00088d-5d for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 May 2012 18:32:36 +0200 Original-Received: from localhost ([::1]:50286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW93b-0001pv-Ll for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 May 2012 12:32:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW93X-0001pT-KC for bug-gnu-emacs@gnu.org; Sun, 20 May 2012 12:32:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SW93V-0002Ta-F7 for bug-gnu-emacs@gnu.org; Sun, 20 May 2012 12:32:31 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SW93V-0002TW-BY for bug-gnu-emacs@gnu.org; Sun, 20 May 2012 12:32:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SW941-0007Os-Gc for bug-gnu-emacs@gnu.org; Sun, 20 May 2012 12:33:01 -0400 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, 20 May 2012 16:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11520-submit@debbugs.gnu.org id=B11520.133753156528425 (code B ref 11520); Sun, 20 May 2012 16:33:01 +0000 Original-Received: (at 11520) by debbugs.gnu.org; 20 May 2012 16:32:45 +0000 Original-Received: from localhost ([127.0.0.1]:35558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SW93l-0007OO-1e for submit@debbugs.gnu.org; Sun, 20 May 2012 12:32:45 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:38154) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SW93i-0007OC-QE for 11520@debbugs.gnu.org; Sun, 20 May 2012 12:32:44 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4KGW287016701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 20 May 2012 16:32:03 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 q4KGW1B6017374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 May 2012 16:32:02 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q4KGW1d3014030; Sun, 20 May 2012 11:32:01 -0500 Original-Received: from dradamslap1 (/10.159.217.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 May 2012 09:32:01 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac02mJ4oXbM5bPf7RmOKtReGO+pBHwABvStw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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 (newer, 2) 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:60235 Archived-At: > Thanks for the recipe. I'm not sure yet how best to solve > this problem. Basically, the issue is that delete-selection-mode > operates before the ( is processed, so it has to "guess" what > ( will do. > > Most likely the cleanest solution will be to add some > "delete-selection-predicates" hook that electric-pair-mode can use to > explain when to inhibit delete-selection. I hesitate to jump in here. I like `d-s' mode, and I hope we do not radically alter its design (which keys off of certain command symbol properties, and which takes place pre-command). I don't claim expertise here; I just like the way `d-s' handles and is easy to configure. It essentially hooks into specific commands, taking effect just before they do. `e-p-m' does not change the bindings of self-inserting keys - they are still bound to `self-insert-command'. And `d-s-m' treats that command as it should: the self-insertion is preceded by deletion of the region. `d-s' mode determines the particular behavior from the command. Its behavior is easily changeable by setting different properties on the command symbol. But a given command (e.g. `self-insert-command') has a single delete-selection behavior. `d-s' takes effect _before_ the affected command (on `pre-command-hook'), not after it. `e-p', on the contrary, does its thing _after_ the command (there is apparently only one such command, so far: `self-insert-command'). `e-p' depends on `post-self-insert-hook', which is new in Emacs 24. I see that this hook is also used by other things in Emacs 24. Dunno whether those other cases might also be problematic for use with d-s mode. `e-p', like `d-s', is command-driven - it is associated with only one command, in a hard-coded way rather than by looking up command-symbol properties. Its behavior is thus not variable depending on the command (only one command, only one behavior). But this difference is not really important here, I think. The real difference is when the special effect takes place: before or after the affected command (`self-insert-command', in this case). Since `d-s' does its thing (deletion) before the relevant command, it is natural that it take effect pre-command. Since `e-p' does its thing (insertion) after the relevant command (`self-insert-command' only), it is natural that it take effect post-command. But as you say, Stefan, a pre-command approach like d-s knows nothing about what might be expected to happen after the command is done. It could be possible to let `e-p' know what `d-s' has already done, but I do not see how it is possible/practical to let `d-s' know what `e-p' will do. We could make `d-s' aware that `e-p' mode is turned on, and we could even try to let it know exactly what `e-p' mode does (not a very modular approach, but perhaps doable). But knowing that, `d-s' would have to not only test for `self-insert-command' but also test the character to be inserted. We would end up, I'm afraid, duplicating nearly all of the `e-p' logic inside `d-s'. (But perhaps I don't understand well what you had in mind.) Anyway, that mismatch (pre-command control vs post) is I guess the problem here. If so, it might be seen to be more general than `d-s' vs `e-p'. I don't really have a solution. (Mainly I have a concern that `d-s' mode not be altered radically.) Wrt your proposal: I don't quite understand. `e-p' wants to inhibit `d-s' deletion only in the case where a `(' (or whatever else, such as `"') is inserted. It does not want to inhibit it generally, correct? If so, how can it possibly inhibit it in only some cases, if it does not even take effect until after the `(' command (= `self-insert-command') is finished? I don't see how `e-p', acting post-command, can _inhibit_ something that happens pre-command. `d-s' could perhaps be made aware that `e-p' is coming up, but to make `d-s' DTRT I would think that it would need to know nearly everything about `e-p'. `e-p' could, however undo/reverse what `d-s' did. In the case of killing this would be simple, I imagine, but it might not be quite so trivial in other `d-s' cases. Perhaps `d-s' could save some "undoing" info for the eventuality that some post-command action (e.g. `e-p') might want to reverse what `d-s' did. That's probably what I would propose: have `e-p' somehow undo what `d-s' did. But I'm sure you know more about this than I. My real concern is that we not lose any of the basic design of `d-s': pre-command & driven by properties on command symbols.