Re: SQLite3 API support

[Shigio YAMAGUCHI]

> 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 <address@hidden>:

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 <address@hidden>

PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3