> Secondly it'd be better to standardize the format so that an indexer
> for a language can be written outside of GNU Global. Many languages
> have better lexer and parser tools in themselves, PHP, perl, javascript,
> Erlang, python etc. etc. Being able to reuse these mature and
battle-tested
> code makes a high-quality indexing tools with little efforts.

The interface for that is already prepared, that is, plug-in parser interfac
Please see the directory named 'plugin-factory/' in the GLOBAL package.
It already includes two practical plug-in parsers except for a nop parser.

> One reason is fewer DB files to clutter a user's projects.

I agree. However, should not it be done regardless of API?

Shigio


2014-11-10 10:51 GMT+09:00 Leo Liu <[email protected]>:

> On 2014-11-10 09:42 +0900, Shigio YAMAGUCHI wrote:
> > It is not recommended for the front-end to read tag files directly,
> > because the realization method of tag files may be changed one day.
>
> In practice few care about this, particularly when existing tools don't
> meet their needs. Secondly it'd be better to standardize the format so
> that an indexer for a language can be written outside of GNU Global.
> Many languages have better lexer and parser tools in themselves, PHP,
> perl, javascript, Erlang, python etc. etc. Being able to reuse these
> mature and battle-tested code makes a high-quality indexing tools with
> little efforts.
>
> There is hardly any interest in writing/rewriting a language's
> lexer/parser for GNU Global and even if they do they have a hard time
> keep it in sync with the language evolution.
>
> > For the moment, there is not such plan. What is the reason you hope it?
>
> One reason is fewer DB files to clutter a user's projects.
>
> > Thank you for having try.
> > Shigio
>
> Thanks,
> Leo
>



-- 
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

Reply via email to