> My suggestion is to tailor the code of gtags and htags, make light > version of them: for gtags-lite and htags-lite, they read from stdin > or a file for file-list, the format is : index filepath lang > and gtags-lite will create/update GTAGS database and htags will produce > rendered html-files.
It is a good idea. GLOBAL is large and complex enough to need to be modularized. If we make gtags a shell script, the simplest version may be like this: +------------------------------------------------------- |#!/bin/sh | |case $GTAGS_FIND in |'') GTAGS_FIND=gtags-find;; # gtags-find: default file list maker |esac |$(GTAGS_FIND) | gtags-lite +------------------------------------------------------- $(GTAGS_FIND) should generates file list like this? [File list format] +------------------------------------------- |<language type>\t<path of source file>\n |... Regards, Shigio 2017-02-21 13:33 GMT+09:00 Jun Sheng <[email protected]>: > Hi, > I partly agree with your points. > libmagic and file are general purpose tools to detect file types, and they > are week in detecting source file type. > but we can improve it by updating the magic-database or create a > customized magic-database for this purpose. > > On the other way, current gtags/htags codes bare a heavy duty on deciding > which language the file they are currently processing is, this makes the > code very complex and hard to patch. > eg, for my patch, I have traced around 10 functions in 4 files to modify. > > My suggestion is to tailor the code of gtags and htags, make light version > of them: > for gtags-lite and htags-lite, they read from stdin or a file for > file-list, the format is : > index filepath lang > and gtags-lite will create/update GTAGS database and htags will produce > rendered html-files. > > functionalities like guess and decide language can be put into a separate > tool which can be compatible with current gtags.rc file and be integrated > with find then output a filelist consumable by gtags-lite. > > > > On Tue, Feb 21, 2017 at 11:44 AM Shigio YAMAGUCHI <[email protected]> wrote: > >> Hi, >> >> I recognize libmagic as an equivalent of file(1). >> Can it decide language type correctly? >> Can it accommodate new languages? >> Isn't it better to use it as a tool for creating file lists? >> >> Regards, >> Shigio >> >> >> 2017-02-21 10:39 GMT+09:00 Jun Sheng <[email protected]>: >> >> specifying the filetype in commandline is a good idea, but why not going >> further, make gtags read file type when read file list ? >> >> and I attached a patch, which will guess file type using libmagic >> >> On Mon, Feb 20, 2017 at 3:16 PM Shigio YAMAGUCHI <[email protected]> wrote: >> >> Hi, >> > Hi, >> > There, what about adding file-type guessing when the source file does >> not have a suffix? >> > >> > Currently when the file doesnot have a suffix, gnu global wont parse it, >> > this is a problem when perl/python ... files. and gtags cant specify >> lang-type on command-line. >> >> You are right. >> Currently, we have a plan to do the following: >> http://lists.gnu.org/archive/html/bug-global/2016-10/msg00003.html >> >> Does this specification fulfill your requirements? >> >> Regards, >> Shigio >> >> >> 2017-02-20 15:45 GMT+09:00 Jun Sheng <[email protected]>: >> >> Hi, >> There, what about adding file-type guessing when the source file does not >> have a suffix? >> >> Currently when the file doesnot have a suffix, gnu global wont parse it, >> this is a problem when perl/python ... files. and gtags cant specify >> lang-type on command-line. >> >> >> _______________________________________________ >> Bug-global mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/bug-global >> >> >> >> >> -- >> Shigio YAMAGUCHI <[email protected]> >> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 >> >> >> >> >> -- >> Shigio YAMAGUCHI <[email protected]> >> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 >> > -- Shigio YAMAGUCHI <[email protected]> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
_______________________________________________ Bug-global mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-global
