GNU bug report logs - #50067
Context menus

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Juri Linkov <juri <at> linkov.net>, Tak Kunihiro <homeros.misasa <at> gmail.com>, tkk <at> misasa.okayama-u.ac.jp, Lars Ingebrigtsen <larsi <at> gnus.org>, 50067 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#50067: Context menus
Date: Sat, 21 Aug 2021 12:57:23 +0200

(Reply to multiple messages)

21 aug. 2021 kl. 11.42 skrev Alan Third <alan <at> idiocy.org>:

> GNUstep, and I believe NEXTstep and old school macOS, allows you to
> "tear off" menus and leave them on screen as sort of custom toolbars.
> Hence the title on each menu.
> 
> Emacs doesn't support this with the main menus (it was the source of a
> crash, so I removed it), but I don't know if it's something we should
> support. I suspect not because once Emacs updates the menus it
> probably can't handle clicks on old ones.

Thank you, I pushed the removal of the default "Select" title: titles will still be there if given explicitly. If this causes trouble for Gnustep, then we'll reinsert the default title for that platform only.

21 aug. 2021 kl. 01.31 skrev Dmitry Gutov <dgutov <at> yandex.ru>:

>> * If I start emacs -Q and enable context-menu-mode, right-clicking on an identifier in an elisp buffer still doesn't produce the Find Definition entry, presumably because xref hasn't been loaded. Shouldn't it be arranged to be autoloaded somehow, which is how xref works when invoked by keystrokes?
> 
> I wonder what could be the reason for that. It would seem the menu should handle autoloaded commands fine. Even the visibility predicate should work: xref-find-backend is autoloaded as well.

It was just a (featurep 'xref) test which didn't seem to be needed; as you say, all the functions involved are autoloaded and I have verified that xref will indeed be loaded when the menu is used the first time. Pushed to master.

>> * `xref-make-match` requires (contrary to its doc string) its LOCATION argument to be of type `xref-file-location`, but some backends may only be able to make an `xref-buffer-location`. Would anyone object to changing the :location slot of `xref-match-item` to have type `xref-location`? I don't see how it could hurt.
> 
> Makes sense to me, seems like an accident. I've done this change locally, no obvious bugs fell out.

Thank you, fixed on master.

Also pushed:

* Previous patch that adds "Find References" to the menu; it seemed to be the right thing to do.
* A fringe arrow is now used to indicate the current position in the *xref* buffer
* Messages added to assuage the boredom of users while searching for references. Could be moved, rephrased, made optional or removed altogether, but it did look a lot better than freezing for a long time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.