[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `etags' bug?
Re: `etags' bug?
Wed, 15 Dec 2004 04:57:32 +0200
> >It seems that behaviour of `etags' is broken.
> Dear Paul, I cannot reproduce the behaviour you observe, neither with
> the stock emacs 21.3 etags nor with the latest etags in the CVS. It may
> be a platform-dependent bug; I use a Debian system running on i686.
> Before going on to debug it, make sure you are indeed using the latest
> $ strings ../etags|fgrep 'pot rev'
> @(#) pot revision number is 17.5
> and try to recompile it from scratch, to reduce the possibility that you
> used some unstable library or similar problems.
> If you can reproduce the bug with this version, please contact me, so we
> can find a way to debug this.
I refreshed my CVS working directory and recompiled with optimizations
turned off (`CFLAGS="-g"'.) The behaviour didn't change.
I tried a little debugging and I don't understand how the behaviour could
be as documented. Function main() basically looks like this:
while ((opt = getopt_long (...)) != EOF)
/* store `--language' and `--regex' arguments in `argbuffer' */
for (; optind < argc; optind++)
/* store filenames in `argbuffer' */
Now, I cannot understand how this code can distinguish between
--language none file1 --language auto file2
--language none --language auto file1 file2
Yet in the man page we have
-l language, --language=language
Parse the following files according to the given
language. More than one such options may be intermixed
with filenames. Use --help to get a list of the
available languages and their default filename
extensions. The `auto' language can be used to restore
automatic detection of language based on the file name.
The `none' language may be used to disable language
parsing altogether; only regexp matching is done in
this case (see the --regex option).
Maybe I'm really missing something fundamental.