[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `etags' bug?

From: Paul Pogonyshev
Subject: Re: `etags' bug?
Date: Wed, 15 Dec 2004 04:57:32 +0200
User-agent: KMail/1.4.3

> >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
> version:
> $ 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)
    switch (opt)
        /* 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

_in principle_.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]