GNU bug report logs - #33870
27.0.50; xref-goto-xref not configurable

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 25 Dec 2018 20:53:01 UTC

Severity: minor

Found in version 27.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: João Távora <joaotavora <at> gmail.com>
Cc: 33870 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Fri, 04 Jan 2019 02:07:10 +0200
>>>> 2. makes the xref buffer non-obtrusive like *Completions*
>>>>    in xref--show-xref-buffer;
>> What do you think about allowing only xref-find-definitions
>> to display a narrow xref window below the original window?
>
> I don't know.  Can I get back the original behaviour easily?  If so,
> how?

This should be easy using a new display action.

> I ask because the assumption that xref-find-definitions produces a small
> number of lines is really quite brittle.  Generic functions can have
> many, many methods.  In Emacs, cl-print-object has 10 definitions lines,
> but that could/should easily grow as anyone who devises a new type of
> object can write a cl-print-object for it.  In a Common Lisp system
> CL:PRINT-OBJECT usually has a ton of methods (and I'm trying to write a
> CL IDE that uses xref.el)

In my experience 10 lines is an exception.  Even with more lines the
completions-like xref window remain pretty usable.

> If it's part of the API, it should really be named
> window-display-buffer.  I'm just making sure it isn't an implementation
> detail for which Martin reserve the to change at any time.

I agree, window--display-buffer is more public towards other packages
and could be renamed.

>>> Perhaps you want window.el to export a function that encapsulates
>>> all/some of this cruft to pass as ACTION.
>> Yes, creating a composite display action would be a good thing to do.
>
> And can you create one such composite display action that brings exactly
> the current *xref* behaviour?  Or does one such thing already exist?

It's as easy as moving components of the particular display action
from the recent patch into a separate function.

>>> Or maybe put that function in xref.el.  But as I said above, I think we
>>> also need a function that brings back the current default.
>> I propose to use the new function only for xref-find-definitions.
>
> OK, but I would say this is a separate request:
>
> * This bug is about making the xref.el window-popping behaviour
>   configurable using display-buffer-alist&friends while keeping the UI.
>   That goal is now apparently within reach;
>
> * The goal of changing the default UI for a certain part of xref-*
>   commands is a different one, which I don't necessarily oppose, but it
>   should be discussed and implemented separately.

Actually the request was about making xref windows more configurable.
I could rename the subject if necessary, or create a separate request
for more discussion.




This bug report was last modified 6 years and 35 days ago.

Previous Next


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