From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: shuguang79@qq.com, larsi@gnus.org, 50752@debbugs.gnu.org
Subject: bug#50752: 28.0.50; easy-menu-define lowers the menu-bar key
Date: Wed, 13 Oct 2021 14:59:03 +0300 [thread overview]
Message-ID: <837dehp248.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkmmFnixKo6xeuV0mpQ4a+nXnYEXuq-8pcr7=AFTP0rRMKw@mail.gmail.com> (message from Stefan Kangas on Tue, 12 Oct 2021 15:22:59 -0700)
> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 12 Oct 2021 15:22:59 -0700
> Cc: Shuguang Sun <shuguang79@qq.com>, 50752@debbugs.gnu.org
>
> + for (int i = 0; i < key_len; i++)
> + {
> + Lisp_Object lc_key = Fdowncase (Fsymbol_name (AREF (key, i)));
> + ASET (new_key, i, Fintern (lc_key, Qnil));
> + }
Beware: downcase uses the current buffer's case-table. Is that
something we want here, or could it be undesirable in some cases?
> + found = lookup_key_1 (keymap, new_key, accept_default);
> +
> + if (!NILP (found) && !NUMBERP (found))
> + goto end;
> +
> + /* If we still don't have a match, let's convert any spaces in
> + our lowercased string into dashes, e.g. "foo bar baz" to
> + "foo-bar-baz". */
> + for (int i = 0; i < key_len; i++)
> + {
> + Lisp_Object lc_key = Fdowncase (Fsymbol_name (AREF (key, i)));
Can't we reuse the results of the original downcasing, instead of
doing that again?
> + USE_SAFE_ALLOCA;
> + ptrdiff_t size = SCHARS (lc_key), n;
> + if (INT_MULTIPLY_WRAPV (size, MAX_MULTIBYTE_LENGTH, &n))
> + n = PTRDIFF_MAX;
> + unsigned char *dst = SAFE_ALLOCA (n);
> + unsigned char *o = dst;
> + ptrdiff_t j = 0, j_byte = 0, chars = 0;
> +
> + while (j < SCHARS (lc_key))
> + {
> + int ch = fetch_string_char_advance (lc_key, &j, &j_byte);
> + if (ch == ' ')
> + *o = '-';
> + else
> + *o = ch;
> + chars++;
This will only work with plain-ASCII characters in lc_key (but then
you don't need fetch_string_char_advance, you can access the bytes one
by one). You need to use CHAR_STRING instead.
> + int len;
> + string_char_and_length (o, &len);
> + o += len;
This is overhead. You already know the length of the multibyte
string, because fetch_string_char_advance reports it back to you via
j_byte. So just use that.
> diff --git a/test/src/keymap-tests.el b/test/src/keymap-tests.el
> index 68b42c346c..8f3dff2acb 100644
> --- a/test/src/keymap-tests.el
> +++ b/test/src/keymap-tests.el
> @@ -124,6 +124,17 @@ keymap-lookup-key/too-long
> ;; (ert-deftest keymap-lookup-key/accept-default ()
> ;; ...)
>
> +(ert-deftest keymap-lookup-key/mixed-case ()
> + (let ((map (make-keymap)))
> + (define-key map [menu-bar foo bar] 'foo)
> + (should (eq (lookup-key map [menu-bar foo bar]) 'foo))
> + (should (eq (lookup-key map [menu-bar Foo Bar]) 'foo))))
> +
> +(ert-deftest subr-test-lookup-keymap/with-spaces ()
> + (let ((map (make-keymap)))
> + (define-key map [menu-bar foo-bar] 'foo)
> + (should (eq (lookup-key map [menu-bar Foo\ Bar]) 'foo))))
> +
> (ert-deftest describe-buffer-bindings/header-in-current-buffer ()
> "Header should be inserted into the current buffer.
> https://debbugs.gnu.org/39149#31"
Please add tests where the symbols use non-ASCII characters.
Also, what about the existing calls to Flookup_key from C: do they all
need to go through the added processing, or could some of them be
satisfied by calling lookup_key_1?
This change needs a NEWS entry.
Thanks.
next prev parent reply other threads:[~2021-10-13 11:59 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-23 8:39 bug#50752: 28.0.50; easy-menu-define lowers the menu-bar key Shuguang Sun via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-23 17:15 ` Juri Linkov
2021-09-23 21:45 ` Lars Ingebrigtsen
2021-10-12 22:22 ` Stefan Kangas
2021-10-13 11:28 ` Lars Ingebrigtsen
2021-10-13 11:59 ` Eli Zaretskii [this message]
2021-10-13 12:04 ` Lars Ingebrigtsen
2021-10-13 12:19 ` Stefan Kangas
2021-10-13 12:58 ` Lars Ingebrigtsen
2021-10-13 15:26 ` Stefan Kangas
2021-10-13 15:42 ` Lars Ingebrigtsen
2021-10-19 3:22 ` Stefan Kangas
2021-10-19 3:40 ` Lars Ingebrigtsen
2021-10-19 3:52 ` Lars Ingebrigtsen
2021-10-19 11:56 ` Eli Zaretskii
2021-10-19 12:07 ` Lars Ingebrigtsen
2021-10-19 12:17 ` Lars Ingebrigtsen
2021-10-19 12:37 ` Eli Zaretskii
2021-10-19 12:45 ` Lars Ingebrigtsen
2021-10-19 13:24 ` Lars Ingebrigtsen
2021-10-19 16:01 ` Eli Zaretskii
2021-10-19 15:41 ` Eli Zaretskii
2021-10-19 15:57 ` Lars Ingebrigtsen
2021-10-19 16:12 ` Eli Zaretskii
2021-10-19 16:15 ` Lars Ingebrigtsen
2021-10-19 16:21 ` Lars Ingebrigtsen
2021-10-19 16:30 ` Eli Zaretskii
2021-10-19 17:12 ` Lars Ingebrigtsen
2021-10-19 17:37 ` Eli Zaretskii
2021-10-19 18:21 ` Lars Ingebrigtsen
2021-10-20 11:28 ` Eli Zaretskii
2021-10-20 11:55 ` Glenn Morris
2021-10-24 20:11 ` Stefan Kangas
2021-10-25 13:06 ` Lars Ingebrigtsen
2021-10-25 13:19 ` Eli Zaretskii
2021-10-25 13:21 ` Lars Ingebrigtsen
2021-10-25 13:51 ` Eli Zaretskii
2021-10-25 13:55 ` Lars Ingebrigtsen
2021-10-25 14:12 ` Eli Zaretskii
2021-10-26 8:38 ` Stefan Kangas
2021-10-26 13:04 ` Eli Zaretskii
2021-10-26 20:24 ` Stefan Kangas
2021-10-27 14:00 ` Eli Zaretskii
2021-10-28 5:29 ` Stefan Kangas
2021-10-28 7:33 ` Eli Zaretskii
2021-10-28 8:06 ` Stefan Kangas
2021-10-28 9:35 ` Eli Zaretskii
2021-10-28 10:49 ` Stefan Kangas
2021-10-28 12:49 ` Eli Zaretskii
2021-10-28 20:44 ` Stefan Kangas
2021-10-21 2:45 ` Lars Ingebrigtsen
2021-10-21 7:26 ` Eli Zaretskii
2021-10-21 13:04 ` Lars Ingebrigtsen
2021-10-20 7:45 ` Lars Ingebrigtsen
2021-10-20 12:24 ` Eli Zaretskii
2021-10-19 11:43 ` Eli Zaretskii
2021-10-19 21:54 ` Stefan Kangas
2021-10-20 12:59 ` Eli Zaretskii
2021-10-13 16:09 ` Eli Zaretskii
2021-10-15 5:59 ` Eli Zaretskii
2021-10-15 18:34 ` Stefan Kangas
2021-10-19 3:18 ` Stefan Kangas
2021-09-23 22:28 ` Glenn Morris
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=837dehp248.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=50752@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=shuguang79@qq.com \
--cc=stefan@marxist.se \
/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).