[Github-comments] [geany/geany] Ctags sync, part 1 (#1160)

[Jiří Techet]

@b4n I have a few questions. First, forgot to mention the patches at the beginning are yours from

https://github.com/b4n/geany/commits/ctags-tag-entry

I had to recreate them because of the new ctags location and added attribution in the comment. Hope it's fine with you.

Second, our ctags now uses these glib calls:

g_malloc
g_free
g_fopen
g_try_malloc
g_strv_length
g_strerror
g_realloc
g_stat
g_lstat
g_warning

Is it OK to convert them to corresponding C stdlib or POSIX calls which uctags uses? My feeling is these were introduced as part of some "let's use glib calls everywhere in Geany" commit but we should keep ctags separate from Geany and have as little changes as possible compared to uctags. Is there any danger of mixing glib functions and their POSIX variants? (My guess is no as these seem to be just thin wrapper around the POSIX calls but I might be wrong.)

This leads me to another glib thing - GRegex. I know Nick introduced it to fix some prformance problem on Windows at that time (which might be gone by now) and personally I'd prefer to revert it back to GNU regex to avoid extra diffs to uctags. We now have just 3 regex parsers:

- HTML
- Cobol
- Actionscript
- (R has an ifdef allowing it to switch between regex parser and hand-written parser but we don't use the regex part at the moment)

Cobol and Actionscript are "who cares" but HTML is definitely important and would badly deserve a hand-written parser because the regex parsers will always be too slow. For comparison, all *.hpp files from boost take 5s to parse; boost's HTML documentation takes 15s to parse. I think creating a super-simple hand-written HTML parser that does just the same as the regex parser shouldn't be that hard and would be worth it (I might do it in the future unless @elextr beats me ;-).

Yeah and finally the "merge soon" I mentioned was just relative to other patches affecting the ctags directory - it meant only "merge sooner than anything else in ctags" otherwise we get bad conflicts.

---
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/pull/1160#issuecomment-237510285
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160804/7d558d56/attachment.html>