all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Geoff Gole" <geoffgole@gmail.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>,
	miles@gnu.org,  emacs-devel@gnu.org
Subject: Re: Annoying paren match messages in minibuffer
Date: Tue, 13 Jan 2009 22:58:54 +0900	[thread overview]
Message-ID: <f5bc73230901130558n68012b52p518d38459c8ba8b@mail.gmail.com> (raw)
In-Reply-To: <jwvwsd05z9g.fsf-monnier+emacs@gnu.org>

> For those, you'd need to set the variable buffer-locally rather than
> let-bind it.

I found getting this right a touch tricky due to the possibility of
recursive minibuffers. But here we go:

(defun locally-suppress-paren-matching ()
  (make-local-variable 'blink-matching-paren)
  (setq blink-matching-paren nil)
  (make-local-variable 'show-paren-mode)
  (setq show-paren-mode nil)
  ;; remove suppression so recursive minibuffers can retain matching
  (remove-hook 'minibuffer-setup-hook 'locally-suppress-paren-matching))

;; This can be used to suppress spurious paren matching complaints for
;; minibuffer input that might be sensible without being balanced.
(defmacro with-minibuffer-suppressed-paren-matching (&rest body)
  "Suppresses paren highlighting for minibuffer invocations in
BODY.  On entry to the minibuffer the suppression is removed,
allowing paren highlighting to work for recursive minibuffers."
  `(let ((minibuffer-setup-hook
	  ;; On entry, kill paren matching and remove self from
	  ;; minibuffer-setup-hook (fix for recursive minibuffers).
	  (cons 'locally-suppress-paren-matching minibuffer-setup-hook))
	 (minibuffer-exit-hook
	  ;; On exit, add back the removed hook.
	  (cons (lambda ()
		  (add-hook 'minibuffer-setup-hook
			    'locally-suppress-paren-matching))
		minibuffer-exit-hook)))
     ,@body))

I don't really like this solution. It appears to work, but requires
patching in a whole bunch of places. And check out the "nifty" self
removing hook!

> Maybe the problem can be fixed by changing the way the message is
> displayed.  E.g. it could be displayed as " [unmatched paren]" at the
> end of the minibuffer input, as is done for minibuffer
> completion messages.

I initially thought this might be a bad idea as it would require
special casing paren matching in the minibuffer. The idea is growing
on me, though.




  parent reply	other threads:[~2009-01-13 13:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-12 12:18 Annoying paren match messages in minibuffer Geoff Gole
2009-01-12 15:20 ` Stefan Monnier
2009-01-13  2:26   ` Miles Bader
2009-01-13 14:00     ` Stefan Monnier
2009-01-13 15:55     ` Dan Nicolaescu
2009-01-13 18:27       ` Stefan Monnier
2009-01-13 18:33         ` Dan Nicolaescu
2009-01-14 22:15           ` Stefan Monnier
2009-01-14 22:30             ` Drew Adams
2009-01-13 13:58   ` Geoff Gole [this message]
2009-01-13 18:25     ` Stefan Monnier
2009-01-13 23:28 ` Juri Linkov
2009-01-14 13:46   ` Chong Yidong
2009-01-14 14:01     ` Stefan Monnier
2009-01-14 15:29       ` Drew Adams
2009-01-14 21:12         ` Juri Linkov
2009-01-14 21:52           ` Stefan Monnier
2009-01-14 22:22             ` Drew Adams
2009-01-14 23:10               ` Stefan Monnier
2009-01-15  0:52                 ` Drew Adams
2009-01-15  2:41                   ` Stefan Monnier
2009-01-16 19:10                     ` Drew Adams
2009-01-16 20:52                       ` Stefan Monnier
2009-01-16 23:42                         ` Drew Adams
2009-01-17  2:15                           ` Stefan Monnier
2009-01-14 22:13           ` Drew Adams
2009-01-14 21:12       ` Juri Linkov
2009-01-14 21:53         ` Stefan Monnier
2009-01-14 18:56   ` Geoff Gole
2009-01-14 21:14     ` Juri Linkov
2009-01-14 22:20       ` Geoff Gole
  -- strict thread matches above, loose matches on Subject: below --
2009-01-14 23:16 Chetan Pandya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f5bc73230901130558n68012b52p518d38459c8ba8b@mail.gmail.com \
    --to=geoffgole@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.