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: Fri, 06 Feb 2015 13:55:19 +0000 Message-ID: <87fvajb0vs.fsf@newcastle.ac.uk> References: <878ugcmqr6.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423230960 8936 80.91.229.3 (6 Feb 2015 13:56:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Feb 2015 13:56:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 06 14:55:59 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 1YJjO1-0002Kp-Vd for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 14:55:58 +0100 Original-Received: from localhost ([::1]:48393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJjO1-0004u9-Ic for ged-emacs-devel@m.gmane.org; Fri, 06 Feb 2015 08:55:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJjNZ-0004ms-Ee for emacs-devel@gnu.org; Fri, 06 Feb 2015 08:55:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJjNU-00081P-Hb for emacs-devel@gnu.org; Fri, 06 Feb 2015 08:55:29 -0500 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:45018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJjNU-00080U-Cf for emacs-devel@gnu.org; Fri, 06 Feb 2015 08:55:24 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1YJjNQ-00077Z-FJ; Fri, 06 Feb 2015 13:55:20 +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 1YJjNQ-000276-BS; Fri, 06 Feb 2015 13:55:20 +0000 In-Reply-To: (Stefan Monnier's message of "Thu, 5 Feb 2015 15:19:40 -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.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:182525 Archived-At: Stefan Monnier writes: >> All fine, but it's breaking my completion framework which removes >> previously offered completions on the pre-command-hook. > > Indeed, I wouldn't be surprised if several other uses of > pre-command-hook could suffer from unexpected behaviors in > such situations. At a quick test, the auto-complete package also behaves badly wrt input methods. The on-screen output is bizarre, although what you end up with in the buffer looks correct, so I guess it is the same problem. > >> I need it to run as soon as the "a" key has been pressed. > > Of course, you can do that using one of the input-method hooks (maybe > input-method-after-insert-chunk-hook), or you could rely on > before-change-functions. Gave that a quick go. As far as I can see, after-insert-chunk-hook runs after the input is complete. Likewise, b-c-f which only runs when the buffer has changed. >> Is there a better hook? > > I don't think so, sadly. > > Maybe we could introduce a new hook like `after-idle-hook'. Part of the > question is what should happen if a timer or a process filter runs > (these can run while Emacs is "idle")? How 'bout when that > timer/process-filter inserts text near/at point? I do buffer analytics in the idle cycle -- I would guess that the same thing is true for most completion packages. So I'd need to be able to distinguish between this and the user doing something. What about after-user-interaction-hook? Or after-something-has-happened-that-changes-the-display-on-screen-of-a-buffer. Although the latter might be affected by things that change the mode line in the idle cycle (like a word count mode). Phil