Maybe revisit using xref-after-jump-hook instead of consult-after-jump-hook

[dhashe]

I noticed that there was some prior discussion of this in #59.

As far as I understand, the reason not to use xref-after-jump-hook was because the set of hooks that you would want to invoke for previewing a buffer could be a subset of the set of hooks that you would want when jumping for real, which makes sense to me.

This came up for me in the context of: emacs-lsp/lsp-mode#4803

The issue there is that lsp-headerline-breadcrumb-mode would need to add a function to consult-after-jump-hook in order to get breadcrumbs on previewed buffers, in addition to adding a function to xref-after-jump-hook.

Since it has been awhile since #59, I wanted to confirm if the logic for having consult-after-jump-hook separate from xref-after-jump-hook still holds, and whether it is expected from your end that a project like lsp-mode that wants to run actions on previewed buffers needs to add to consult-after-jump-hook in addition to xref-after-jump-hook.

[minad]

I wanted to confirm if the logic for having consult-after-jump-hook separate from xref-after-jump-hook still holds, and whether it is expected from your end that a project like lsp-mode that wants to run actions on previewed buffers needs to add to consult-after-jump-hook in addition to xref-after-jump-hook.

I think it still holds, but feel free to investigate. I think the problem is also that xref is not always loaded in the context of Consult.

[dhashe]

I thought about this some more.

I think the problem is also that xref is not always loaded in the context of Consult.

I think that it's definitely correct for most consult-* commands to invoke consult-after-jump-hook, but the question would be whether consult-xref should also invoke xref-after-jump-hook when previewing. We can rely on xref being loaded in the context of consult-xref.

But I also think that the answer is still "no", because consult-xref doesn't do a real xref jump when previewing, and because the user may or may not want any of the things that commonly happen on real xref jumps (pulsing, re-centering, or anything else) to happen during a preview.

It makes sense to me for consult to provide a tool (consult-after-jump-hook) that lets users decide what happens on previews independently of what happens on real xref jumps.

The specific problem I'm facing with lsp-headerline-breadcrumb-mode is still tricky but I think that it's best solved downstream of consult.

Thank you.

[minad]

Thanks for investigating. Yes, actually I just tried a few hours ago to additionally run the xref hooks from consult-xref--preview. As you say, the problem is that we are not doing a "real" jump. Consult needs fine control over the hooks executed during preview, to prevent adverse effects. Even the pulsing done by xref by default is already too much for the preview imho. So yes, this needs to be resolved downstream. Note that in the end when the "real" jump is performed, the xref hooks will be executed.

[minad]

The specific problem I'm facing with lsp-headerline-breadcrumb-mode is still tricky but I think that it's best solved downstream of consult.

Note that you can also resolve it in your user configuration by adjusting consult-after-jump-hook and maybe document the tweak somewhere, in the Consult or LSP wiki.

[dhashe]

Note that you can also resolve it in your user configuration by adjusting consult-after-jump-hook and maybe document the tweak somewhere, in the Consult or LSP wiki.

Good point. I may try to document it if I can't get it fixed in lsp-mode. For now, in case anyone in the future comes across this discussion and just wants the snippet to add to their user config, this is what you want:

(add-hook 'lsp-headerline-breadcrumb-mode-hook
          (lambda ()
            (if lsp-headerline-breadcrumb-mode
                (add-hook 'consult-after-jump-hook #'lsp-headerline--check-breadcrumb nil t)
                (remove-hook 'consult-after-jump-hook #'lsp-headerline--check-breadcrumb t))))