bug#35737: xref--original-command

[Dmitry Gutov]

On 16.05.2019 0:04, Juri Linkov wrote:

> I don't propose to change its default behavior.  Just allowing its
> customization would be good.

OK.

But please wait a little, I'd like to show a patch for bug#35702 that 
can also provide a basic for the same distinction in functionality but 
without this variable.

> > Having two buffers that looks basically the same but react to RET
> > differently is not great for usability.
>
> Using display-buffer-in-direction, they don't look the same: after
> customization xref-find-definitions can display the xref buffer below,
> whereas other xref command can display in the side window.

OK. Still look very similar, but at least the behavior appears different 
from the outset.

If you look at Atom's behavior, it actually shows regexp search results 
in a pane below the main area. The same direction where you want to show 
the definitions search result. Just something to keep in mind.

> > To take VS Code as an example (I just to see how it behaves exactly),
> > a search for references opens search results in the sidebar.
>
> Emacs has side windows too.

You mean like Speedbar? That's the part which I didn't exactly like.

> > Whereas for definitions they have both "Go To Definition" and "Peek
> > Definition". The latter shows the definitions kind of inline, in
> > a not-exactly-a-popup kind of way
> > (https://stackoverflow.com/questions/55599177/go-to-definition-in-vscode-preview-window-ruins-the-edito),
> > and there, if you type RET, that triggers navigation to the selected
> > definition. "Go To Definition", when there are several definitions, also
> > switches to "Peek" mode by default.
> >
> > Not sure how best to implement this different kind of display in Emacs, but
> > the idea makes a lot of sense to me.

BTW, there's a third-party package that implements something like that 
for LSP users: https://github.com/emacs-lsp/lsp-ui#lsp-ui-peek

Not sure how likely we are to have this contributed to the core, though.

> > In Sublime, IIRC, for this they used the dropdown from their
> > top-of-the-window command line, the same one that becomes active once one
> > presses Ctrl-P.
>
> We have Completions for the same purpose.

Except we have a UI for it which is expected to be usable without using 
arrow keys. And the completion entries in this case can contain spaces, 
parens, and basically any other characters. They can also be fairly 
long. So completing-read doesn't seem to fit the bill.

I'm open to ideas.