What to do about dtags?

[lassik]

The dtags script relies on the gema macro processor which is not easy to install on any major OS.

If people are still using dtags, it would probably be a good idea to rewrite it using either Dylan or Emacs Lisp. At a glance, it looks like a job that Elisp would do well at.

[lassik]

etags.regex is another script to generate a TAGS file. etags.regex seems less comprehensive than dtags. Could we port the extra stuff from dtags into etags.regex and keep only the latter?

[cgay]

I wrote etags.regex as a quick hack for the very reason you mention, IIRC. I think it can be deleted. Maybe @housel can comment on how dtags compares to what Open Dylan's recently added export tags command generates?

[lassik]

If the Dylan toolchain itself can write a TAGS file, that will almost certainly be superior to any regexp approximations we can achieve with etags.

[housel]

If the Dylan toolchain itself can write a TAGS file, that will almost certainly be superior to any regexp approximations we can achieve with etags.

Yes, precisely; the compiler has authoritative information about what symbols are being defined that dtags and etags can only approximate. The only inconvenience in letting the compiler do it is the requirement that the compiler actually compile everything you're interested in. It's possible to create projects that do this (win32-environment already uses pretty much everything), though some might feel this is more trouble than simply pointing etags or dtags at a source directory. If there's nobody in this category, though, I have no problem with desupporting etags and dtags.

[cgay]

Let's nuke 'em.

[lassik]

The only inconvenience in letting the compiler do it is the requirement that the compiler actually compile everything you're interested in.

Would it be hard to create a compiler pass that merely parses the code without actually compiling it, and use that for fast generation of a tags table?