bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50067: Context menus


From: Mattias Engdegård
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@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@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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]