From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: pre-command-hook with input methods Date: Tue, 10 Feb 2015 14:09:51 +0000 Message-ID: <878ug53ljk.fsf@newcastle.ac.uk> 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 1423577412 4266 80.91.229.3 (10 Feb 2015 14:10:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2015 14:10:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 10 15:10:12 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 1YLBVy-0002HN-Kw for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 15:10:10 +0100 Original-Received: from localhost ([::1]:40018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLBVs-000741-Os for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 09:10:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLBVo-00073l-4G for emacs-devel@gnu.org; Tue, 10 Feb 2015 09:10:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLBVk-0005UT-Qh for emacs-devel@gnu.org; Tue, 10 Feb 2015 09:10:00 -0500 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:51220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLBVk-0005SX-L9 for emacs-devel@gnu.org; Tue, 10 Feb 2015 09:09:56 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1YLBVh-0006kU-Af; Tue, 10 Feb 2015 14:09:53 +0000 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YLBVg-0008N6-4P; Tue, 10 Feb 2015 14:09:52 +0000 In-Reply-To: (Stefan Monnier's message of "Mon, 9 Feb 2015 11:13:12 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:182800 Archived-At: Stefan Monnier writes: >>> 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. I think so yes -- so long as input-event means "user input-event" or I have some way of telling. Something coming in from a process, or file-watch notifications need to be ignored. >> 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 . Yes, that would be tricky. I'd probably have to ignore the first redisplay after a completion has been offered. Also, my package does idle cycle operations which include "sit-for" as a way of returning control to the user. These trigger redisplay also which would be unfortunate. Probably they shouldn't do that. I *think* I added that so I could have the idle-cycle operations add visible overlays for debugging purposes, so the sit-for is necessary. Still, it's there now, so I will give it a go. But having the input-event-hook might be better. Phil