unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: emacs-devel@gnu.org
Cc: David Kastrup <dak@gnu.org>
Subject: [PATCH v1] Let input queue deal gracefully with up-events
Date: Wed, 28 Jan 2015 16:19:03 +0100	[thread overview]
Message-ID: <1422458343-12633-1-git-send-email-dak@gnu.org> (raw)
In-Reply-To: <20150128145849.GA5107@acm.acm>

* keyboard.c (apply_modifiers_uncached, parse_solitary_modifier)
(parse_modifiers_uncached): React gracefully to "up-" modifiers:
those may easily be injected by user-level Lisp code.
(read_key_sequence): Discard unbound up-events like unbound
down-events: they are even more likely only relevant for special
purposes.

While Emacs will not produce up-events on its own currently (those are
converted to drag or click events before being converted to
Lisp-readable structures), the input queue can be made to contain them
by synthesizing events to `unread-command-events'.  This patch makes
Emacs deal consistently with such events.

Signed-off-by: David Kastrup <dak@gnu.org>
---
While changing the comment Alan complained about I decided to fix
another comment that was no longer corresponding to the code.

 src/ChangeLog  |  9 +++++++++
 src/keyboard.c | 34 +++++++++++++++++++++++-----------
 2 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/src/ChangeLog b/src/ChangeLog
index 1df4f6a..f9f53c4 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,12 @@
+2015-01-28  David Kastrup  <dak@gnu.org>
+
+	* keyboard.c (apply_modifiers_uncached, parse_solitary_modifier)
+	(parse_modifiers_uncached): React gracefully to "up-" modifiers:
+	those may easily be injected by user-level Lisp code.
+	(read_key_sequence): Discard unbound up-events like unbound
+	down-events: they are even more likely only relevant for special
+	purposes.
+
 2015-01-27  Eli Zaretskii  <eliz@gnu.org>
 
 	* dired.c (directory_files_internal) [WINDOWSNT]: If readdir
diff --git a/src/keyboard.c b/src/keyboard.c
index 383c109..b762e13 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -6202,6 +6202,10 @@ parse_modifiers_uncached (Lisp_Object symbol, ptrdiff_t *modifier_end)
 	case 't':
 	  MULTI_LETTER_MOD (triple_modifier, "triple", 6);
 	  break;
+
+	case 'u':
+	  MULTI_LETTER_MOD (up_modifier, "up", 2);
+	  break;
 #undef MULTI_LETTER_MOD
 
 	}
@@ -6249,16 +6253,18 @@ apply_modifiers_uncached (int modifiers, char *base, int base_len, int base_len_
   /* Since BASE could contain nulls, we can't use intern here; we have
      to use Fintern, which expects a genuine Lisp_String, and keeps a
      reference to it.  */
-  char new_mods[sizeof "A-C-H-M-S-s-down-drag-double-triple-"];
+  char new_mods[sizeof "A-C-H-M-S-s-up-down-drag-double-triple-"];
   int mod_len;
 
   {
     char *p = new_mods;
 
-    /* Only the event queue may use the `up' modifier; it should always
-       be turned into a click or drag event before presented to lisp code.  */
-    if (modifiers & up_modifier)
-      emacs_abort ();
+    /* Mouse events should not exhibit the `up' modifier; it should
+       always be turned into a click or drag event before being
+       presented to lisp code.  And there should not be more than one
+       of up/down/click/drag anyway.  But since Lisp events can be
+       synthesized, we don't take exception to unexpected
+       combinations */
 
     if (modifiers & alt_modifier)   { *p++ = 'A'; *p++ = '-'; }
     if (modifiers & ctrl_modifier)  { *p++ = 'C'; *p++ = '-'; }
@@ -6268,6 +6274,7 @@ apply_modifiers_uncached (int modifiers, char *base, int base_len, int base_len_
     if (modifiers & super_modifier) { *p++ = 's'; *p++ = '-'; }
     if (modifiers & double_modifier) p = stpcpy (p, "double-");
     if (modifiers & triple_modifier) p = stpcpy (p, "triple-");
+    if (modifiers & up_modifier) p = stpcpy (p, "up-");
     if (modifiers & down_modifier) p = stpcpy (p, "down-");
     if (modifiers & drag_modifier) p = stpcpy (p, "drag-");
     /* The click modifier is denoted by the absence of other modifiers.  */
@@ -6387,8 +6394,7 @@ DEFUN ("internal-event-symbol-parse-modifiers", Fevent_symbol_parse_modifiers,
    BASE must be unmodified.
 
    This is like apply_modifiers_uncached, but uses BASE's
-   Qmodifier_cache property, if present.  It also builds
-   Qevent_symbol_elements properties, since it has that info anyway.
+   Qmodifier_cache property, if present.
 
    apply_modifiers copies the value of BASE's Qevent_kind property to
    the modified symbol.  */
@@ -6734,6 +6740,10 @@ parse_solitary_modifier (Lisp_Object symbol)
       MULTI_LETTER_MOD (triple_modifier, "triple", 6);
       break;
 
+    case 'u':
+      MULTI_LETTER_MOD (up_modifier, "up", 2);
+      break;
+
 #undef SINGLE_LETTER_MOD
 #undef MULTI_LETTER_MOD
     }
@@ -9441,14 +9451,16 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt,
 		   Drags reduce to clicks.
 		   Double-clicks reduce to clicks.
 		   Triple-clicks reduce to double-clicks, then to clicks.
-		   Down-clicks are eliminated.
+		   Up/Down-clicks are eliminated.
 		   Double-downs reduce to downs, then are eliminated.
 		   Triple-downs reduce to double-downs, then to downs,
 		     then are eliminated.  */
-	      if (modifiers & (down_modifier | drag_modifier
+	      if (modifiers & (up_modifier | down_modifier
+			       | drag_modifier
 			       | double_modifier | triple_modifier))
 		{
-		  while (modifiers & (down_modifier | drag_modifier
+		  while (modifiers & (up_modifier | down_modifier
+				      | drag_modifier
 				      | double_modifier | triple_modifier))
 		    {
 		      Lisp_Object new_head, new_click;
@@ -9460,7 +9472,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt,
 			modifiers &= ~drag_modifier;
 		      else
 			{
-			  /* Dispose of this `down' event by simply jumping
+			  /* Dispose of this `up/down' event by simply jumping
 			     back to replay_key, to get another event.
 
 			     Note that if this event came from mock input,
-- 
2.1.0




  reply	other threads:[~2015-01-28 15:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 13:31 [PATCH] Let input queue deal gracefully with up-events David Kastrup
2015-01-28 14:58 ` Alan Mackenzie
2015-01-28 15:19   ` David Kastrup [this message]
2015-02-05 17:23     ` [PATCH v1] " David Kastrup
2015-02-05 19:11       ` Stefan Monnier
2015-02-05 19:27         ` David Kastrup
2015-02-05 21:07           ` Ivan Shmakov
2015-02-05 21:42             ` David Kastrup
2015-02-05 19:17       ` Ivan Shmakov
2015-01-28 19:35 ` [PATCH] " Stefan Monnier
2015-01-28 19:50   ` David Kastrup
2015-01-28 22:14     ` Stefan Monnier
2015-01-28 22:55       ` David Kastrup
2015-01-28 22:19 ` Stefan Monnier
2015-01-28 23:06   ` David Kastrup
2015-01-29  3:57     ` Stefan Monnier
2015-01-29  8:49       ` David Kastrup
2015-01-29 15:00         ` Stefan Monnier
2015-01-29 15:14           ` David Kastrup

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=1422458343-12633-1-git-send-email-dak@gnu.org \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).