Re: Code completion proposal for GtkSourceView



(sorry for dupe, forgot to cc the list)

Hi,

how about using tags files... don't most editors make use of ctags
generated tags files? Doing a binary search on the content in tags
files (which are stored presorted I believe), is supposedly pretty
efficient even for "realtime" look ups.

Maybe a simple interface to tags files is all that's necessary.

IMHO i think at the very most, gtksourceview should only have api's
for stuff like bringing up calltips at the current cursor position,
populating calltips (gtksourceview itself shouldn't have to know what
to populate), handling events within calltips, completing the word
after user chooses a option from the calltip, etc.

In reality, I don't think this stuff is gtksourceview specific
enough... should just separate it out so you can use it from regular
textviews and other stuff... and keep gtksourceview simple and clean
:-P

a naive approach might be: for starters, to create a library that...
initializes itself by loading a tags file (or whatever), and given a
word/fragment, returns a list of possible matches... then it's up to
the app to do whatever with it... you can then build up from this to
create some gtk specific interface... code for this should already
exist in many text editors @_@


On Fri, 14 Jan 2005 12:53:07 +0100, Emmanuele Bassi <ebassi gmail com> wrote:
> Hi all,
> 
> After givin to the subject some thought, and seeing that this item has
> been onn the wishlist for some time now, I've drafted a simple
> proposal for implementing code completion in GtkSourceView.
> 
> The draft is written here:
> http://devel.emmanuelebassi.net/papers/gtk-source-completion-engine.html
> 
> And in Wiki form here:
> http://wiki.emmanuelebassi.net/index.php?GtkSourceCompletionEngine
> 
> +++
> 
> Since knowing how to complete code is something that it's bound to
> each language (e.g. in C you could just match each word under the
> cursor, optionally opening each #included file - but in Java you have
> to scan through the packages and match the namespace before the point;
> the same in Perl, but matching the double colon), we cannot implement
> a code completion for each language. Plus, code completion could
> require language introspection, or metadata handling; thus, code
> completion is a tricky and per-language thing.
> 
> Basically, the idea is to create a base class, and let each user
> implement its own code completion method (with a basic "string match"
> for a start); we could also offer a standard UI for showing the
> alternatives.
> 
> I plan to write up some preliminary code this weekend. If anyone has
> suggestions or objections, I'd like to hear those (here on the list or
> on the wiki). :-)
> 
> Regards,
>  Emmanuele.
> 
> --
> It is against the grain of modern education to teach children to program.
> What fun is there in making plans, acquiring discipline in organizing
> thoughts, devoting attention to detail, and learning to be self-critical?
>                 -- Alan Perlis
> _______________________________________________
> gnome-devtools mailing list
> gnome-devtools gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devtools
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]