[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33695: 27.0.50; which-function reports wrong imenu information
From: |
martin rudalics |
Subject: |
bug#33695: 27.0.50; which-function reports wrong imenu information |
Date: |
Thu, 13 Dec 2018 10:01:18 +0100 |
>> 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
bug#33695: [PATCH] Fix which-function reporting outdated information, Alex Branham, 2018/12/19