Identifying DEFUNs in which-func-mode

Identifying DEFUNs in which-func-mode

[Juanma Barranquero]

IMO, defining this function somewhere

(defun which-func-identify-DEFUN ()
  (save-excursion
    (save-match-data
      (beginning-of-defun)
      (if (looking-at "DEFUN +(\"[^\"]+\", +\\(F[^,]+\\),")
          (match-string-no-properties 1)
        nil))))

and adding it to `which-func-functions' for C files in the Emacs tree
would be useful.

Alas, it can't be added through .dir-locals.el, because hooks are
unsafe as directory-local variables. One (not particularly elegant)
way to fix it would be to add to C mode the function and a boolean
variable to set it; that variable could be safely set in
.dir-locals.el. Surely others can think of better ways.

But before taking the trouble, does anyone else think that it would be
useful to have this in standard Emacs, or it is the intersection of
Emacs developers and which-func-mode users too small?

    Juanma

Re: Identifying DEFUNs in which-func-mode

[Eric M. Ludlam]

On Wed, 2009-10-07 at 03:27 +0200, Juanma Barranquero wrote:
> IMO, defining this function somewhere
> 
> (defun which-func-identify-DEFUN ()
>   (save-excursion
>     (save-match-data
>       (beginning-of-defun)
>       (if (looking-at "DEFUN +(\"[^\"]+\", +\\(F[^,]+\\),")
>           (match-string-no-properties 1)
>         nil))))
> 
> and adding it to `which-func-functions' for C files in the Emacs tree
> would be useful.
> 
> Alas, it can't be added through .dir-locals.el, because hooks are
> unsafe as directory-local variables. One (not particularly elegant)
> way to fix it would be to add to C mode the function and a boolean
> variable to set it; that variable could be safely set in
> .dir-locals.el. Surely others can think of better ways.
> 
> But before taking the trouble, does anyone else think that it would be
> useful to have this in standard Emacs, or it is the intersection of
> Emacs developers and which-func-mode users too small?

If you enable semantic-mode in Emacs (via the recent integration) and
also enable EDE (via the integration), then Emacs will identify your
Emacs sources as a project, and setup the parsing system to recognize
DEFUN macros.  A piece of Semantic that supports which-func mode is,
AFIAK, not yet integrated as the file is waiting for papers.  The
which-func support there is, however, not dependent on that paperwork
and could be used.

Anyway, the Semantic parsers put overlays on tags, so looking up which
function you are on is very fast.

You can see how the which-func support works at the bottom of this file:

http://cedet.cvs.sourceforge.net/viewvc/*checkout*/cedet/cedet/semantic/semantic-imenu.el

This support was added a long time ago, and judging by the description
you posted, should be re-written to some new APIs anyway.  I'd be glad
to see that old code refreshed as needed, as which-func is exactly the
type of functionality that CEDET excels at.

On the flip-side, if you enable the CEDET tools, you could enable
semantic-stickyfunc-mode instead of which-func.  IMO this is a much
slicker way of doing the same thing, but only if you don't use your
header line for other tasks already.

Eric

Re: Identifying DEFUNs in which-func-mode

[Juanma Barranquero]

On Wed, Oct 7, 2009 at 04:29, Eric M. Ludlam <eric@siege-engine.com> wrote:

> If you enable semantic-mode in Emacs (via the recent integration) and
> also enable EDE (via the integration), then Emacs will identify your
> Emacs sources as a project, and setup the parsing system to recognize
> DEFUN macros.

Interesting.

> Anyway, the Semantic parsers put overlays on tags, so looking up which
> function you are on is very fast.

Cool. There's a comment in which-func.el:

;; TODO LIST
;; ---------
;; [...]
;;     2. This package should be realized with the help of overlay
;; properties instead of imenu--index-alist variable.

so it's nice to know Semantic is doing better and faster (not that I
doubted it :-)

> You can see how the which-func support works at the bottom of this file:
>
> http://cedet.cvs.sourceforge.net/viewvc/*checkout*/cedet/cedet/semantic/semantic-imenu.el
>
> This support was added a long time ago, and judging by the description
> you posted, should be re-written to some new APIs anyway.  I'd be glad
> to see that old code refreshed as needed, as which-func is exactly the
> type of functionality that CEDET excels at.

I've just taken a cursory glance, but yes, it seems like the advice
stuff for which-func at the end of semantic-imenu.el could be
simplified by using which-func-functions.

BTW, there's no semantic/imenu.el on the Emacs CVS, nor any reference
to which-func in the lisp/cedet/ subtree. Why?

> On the flip-side, if you enable the CEDET tools, you could enable
> semantic-stickyfunc-mode instead of which-func.  IMO this is a much
> slicker way of doing the same thing, but only if you don't use your
> header line for other tasks already.

It's pretty clear that at some not-to-distant future I should take the
time to learn about the CEDET tools...

All in all, what I proposed could still be useful for developers not
wanting to use EDE, etc. But perhaps is just not worth the trouble.

    Juanma

Re: Identifying DEFUNs in which-func-mode

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> BTW, there's no semantic/imenu.el on the Emacs CVS, nor any reference
> to which-func in the lisp/cedet/ subtree. Why?

Waiting for paperwork from Paul Kinnucan.

Re: Identifying DEFUNs in which-func-mode

[Eric M. Ludlam]

On Wed, 2009-10-07 at 04:44 +0200, Juanma Barranquero wrote:
> On Wed, Oct 7, 2009 at 04:29, Eric M. Ludlam <eric@siege-engine.com> wrote:
> ...
> All in all, what I proposed could still be useful for developers not
> wanting to use EDE, etc. But perhaps is just not worth the trouble.

It was not my intention to divert the original conversation.  It seemed
like an opportunity to explain one of the corners that CEDET can help
with.

Eric

Re: Identifying DEFUNs in which-func-mode

[Juanma Barranquero]

On Wed, Oct 7, 2009 at 18:23, Eric M. Ludlam <eric@siege-engine.com> wrote:

> It was not my intention to divert the original conversation.  It seemed
> like an opportunity to explain one of the corners that CEDET can help
> with.

No diversion at all. I wasn't aware of what CEDET had to offer, so
when I say that my proposal is just not worth the trouble, I'm
serious.

Thanks for taking the time to explain your work.

    Juanma