[Geany-devel] Geany FTW - better autocompletion

Simone Pellegrini spellegrini at xxxxx
Thu Nov 18 08:12:24 UTC 2010

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.

The main problem is whether is a problem for you to have this dependency 
on clang.

cheers, Simone

On 11/18/2010 01:18 AM, Lex Trotman wrote:
> On 18 November 2010 11:10, Colomban Wendling<lists.ban at 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 at herbesfolles.org>  wrote:
>>>>> Le 17/11/2010 15:54, Nick Treleaven a écrit :
>>>>>> On Tue, 16 Nov 2010 17:32:01 +0100
>>>>>> Simone Pellegrini<spellegrini at 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 at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list