all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: npostavs@users.sourceforge.net
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 9898@debbugs.gnu.org
Subject: bug#9898: 24.0.90; doc of :key-sequence
Date: Fri, 24 Mar 2017 23:22:56 -0400	[thread overview]
Message-ID: <87ziga11m7.fsf@users.sourceforge.net> (raw)
In-Reply-To: <8738jsaktq.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Sat, 08 Feb 2014 21:58:41 -0800")

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>> (elisp) Extended Menu Items
>>
>> "`:key-sequence nil'
>>  This property indicates that there is normally no key binding
>>  which is equivalent to this menu item.  Using this property saves
>>  time in preparing the menu for display, because Emacs does not
>>  need to search the keymaps for a keyboard equivalent for this menu
>>  item.
>>
>>  However, if the user has rebound this item's definition to a key
>>  sequence, Emacs ignores the `:keys' property and finds the keyboard
>>  equivalent anyway."
>>
>> Should that `:keys' be `:key-sequence'?  Since when do we override :keys
>> with whatever the command is bound to?
>
> Looking at the code, it looks to me that the documentation is wrong
> here.  But I might be wrong.  The function in question that uses this
> stuff is `easy-menu-convert-item-1'.  Somebody should take a look and
> decide.

I think the relevant code is in `parse_menu_item' of keyboard.c,
`easy-menu-convert-item-1' is only constructing menu items, not
interpreting them.

As far as I can tell, `:key-sequence nil' doesn't actually do anything
different from just not specifying `:key-sequence' at all (with the
minor exception that passing both `:keys STRING' and `:key-sequence nil'
causes the `:keys STRING' to be ignored).  So I propose just removing
both `:key-sequence nil' paragraphs.

parse_menu_item (Lisp_Object item, int inmenubar)
{
  Lisp_Object def, tem, item_string, start;
  Lisp_Object filter;
  Lisp_Object keyhint;
  int i;

  filter = Qnil;
  keyhint = Qnil;
  [...]
          /* Parse properties.  */
          while (CONSP (item) && CONSP (XCDR (item)))
            {
              tem = XCAR (item);
              item = XCDR (item);
        [...]
              else if (EQ (tem, QCkey_sequence))
                {
                  tem = XCAR (item);
                  if (SYMBOLP (tem) || STRINGP (tem) || VECTORP (tem))
                    /* Be GC protected. Set keyhint to item instead of tem.  */
                    keyhint = item;
                }
        [...]
    /* The previous code preferred :key-sequence to :keys, so we
       preserve this behavior.  */
    if (STRINGP (keyeq) && !CONSP (keyhint))
      keyeq = concat2 (space_space, Fsubstitute_command_keys (keyeq));
    else
      {
      [...]
        if (CONSP (keyhint) && !NILP (XCAR (keyhint)))
          {
            keys = XCAR (keyhint);
            [...]
          }

        if (NILP (keys))
          keys = Fwhere_is_internal (def, Qnil, Qt, Qnil, Qnil);





  reply	other threads:[~2017-03-25  3:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-28 18:48 bug#9898: 24.0.90; doc of :key-sequence Drew Adams
2014-02-09  5:58 ` Lars Ingebrigtsen
2017-03-25  3:22   ` npostavs [this message]
2021-07-16 13:52     ` Lars Ingebrigtsen

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

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

  git send-email \
    --in-reply-to=87ziga11m7.fsf@users.sourceforge.net \
    --to=npostavs@users.sourceforge.net \
    --cc=9898@debbugs.gnu.org \
    --cc=larsi@gnus.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.