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

Previous Next

Full log

Message #104 received at 33870 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 33870 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Fri, 4 Jan 2019 07:41:38 +0000

[Message part 1 (text/plain, inline)]

On Fri, Jan 4, 2019, 00:16 Juri Linkov <juri <at> 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

>

[Message part 2 (text/html, inline)]

Previous Next

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