[Github-comments] [geany/geany] Upstream or alternative solution for ctags regex parsers (#2119)

Masatake YAMATO notifications at xxxxx
Thu Apr 25 10:31:21 UTC 2019


@elextr,

> If it was a proper library then both Geany and ctags and others should be able to use it as a library. There should be no need to import ctags code into Geany at all if it was a proper library, just link to the API.

This is ideal but I would like to focus on the interface between Geany. 
I don't have enough skill to design and maintain a new library API.
3 ~ 5 years ago, I declined to make ctags a library in the above reason.
However, libctags is already there. I don't have to design an API.
I think I can do keeping the interface.
The benefit of moving the library to u-ctags project is that I, an active ctags developer, can take care of keeping the interface working.

The following figure shows the position of libctags in us.

![libctags-layer](https://user-images.githubusercontent.com/77077/56729424-3bef4980-6790-11e9-8fbc-11ba9975d689.png)

For a while, the libctags is only for Geany. I assume Geany may incorporate ctags code via git subtree.

@techee
> I could create some dummy client application for uctags which uses the same functionality we need in Geany to make sure some internal change in uctags doesn't remove or break what we need.

YES! It is what we need. Let's give an impressive name the dummy client. This client drives us.
My idea is 'minigeany' or 'microgeany'. The client is at uctags side so we can add test cases on it.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2119#issuecomment-486618279
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20190425/88351e76/attachment-0001.html>


More information about the Github-comments mailing list