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

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

bug#33870: 27.0.50; xref-goto-xref not configurable


From: João Távora
Subject: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Fri, 4 Jan 2019 07:41:38 +0000

On Fri, Jan 4, 2019, 00:16 Juri Linkov <juri@linkov.net wrote:

> I don't know.  Can I get back the original behaviour easily?  If so,
> how?
This should be easy using a new display action.


Ok. Make sure to include that in your next patch, and make it the default.

> 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.

I'm trying to tell your that your experience which seems limited to xref in emacs lisp, is not a good measure of how xref-find-definitions is used in the wild. xref-find-definitions came from something called slime-find-definitions, and has mostly its UI. SLIME is a CL IDE  where 100+ long complicated definitions are the norm, not the exception.  And one day SLIME could decide to use xref.el.

> 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.

Good. Include this in your next patch.

>>> Perhaps you want 
> 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.

OK.

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.

Don't change subject, create a separate request. Submit a second patch that makes xref windows configurable and leaves the default UI unchanged. Then install that patch closing this bug. In the separate discussion we can continue the discussion of the UI changes you want.

Actually I should have made this separation clearly earlier.

João

reply via email to

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