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

Previous Next

Full log

View this message in rfc822 format

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: bug#33870: 27.0.50; xref-goto-xref not configurable
Date: Thu, 03 Jan 2019 22:08:28 +0000

Juri Linkov <juri <at> linkov.net> writes:

> (with-selected-window (display-buffer buf action)
>   with just
> (pop-to-buffer buf action)
>
> but I'm not sure about this change because it could change the current
> behavior.

Didn't test, but that would be bad.  Is this small reduction worth it?

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

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)

>>> -          (display-buffer buf action))
>>> +                 `(,(lambda (buf alist)
>>> +                      (window--display-buffer buf xref--original-window 'reuse alist)))))))
>>>
>>
>> Using internal "--" symbols from window.el is a temporary solution I
>> hope.
>
> Actually this function is not quite internal.  It's intended to be used
> in display actions implemented by packages.

Hmmm, it's used only in lisp/window.el, where it hails from, and in
lisp/windmove.el, where you added it recently.

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.

>> Again, too many --, and seems like a lot of repetition from window.el.
> The distinction between internal and public window functions is quite
> fuzzy.

It shouldn't be.  If a package A uses -- from package B, either A is
going to break soon, or B's API is insufficient.

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

>> Naming that function would be the hardest problem (best I could do is
>> display-buffer-use-completions-like-window).
> Or when naming by not its usage but what it does:
> display-buffer-below-and-resize.

OK.  Better, I guess (if that's really what it does).

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

João

Previous Next

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