What to do about dtags?
Closed this issue · 6 comments
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.
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?
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?
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.
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.
Let's nuke 'em.
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?