From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: pre-command-hook with input methods Date: Mon, 09 Feb 2015 11:13:12 -0500 Message-ID: References: <878ugcmqr6.fsf@newcastle.ac.uk> <87fvajb0vs.fsf@newcastle.ac.uk> <87siej9h8c.fsf@newcastle.ac.uk> <87iofb2wfk.fsf@newcastle.ac.uk> <87egpz14re.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423498410 11687 80.91.229.3 (9 Feb 2015 16:13:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Feb 2015 16:13:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: phillip.lord@newcastle.ac.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 09 17:13:26 2015 Return-path: Envelope-to: ged-emacs-devel@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 1YKqxe-0006LE-OR for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 17:13:22 +0100 Original-Received: from localhost ([::1]:33635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKqxe-00078d-5O for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 11:13:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKqxZ-00077v-U7 for emacs-devel@gnu.org; Mon, 09 Feb 2015 11:13:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKqxW-0002pu-OT for emacs-devel@gnu.org; Mon, 09 Feb 2015 11:13:17 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKqxW-0002pe-IK for emacs-devel@gnu.org; Mon, 09 Feb 2015 11:13:14 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t19GDClo008875; Mon, 9 Feb 2015 11:13:13 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 99F7B1240; Mon, 9 Feb 2015 11:13:12 -0500 (EST) In-Reply-To: <87egpz14re.fsf@newcastle.ac.uk> (Phillip Lord's message of "Mon, 09 Feb 2015 15:30:45 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5212=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5212> : inlines <2055> : streams <1387430> : uri <1850586> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182705 Archived-At: > Ah, sorry. The advice is actually on the variable, and no on the > symbol stored in the variable? So it runs even if the value changes? Ah, you're right that other packages won't use add-function, so they'll stomp on our advice! >> Maybe what you're after is just an input-event-hook? > I think for consistency, the hook should run immediately before or after > Emacs responds to C-u (or C-x) depending on whether it is pre- or post-. > Effectively, the C-x of a C-xC-f is, I think equivalent to the first "a" > of a "a`" post-fix input key sequence. The only reason that the former > works fine for me, and the latter is problematic is the latter changes the > display of the buffer while the former changes just the mini-buffer. So it sounds like you'd indeed be happy with an input-event-hook. > The other possibility is not to have an interaction hook but to have a > "the buffer has just changed in some way that is liable to cause a > redisplay"-hook. I don't know that this would be better. I throw it out > as a possibility, depending on which is easier. Then maybe the (new in 24.4) pre-redisplay-function could be used for that. Something like (add-function :before pre-redisplay-function (lambda (wins) (if (or (eq t wins) (memq (mapcar #'window-buffer wins))) ))) Of course, this will require some care, since a redisplay happens probably right after you've set things up (i.e. before you start waiting for user input), and you don't want *that* redisplay to trigger the . Stefan