On 11/18/2010 09:24 AM, Lex Trotman wrote:
On 18 November 2010 19:12, Simone Pellegrinispellegrini@dps.uibk.ac.at wrote:
I think these kind of support for code competition are obsolete and there are new tools popping out that can make the work much more easier.
For example I have been working for a long time with the clang-LLVM compiler. Clang is a C frontend and It offers a very easy interface to do code completition on the fly. It's very impressive the way it works and it's really fast. I have developed myself a small project where I integrated the code completition support on a scintilla based editor and it really takes few lines of code.
If you want I can show the code.
All contributions welcome, Clang seems a very fast compiler (and very picky about warnings) the few times I've used it.
But this is of course only a solution for C (and is Clangs C++ working yet?). Still it could be added as a plugin i think.
Clang also supports C++ and ObjectiveC. C++ support is not complete yet but lot of work has been done and soon it will kick ass even for C++ :)
cheers, Simone
Columbans suggestion applies to any tagmanager language.
The main problem is whether is a problem for you to have this dependency on clang.
Probably not a problem for a plugin to have that dependency.
Cheers Lex
cheers, Simone
On 11/18/2010 01:18 AM, Lex Trotman wrote:
On 18 November 2010 11:10, Colomban Wendlinglists.ban@herbesfolles.org wrote:
Le 17/11/2010 23:45, Enrico Tröger a écrit :
On Thu, 18 Nov 2010 09:34:03 +1100, Lex wrote:
On 18 November 2010 04:05, Colomban Wendling lists.ban@herbesfolles.org wrote: > Le 17/11/2010 15:54, Nick Treleaven a écrit : >> On Tue, 16 Nov 2010 17:32:01 +0100 >> Simone Pellegrinispellegrini@dps.uibk.ac.at wrote: >> >>> I really like geany as it uses scintilla, the only feature I feel >>> is missing is the intellisense like code competition for C++. I >>> would like to ask if anyone is working on a better code >>> competition for C++. I am not talking about ctags but something >>> more advanced that can give me code hints on the fly without the >>> need of rebuilding the index. >> I don't think anyone's working on that ATM. There was some work to >> make Geany able to parse tags from memory instead of from disk, but >> it wasn't finished. > Well, I had an attempt a while ago to achieve this [1], but I didn't > finished it already. I used a small library I written for the > occasion, called MIO [2], that replicates C's file IO functions, but > allowing to choose between memory or file IO. This makes the > tagmanager update quite easy. > > BTW almost everything is done, but it needs someone to check whether > it actually work in memory and don't do some FILE I/O (if Geany > correctly demands memory IO, and if the tagmanager doesn't do extra > file IO). Unfortunately, I wasn't sure how to check for this... > (just thinking I may add a debug statement in my IO object creation > functions) 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.
Cheers Lex
Yup. Or simply use stat(1) to check the atime (provided the filesystem in use supports atime) of the opened file.
IIRC, the problem was that the tag manager seems to use some tempfiles in some cases. And such tempfiles are not acceptable for an in-memory parsing, from which we expect real-time parsing. But it's probably easy to at least move these temp files to memory chunks. Need to be investigated deeper.
Though, Lex' suggestion is more secure and can be easily grepped :).
> But I can try to bring this upper in my todo-list, and somebody with > better knowledge of the tagmanager (Enrico? Nick? :D) may want to > help :)
knowledge? me? no no.
Seriously, this looks interesting! Great idea to create MIO!
Thanks, and happy to see you like it :) (but remember, we spoke of this a while ago ;))
Since MIO seems quite small (code-size), we maybe even could distribute as static lib with Geany at the beginning and then a bit later once it used and got stable, separate it as a standalone library.
I actually wrote it partially thinking about using it as a static library because Geany's policy is not to have much dependencies. But I'm of the "share everything" school, so I feel even better with it as a shared library :) About the stability, even though it would be completely blind to think it is stable regarding the few real-world tests I made, I think the test suite should help a lot for this -- and since all tests passed (and still passes I guess!), it should work quite correctly :)
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.
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel