From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#4854: 23.1.50; before-string overlay and show-paren-mode Date: Sun, 03 Jul 2016 11:36:01 -0400 Message-ID: <874m86g2e6.fsf@users.sourceforge.net> References: <87fx8x0yng.fsf@escher.local.home> <877hu5zy5r.fsf@escher.local.home> <87k2h5gpyh.fsf@users.sourceforge.net> <87r3ban653.fsf@gmx.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1467560186 27008 80.91.229.3 (3 Jul 2016 15:36:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jul 2016 15:36:26 +0000 (UTC) Cc: 4854@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 03 17:36:16 2016 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 1bJjRO-00061u-Gg for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Jul 2016 17:36:14 +0200 Original-Received: from localhost ([::1]:43114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJjRN-0002Ub-NY for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Jul 2016 11:36:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJjRH-0002TP-PM for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2016 11:36:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJjRC-0000zF-Nh for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2016 11:36:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJjRC-0000z4-Kk for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2016 11:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bJjRC-0005rc-Gf for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2016 11:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Jul 2016 15:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 4854 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 4854-submit@debbugs.gnu.org id=B4854.146756016022533 (code B ref 4854); Sun, 03 Jul 2016 15:36:02 +0000 Original-Received: (at 4854) by debbugs.gnu.org; 3 Jul 2016 15:36:00 +0000 Original-Received: from localhost ([127.0.0.1]:36075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bJjRA-0005rN-Ex for submit@debbugs.gnu.org; Sun, 03 Jul 2016 11:36:00 -0400 Original-Received: from mail-io0-f175.google.com ([209.85.223.175]:33424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bJjR9-0005rC-1I for 4854@debbugs.gnu.org; Sun, 03 Jul 2016 11:35:59 -0400 Original-Received: by mail-io0-f175.google.com with SMTP id t74so135965799ioi.0 for <4854@debbugs.gnu.org>; Sun, 03 Jul 2016 08:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=eXPrsK4J7xq1VshftUqcsU9dAGbmoaNrXxOtvP2uCzo=; b=BY6St78cY9G+70JjPKDjqrGKa4dkIk1Dp9nUj4fUSEL0CV2jll0/UdjnWcPiY+xpzA rmjqfX3CLpFgmBofNhb+x9JbS6qNW1G8NELMyhsceFmK+Ovdg0FAK88tkaPVLOd0wXC5 ONcarWeXg3HXclByXFe5lJLfoRLFdoT1M64CXOPgPPiAhLsImhTqvdsnAoac5S5fW/Yw mrTzfZQJ2Hs290xXxp1OR8FAZ1lTd7HJhKaSU2/cs34D1FvIbQTjFHd8z4nTi+Ju72OA 7xcx3F3DGobX4TXUE0iLGEKAAoOWqOXgcUvTEaoNmHR6sLTy90AvDl+WyzMbkc7uhmV6 6kKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=eXPrsK4J7xq1VshftUqcsU9dAGbmoaNrXxOtvP2uCzo=; b=Z5uT1Ksyn80THbSXdX2x7TSdHlywLPN8RpQZ9gxGGhwF8x7Jfg+k6rbH8qo+2LYDMx ielTGU5vee55FvtAH/fekcHPLas5OQ3/gUaLZnGq909Op+J3RmuLKjtio3Z9Nit8nLNw 7F2NFP65UAinOjjsPC8iLh/6uIuGSE1rPySK/vJkK6kosrGkOFNiSFXERNvW2vsUamRh 0MXDnB8By5NqQ62238dTJPifMwTm5qP5KigTcN3x7fdbVP1OuaZLLJx8W4bdcigec7EQ qCldGikB/1/dgs1/hGd/vvyFJ95/wTtiFzCymqdB/6xJ/JJ5j4jp4h1r3/LFiXPiVfnl TgnQ== X-Gm-Message-State: ALyK8tLVBUNnwCGH1bMMCqX1W20nJC6e26JXIQ5Fn4mTHZevZSGGoUidxcM9XW26kE7ZbA== X-Received: by 10.107.50.65 with SMTP id y62mr5496287ioy.46.1467560153516; Sun, 03 Jul 2016 08:35:53 -0700 (PDT) Original-Received: from zony (206-188-64-44.cpe.distributel.net. [206.188.64.44]) by smtp.googlemail.com with ESMTPSA id p102sm10276604ioi.7.2016.07.03.08.35.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Jul 2016 08:35:52 -0700 (PDT) In-Reply-To: <87r3ban653.fsf@gmx.net> (Stephen Berman's message of "Sun, 03 Jul 2016 16:33:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:120344 Archived-At: Stephen Berman writes: > On Fri, 01 Jul 2016 14:42:30 -0400 npostavs@users.sourceforge.net wrote: > > [...] >> Stephen Berman writes: >>> These two things seem very strange: (i) enabling show-paren-mode and >>> getting the show-paren overlay somehow nullifies the unless test; (ii) >>> this effect only happens when the command is invoked via a key >>> sequence. >> >> It's because show-paren-mode uses a single (pair of) overlay(s) for all >> buffers and moves it to right place during idle time. When you invoke a >> command with M-x the overlay pair gets moved to the minibuffer. With a >> direct keybinding the overlay pair stays in the current buffer. > > Thanks for the diagnosis, which is convincing. > >> So I think this is not a bug, it's just how show-paren-mode works. > > I guess you're right; yet this behavior seems to go against the spirit > of the way Emacs is intended to work, as suggested by the Emacs manual, > node `M-x': "Every Emacs command has a name that you can use to run it. > For convenience, many commands also have key bindings. You can run > those commands by typing the keys, or run them by name. Most Emacs > commands have no key bindings, so the only way to run them is by > name. [...] Note that =E2=80=98forward-char=E2=80=99 is the same command= that you > invoke with the key =E2=80=98C-f=E2=80=99. The existence of a key bindin= g does not stop > you from running the command by name." Are there any other Emacs > commands that produce different behavior depending on whether they are > invoked with a key binding or by name? self-insert-command ;) You can fix your my-test command by changing the condition: (defun my-test () ... (unless (cl-some (lambda (o) (overlay-get o 'before-string)) (overlays-in (1- (point)) (1+ (point)))) ...)) >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > Maybe it would be better to > unify the behavior of show-paren-mode. (I briefly tried conditioning > the calls to move-overlay on whether the current buffer is a minibuffer, > but my attempt (which I didn't give much thought to) didn't work.) Well, it's possible to avoid moving overlays to minibuffer, but then show-paren-mode stops working in the minibuffer, which I don't think is so great. diff --git i/lisp/paren.el w/lisp/paren.el index 53eb500..1e4942f 100644 --- i/lisp/paren.el +++ w/lisp/paren.el @@ -236,9 +236,10 @@ show-paren--default ;; Find the place to show, if there is one, ;; and show it until input arrives. (defun show-paren-function () - (let ((data (and show-paren-mode (funcall show-paren-data-function)))) + (let ((data (and show-paren-mode (not (minibufferp)) + (funcall show-paren-data-function)))) (if (not data) - (progn + (unless (minibufferp) ;; If show-paren-mode is nil in this buffer or if not at a paren= that ;; has a match, turn off any previous paren highlighting. (delete-overlay show-paren--overlay) With that patch, the original my-test keeps inserting more overlays whether it's called by keybinding or M-x. > > I guess this bug can be closed, unless leaving it open might spur > someone to try and "improve" show-paren-mode. Not sure if there's anything to do.