helm-bibtex-candidates-formatter not applied (?)
Opened this issue · 11 comments
Hi there,
I get the following strange behaviour. When I startup helm-bibtex all is in order:
But when I search (sometimes) I get:
Which seems to suggest that somehow helm-bibtex-candidates-formatter is no longer applied?
Moreover, if I start helm-bibtex from a buffer in say pdf-view-mode then everything works as expected, but if I start helm-bibtex from a buffer in latex-mode I get the behaviour described above. Is there some logic in bibtex-completion or helm-bibtex that might be the likely culprit? As it stands, I struggle to see where I'd start with debugging this.
Hang on, is this meant to be a feature? If I trigger helm-bibtex from inside \cite{|} (cursor at |) then I get the behaviour reported above, if I trigger it from \cite{}| then I get the behaviour I expect.
It's a bug that I observed as well. But it happens rarely and (I think) only when I fire up helm-bibtex and very quickly start typing search terms. Since we haven't changed anything recently in helm-bibtex, I suspect that it's a problem in helm. I would have posted an issue there but I simply didn't find time to do it and to investigate this a bit more in depth.
Same problem here. The occurrence seems to depend on the text at point. If there is nothing under cursor, then everything goes well. I have checked the code of 'helm' and found something related to thing-at-point, but cannot figure out how to fix it.
@hitswint I can't reproduce a dependency on whether or not something is at point. The error also occurs rarely recently. Really hard to debug. If you can reproduce it more reliably, you could try git dissect on helm to see which helm commit introduced the problem
After some digging, i finally ended up with the function "helm-guess-filename-at-point". There are two format functions applied on the original candidates: helm-bibtex-candidates-formatter and helm-fuzzy-highlight-matches. The two functions are applied sequentially on the original candidates. With the first one applied, it returns as expected. But the return value of latter function depends on the things at point because of the "helm-guess-filename-at-point" in it. When there is nothing under cursor, helm-guess-filename-at-point returns nothing, and when there is something like "high", it returns "/anonymous@high". This behavior ruins the return value of the format function. When i remove helm-guess-filename-at-point from helm-fuzzy-highlight-matches, everything runs normally.
I am using version 28, the bug happens frequently. "helm-guess-filename-at-point" may be optimized for version 29, which is told by the docstring of the function. So i think this is not the bug of helm-bibtex.
Thank you for investigating this. Please file an issue with the helm project (if you haven't done that yet) and perhaps reference this issue there.
Thank you for investigating this. Please file an issue with the helm project (if you haven't done that yet) and perhaps reference this issue there.
My bad, i just found that i have added an advice to "helm-guess-filename-at-point", in which the ffap-machine-p-local is modified to 'accept. I think that's why i encountered this problem frequently. I will remove the advice to see if this is still a bug.
After i remove the advice on "helm-guess-filename-at-point", helm-bibtex runs normally most of the time. But when i call it in dired-mode, the bug still exists. When i redefine "helm-guess-filename-at-point" to always return nil, the bug disappears.
Perhaps there is no perfect definition of "helm-guess-filename-at-point", it should vary with use case. That's why i added an advice to it. Refer to https://www.n16f.net/blog/investigating-a-ffap-issue-in-emacs. So maybe we can just redefine it in the helm-bibtex, after all, we don't need to match file name in helm-bibtex.
Sorry, I probably don't fully understand what's going on, but if this issue is caused by a bug in helm. shouldn't we try to get it fixed there instead of adding a workaround in helm-bibtex?
Yeah, you are right. I will file an issue with helm to see if they can fix it.
This has been fixed in helm.
emacs-helm/helm#2597