>
> 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)
> It does'nt seem to like a "," (comma) in a filename and
> drivers/scsi has a couple of files like these (53c7,8xx.c and 53c7,8xx.h).
>
> Basically etags seems to assume that a "," marks the end of the filename
> and gets confused with the filenames 53c7,8xx.c and 53c7,8xx.h in drivers/scsi.
>
> For eg. here's a proper filename line in the TAGS files:
>
> fs/read_write.c,324
>
> and here's what the problem files look like:
>
> drivers/scsi/53c7,8xx.c,2429
>
> After reading this emacs tries to open the file drivers/scsi/53c7
> (which does'nt exist) instead of drivers/scsi/53c7,8xx.c and
> stops scanning with an error message.
Well that's what the entries should look like, right? This isn't an etags
problem but an emacs problem. And it appears not to be a problem at all
in emacs 19.30. (I couldn't reproduce it.) Here is the code emacs uses to
find the file a tag is in once it's already searched to the tag. The
re-search-backward should always match the last comma because the [^\n]+
will suck up as much as it can. I have no idea why the if (looking-at
"./") is there, but it shouldn't normally be executed. Maybe you should
just upgrade to 19.30
(defun etags-file-of-tag ()
(save-excursion
(if (looking-at "./")
(re-search-forward "\\([^\n]+\\),[0-9]*\n")
(re-search-backward "\f\n\\([^\n]+\\),[0-9]*\n"))
(buffer-substring (match-beginning 1) (match-end 1))))
Grant