GNU bug report logs -
#35737
xref--original-command
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Tue, 14 May 2019 20:58:02 UTC
Severity: wishlist
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#35737: xref--original-command
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 35737 <at> debbugs.gnu.org.
--
35737: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=35737
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> "revert buffer" sounds like undoing changes, and we're repeating a search
> and refreshing (or maybe reloading) the results.
"revert buffer" is a standard term for updating an Emacs buffer.
> I get the idea, but not the goal. I know why we'd want to make
> xref-find-definitions and project-find-regexp to behave differently. The
> rest, I'm not so clear.
>
> Anyway, I was hoping my efforts in improving the default behavior would
> benefit your goals as well, but it seems the split between xref--show-xrefs
> and xref--show-defs goes against them. That's too bad.
Thanks for your efforts. Your recent changes would be useful for other goals,
e.g. making the xref output to use grep-like output format.
>> The goal was to improve the default behavior to make customization easier.
>
> That's why I added xref-show-definitions-function.
>
> Customizing display-buffer-alist is an arcane art. The hook this variable
> provides should be easier to understand for an average user.
>
> So, to clarify, you're not interested in changing the *visible* default
> behavior, at least for now?
No, not a visual change this time. I'd also close bug#33992 because
it's also leading nowhere. But maybe your recent patch with
xref--definitions-buffer-mode is an improvement, I don't know.
I'm looking at xref from customization's point of view, and I see no more
improvements that could simplify xref customization.
[Message part 3 (message/rfc822, inline)]
Remembering the command that created the *xref* buffer
will allow such customization to treat RET differently,
i.e. it makes sense for RET to quit the transient xref buffer
displayed momentarily while navigating code with xref-find-definitions,
whereas leaving the xref buffer visible while navigating matches
in the xref buffer created by e.g. project-find-regexp:
(define-key xref--button-map [(control ?m)]
(lambda ()
(interactive)
(if (memq xref--original-command '(xref-find-definitions))
(call-interactively 'xref-quit-and-goto-xref)
(call-interactively 'xref-goto-xref))))
Better ideas?
diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index bf999aeb0d..5c38cac164 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -477,6 +477,9 @@ xref--original-window-intent
(defvar-local xref--original-window nil
"The original window this xref buffer was created from.")
+(defvar-local xref--original-command nil
+ "The original command that created this xref buffer.")
+
(defun xref--show-pos-in-buf (pos buf)
"Goto and display position POS of buffer BUF in a window.
Honor `xref--original-window-intent', run `xref-after-jump-hook'
@@ -777,7 +788,8 @@ xref--analyze
(pop-to-buffer (current-buffer))
(goto-char (point-min))
(setq xref--original-window (assoc-default 'window alist)
- xref--original-window-intent (assoc-default 'display-action alist))
+ xref--original-window-intent (assoc-default 'display-action alist)
+ xref--original-command this-command)
(current-buffer)))))
This bug report was last modified 5 years and 351 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.