[Geany-devel] Geany FTW - better autocompletion

Colomban Wendling lists.ban at xxxxx
Sat Nov 20 23:32:20 UTC 2010


Hi!

Le 18/11/2010 01:18, Lex Trotman a écrit :
>>>> You could try using strace to check what file IO is being done.
>> Yes, may be a good idea :) Hope there is not toooooooo much open calls
>> in other places... (I'm a bit scared though :-')
> 
> Well be sure to use -eopen on strace and I'd only have one file at a
> time open in Geany for the tagmanager to crunch, that way you should
> only get less than ten files opened unless tagmanager is being
> naughty.
Thanks, works very well!

So, my patch seems to work fine, no extra IO on tag update :) (at least
with C, Python, PHP and SH)

However, there are the following opens at each sidebar update:

open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-namespace.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-class.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-method.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-member.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-struct.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-struct.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-macro.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-var.png",
O_RDONLY) = 16
open("/usr/local/share/icons/hicolor/16x16/apps/classviewer-other.png",
O_RDONLY) = 16

I've not investigated, but this is probably bad for near-real-time updates.

>>> If I only would have more time, I'd like to dig into this...
>> Almost the same here... but I'll try to move it up in my todo-list.
I've worked a bit on this (well, not that much indeed, but still), and
the point I got last summer seems quite interesting!
As said above, the tagmanager seems not to do any more IO on tag update
(if we enable buffer updates in Geany, of course), so it should be quite OK.

However, there are still part of the tagamanager that uses plain C file
IO calls (fopen, fread & co); but I'm unable to find what exactly should
be ported to MIO, and what should not. Either because I don't know what
the code actually does, or because the tagamanager creates FILE streams
itself, so Geany cannot give it a buffer anyway.
Actually, I've ported what I understood parsers are using, and
everything that was touched by this modification.
So, if anyone has any clues on what else should be ported and what is
not needed, please go ahead an either port it or tell me :)


So, 2 patches attached:

First, an update of the patch that ports (a part of) the tagmanager to
MIO for it to apply to trunk (no code change, but the patch didn't apply
for cosmetic reasons) [1]. It is 0001-First-tagmanager-move-to-MIO-I-O.patch

Second, a toy patch to:
1) activate buffer parsing (a simple #if change)
2) adds IDLE call on editor notification for live parsing. The code is a
bit ugly, but that's only to test the thing.

Testing, reviewing & co appreciated :)


An important this that should be done IMHO before live symbol updating
could be really done is to avoid flickering in the symbol table. For
example, don't clear the whole list and recreate it, but rather simply
remove/add the necessary items.


Regards,
Colomban


[1] Unfortunately, since the repository I cloned on Gitorious isn't
updated since June, I can't use this repository for updates. So I do
this on my local copy for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-First-tagmanager-move-to-MIO-I-O.patch
Type: text/x-patch
Size: 41958 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20101121/60e54b98/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Update-tags-in-almost-real-time.patch
Type: text/x-patch
Size: 1439 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20101121/60e54b98/attachment-0001.bin>


More information about the Devel mailing list