GNU bug report logs - #33695
27.0.50; which-function reports wrong imenu information

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Alex Branham <alex.branham <at> gmail.com>
Cc: 33695 <at> debbugs.gnu.org
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.