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: Wed, 27 May 2015 15:45:37 -0400 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> <878ug53ljk.fsf@newcastle.ac.uk> <87617em2it.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432755969 4790 80.91.229.3 (27 May 2015 19:46:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 19:46:09 +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 Wed May 27 21:45: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 1YxhH5-0001vH-3h for ged-emacs-devel@m.gmane.org; Wed, 27 May 2015 21:45:59 +0200 Original-Received: from localhost ([::1]:55254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxhH4-00088J-Gx for ged-emacs-devel@m.gmane.org; Wed, 27 May 2015 15:45:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxhGq-00088C-HO for emacs-devel@gnu.org; Wed, 27 May 2015 15:45:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxhGm-0000qk-39 for emacs-devel@gnu.org; Wed, 27 May 2015 15:45:44 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:49678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxhGl-0000qO-N6 for emacs-devel@gnu.org; Wed, 27 May 2015 15:45:39 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t4RJjbNd027776; Wed, 27 May 2015 15:45:37 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 4D42D660ED; Wed, 27 May 2015 15:45:37 -0400 (EDT) In-Reply-To: <87617em2it.fsf@newcastle.ac.uk> (Phillip Lord's message of "Wed, 27 May 2015 17:03:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered AFF_LOTTO_1=0.2, RV5319=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5319> : inlines <3083> : streams <1445709> : uri <1941700> 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:186884 Archived-At: > Had a bit of a nightmare building from trunk. I still do not understand > why this happens so inconsistently for me; my "main" clone failed to > build even after make bookstrap, but a clone of the clone worked fine. The "original clone" was probably not completely clean, and the recent change that removed lisp.mk required rebuilding the Makefile in a way that's not handled by "make bootstrap". Our makefiles have a lot of circular dependencies (e.g. they're built from autoconf/automake files, so the makefiles themselves need to be re-made). I suggest you file a bug report about it: we really should split the "bootstrap" target into two: one that handles the Elisp-bootstrapping (where we first need to build a "bootstrap-emacs" with ldefs-boot.el and uncompiled files and then build the real loaddefs.el and compile the .el files to then build the real "emacs"), and another that handles the "build machinery's own bootstrap" (which would remove a few more files than the current "bootstrap" but wouldn't need to remove the .elc and loaddefs.el files). > I really must be doing something wrong thing. No, it's not just you. Many people have bumped into this. I bumped into it as well, it's just that my experience allowed me to handle it without too much trouble. > This appears to work. Thanks for confirming. > Using italian-postfix, with -off set to t in > scratch I get, after typing "bu" I get > b[u]u_ IIUC that's because you had "b[u]" before you typed the "u" which then inserted "u_" without running pre-command-hook (since we don't know yet exactly what command we're going to run). > With it -off set to nil, I get > bu_ > (i.e. a u waiting for the dead-key). And here the "[u]" is gone because we ran pabbrev-input-event-functions right after reading the "u". > At the moment, this also means that it's never possible to complete > after a "u" (or a "u`") or any character with a dead key. Not sure what you mean here. It prevents pabbrev from *displaying* the completion, but it doesn't prevent the user from causing the completion (assuming she guessed what the completion would be, despite not seeing it displayed), right? > That would require quite a lot more thought; I guess that the "u" you > can see on screen is not really in the buffer until the command (and > key sequence) has completed anyway. IIRC the way quail works, the "u_" is very much inserted in the buffer (it's not just a display-only artifact such as an overlay with an after-string, tho it could also use such a thing), but not via a command (e.g. self-insert-command) but via quail's internal code and that "u_" will be erased before we (later) run pre-command-hook and then self-insert-command. > Still if someone really cared about this, they could switch to > a pre-fix method. That should suffer from the same problem, tho affecting the "accent" chars rather then u/e/... To solve this problem in general, I guess we could/should generalize input-event-functions into a before-input-event-functions (aka after-read-event-functions) and an after-input-event-functions (aka before-read-event-functions). So you could use after-input-event-functions instead of post-command-hook to insert pabbrev's completion "box". > I tried french-prefix and that works nicely, > although, even using Emacs, I still can't actually speak French. Hmm... sounds like a bug in the "french-prefix" method. Oh wait, no indeed it only lets you write French, but not speak it. You could still open a feature request for it, tho. > So, the practical upshot is, yes, it seems to work nicely! > Phil > Stefan Monnier writes: >>> 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. >> >> Could you try the patch below to see if it provides the feature >> you need? >> >> >> Stefan >> >> >> diff --git a/etc/NEWS b/etc/NEWS >> index 1cccc31..f1b7119 100644 >> --- a/etc/NEWS >> +++ b/etc/NEWS >> @@ -811,6 +811,8 @@ behavior, set `diff-switches' to `-c'. >> >> * Lisp Changes in Emacs 25.1 >> >> +** New hook `input-event-functions' run whenever a user-input event is read. >> + >> ** The default value of `load-read-function' is now `read'. >> >> ** New hook `pre-redisplay-functions', a bit easier to use than pre-redisplay-function. >> diff --git a/lisp/subr.el b/lisp/subr.el >> index b9a847d..df0ed42 100644 >> --- a/lisp/subr.el >> +++ b/lisp/subr.el >> @@ -1110,6 +1110,12 @@ See `event-start' for a description of the value returned." >> "Return the multi-click count of EVENT, a click or drag event. >> The return value is a positive integer." >> (if (and (consp event) (integerp (nth 2 event))) (nth 2 event) 1)) >> + >> +(defvar input-event-functions nil >> + ;; BEWARE: If it looks like this is not run anywhere, it's normal: >> + ;; this is run in keyboard.c. >> + "Special hook run each time a user-input event is read. >> +Each function is called with one argument: the event.") >> >> ;;;; Extracting fields of the positions in an event. >> >> diff --git a/src/keyboard.c b/src/keyboard.c >> index eb66c44..5c64199 100644 >> --- a/src/keyboard.c >> +++ b/src/keyboard.c >> @@ -2454,7 +2454,7 @@ read_char (int commandflag, Lisp_Object map, >> /* Also check was_disabled so last-nonmenu-event won't return >> a bad value when submenus are involved. (Bug#447) */ >> && (EQ (c, Qtool_bar) || EQ (c, Qmenu_bar) || was_disabled)) >> - *used_mouse_menu = 1; >> + *used_mouse_menu = true; >> >> goto reread_for_input_method; >> } >> @@ -2995,6 +2995,8 @@ read_char (int commandflag, Lisp_Object map, >> if (! NILP (also_record)) >> record_char (also_record); >> >> + Frun_hook_with_args (2, ((Lisp_Object []) {Qinput_event_functions, c})); >> + >> /* Wipe the echo area. >> But first, if we are about to use an input method, >> save the echo area contents for it to refer to. */ >> @@ -3986,7 +3988,7 @@ kbd_buffer_get_event (KBOARD **kbp, >> obj = list1 (intern ("ns-unput-working-text")); >> kbd_fetch_ptr = event + 1; >> if (used_mouse_menu) >> - *used_mouse_menu = 1; >> + *used_mouse_menu = true; >> } >> #endif >> >> @@ -4181,13 +4183,13 @@ kbd_buffer_get_event (KBOARD **kbp, >> && !EQ (event->frame_or_window, event->arg) >> && (event->kind == MENU_BAR_EVENT >> || event->kind == TOOL_BAR_EVENT)) >> - *used_mouse_menu = 1; >> + *used_mouse_menu = true; >> #endif >> #ifdef HAVE_NS >> /* Certain system events are non-key events. */ >> if (used_mouse_menu >> && event->kind == NS_NONKEY_EVENT) >> - *used_mouse_menu = 1; >> + *used_mouse_menu = true; >> #endif >> >> /* Wipe out this event, to catch bugs. */ >> @@ -8445,7 +8447,7 @@ read_char_x_menu_prompt (Lisp_Object map, >> Lisp_Object prev_event, bool *used_mouse_menu) >> { >> if (used_mouse_menu) >> - *used_mouse_menu = 0; >> + *used_mouse_menu = false; >> >> /* Use local over global Menu maps. */ >> >> @@ -8494,7 +8496,7 @@ read_char_x_menu_prompt (Lisp_Object map, >> else if (NILP (value)) >> value = Qt; >> if (used_mouse_menu) >> - *used_mouse_menu = 1; >> + *used_mouse_menu = true; >> return value; >> } >> return Qnil ; >> @@ -9067,7 +9069,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, >> : (/* indec.start < t || fkey.start < t || */ keytran.start < t)) >> { >> Lisp_Object key; >> - bool used_mouse_menu = 0; >> + bool used_mouse_menu = false; >> >> /* Where the last real key started. If we need to throw away a >> key that has expanded into more than one element of keybuf >> @@ -11078,6 +11080,7 @@ syms_of_keyboard (void) >> DEFSYM (Qself_insert_command, "self-insert-command"); >> DEFSYM (Qforward_char, "forward-char"); >> DEFSYM (Qbackward_char, "backward-char"); >> + DEFSYM (Qinput_event_functions, "input-event-functions"); >> >> /* Non-nil disable property on a command means do not execute it; >> call disabled-command-function's value instead. */