>On Tue, 19 Mar 1996 rmenon@tisl.ukans.edu wrote:
>>
>> Has anyone noticed that emacs bombs while trying to scan etags files
>> of the kernel ? (or does no one use such tools anymore ? Its really useful
>> for browsing through lots of code)
>
>Quite frankly, I consider GNU emacs to be just about the most broken
>program there _is_ in any unix environment, and I refuse to cater to any
>GNU emacs bugs.
No need to, this one appears to have been fixed in the most recent
version of Emacs, pretest 19.30.95 from the morning. (Probably
there still is a problem with newlines in file names as with diff,
patch, find, and many other programs.) Similar problems exist
with ctags, the pendant in the VI[?] world...
Note, however, that there are more problems with commas and other
funny characters in file names. Copying a file with a comma to a
msdos fat file system caused msdog to become severely upset last
I tried. Yes, I know: msdog is broken, broken, broken.
I think the relevant files should be renamed. It's kind-of like
someone having a file name with a slash or a NUL complaining about
Linux not being able to handle it. There really are no strong
reasons for the commas in the file names in question, so as long
as it doesn't hurt anyone I'd say stay within a safe character
set. This also makes it clear that the text "files a, b, and c"
refers to three files, no more and no less.
Morten
> The fix to the etags problem is probably to use "strrchr()" instead
> of "strchr()" [...]
Unlikely. str[r]chr() is mostly used in C code. :-)