bug#33695: 27.0.50; which-function reports wrong imenu information

[martin rudalics <rudalics@gmx.at>]

 >> For me the idea of calculating all function position in a buffer and
 >> afterwards have 'which-func-mode' scan them to find out which function
 >> point is in, strikes me as enormous over-kill.  In particular with
 >> 'syntax-ppss' around which usually should, without any additional
 >> cost, provide the position where the current functions starts via the
 >> 9th element of its return value.  But don't let these rantings
 >> distract you.
 >
 > That won't help with non-lispy languages like R or python though, I
 > don't think.

IIUC 'python-info-looking-at-beginning-of-defun' uses 'syntax-ppss'
while for example 'c-beginning-of-defun' doesn't.

I understand that the implementors of which-func chose the most simple
existing way to get the function point is in.  But it amounts to
having 'beginning-of-defun' always construct a list of the positions
of all function definitions in a buffer to find the first one before
point.  With wich-func a user won't notice the effect because it's
done when Emacs is idle.  Still it's not ecological.

 > Perhaps we should reverse the order of what which-function checks? It
 > currently looks at:
 >
 > 1. which-func-functions
 > 2. imenu--index-alist
 > 3. add-log-current-defun
 >
 > but we could switch those last two. add-log-current-defun should be
 > faster than reconstructing imenu--index-alist.

I think so.  But I'm afraid it's not well supported everywhere.
Anyway, as I already said don't let my remarks distract you.

martin