which-function deficiency in C mode

which-function deficiency in C mode

[Sam Steingold]

GNU Emacs 22.0.50.6 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2006-06-19 on quant8

which-function (and thus which-function-mode) does not determine the
"function name" correctly in the following common cases:

typedef struct foo {
  int bar;
  char* baz;
} foo_t;

typedef struct {
  int bar;
  char* baz;
} foo_t;

note that "struct foo" appears to be handled properly.

I cannot figure out what is amiss (it is even unclear what facility -
add-log and imenu - is used when).

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://openvotingconsortium.org http://thereligionofpeace.com
http://pmw.org.il http://camera.org http://honestreporting.com
Only adults have difficulty with child-proof caps.

Re: which-function deficiency in C mode

[Richard Stallman]

    which-function (and thus which-function-mode) does not determine the
    "function name" correctly in the following common cases:

    typedef struct foo {
      int bar;

Since which-function-mode uses the results of imenu, I think the first
step is to see whether imenu parses that wrong.  Could you do that?

    typedef struct {
      int bar;
      char* baz;
    } foo_t;

That is surely hopeless.

Re: which-function deficiency in C mode caused by imenu

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-06-24 04:31:26 -0400]:
>
>     which-function (and thus which-function-mode) does not determine the
>     "function name" correctly in the following common cases:
>
>     typedef struct foo {
>       int bar;
>
> Since which-function-mode uses the results of imenu, I think the first
> step is to see whether imenu parses that wrong.  Could you do that?

imenu produces largely garbage:

(("*Rescan*" . -99) ("strerror" . #<marker at 1229 in util.h>)
("DEBUG_WARN" . #<marker at 1307 in util.h>) ("int" . #<marker at 5029
in util.h>) ("int" . #<marker at 5071 in util.h>) ("int" . #<marker at
5113 in util.h>) ("int" . #<marker at 5155 in util.h>) ("void"
. #<marker at 5197 in util.h>) ("member" . #<marker at 5235 in util.h>)
("merge_sort" . #<marker at 5462 in util.h>) ("heap_sort" . #<marker at
5532 in util.h>) ("mapl" . #<marker at 6121 in util.h>))

for the file <http://www.podval.org/~sds/data/util.h>

specifically,

typedef struct list_t {
  struct list_t *next;
  void *data;
} List_t;

is not represented.

>     typedef struct {
>       int bar;
>       char* baz;
>     } foo_t;
>
> That is surely hopeless.

trivially handled:
no id after struct => forward-sexp to skip over {} and get the next id.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://thereligionofpeace.com http://honestreporting.com http://memri.org
http://truepeace.org http://pmw.org.il http://jihadwatch.org
(lisp programmers do it better)

Re: which-function deficiency in C mode caused by imenu

[Richard Stallman]

I think imenu understands mainly function declarations, for C.
And it probably only understands them when the function
name starts in column 0.  For a header file it is likely to get
totally confused.

What you want would be a major upgrade in the capabilities.
Not something we can entertain for now.