Messages in this thread | | | Date | Wed, 20 Mar 1996 11:54:10 -0800 (PST) | From | Grant Reaber <> | Subject | Re: [minor style issue] filenames and C++ reserved words in header files |
| |
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) > 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
| |