Author Topic: Improving code completion to a usable state  (Read 26779 times)

X-Ryl669

  • Guest
Improving code completion to a usable state
« on: May 17, 2005, 12:41:30 pm »
I don't know what are your current plan about improving the code
completion, but this is what I could try to do (please tell me if I'm
wrong)

Current state:
 -  For the code editor you are using wxStyledTextCtrl which, in
turns, uses Scintilla. I've already used Scintilla a while ago, and
I'm familiar with its syntax.
-  For the code completion, you are parsing the source code by
yourself with a home made parser.

What is currently lacking (from my point of view):
 - The code editor could have a lot of features from the last
Scintilla turned on (like brace matching, code block vertical lines,
better coloring)
 - The parsing is quite limited. Maybe you could see ctags.sf.net for
a more complete parser (which still lacks preprocessing).
 - The code completion is really boring to use (if not counter intuitive)

What I could try to do:
1 - Use the parser, when available, to feed a new list of colored
keywords to Scintilla, so that class members, local variables,
functions can have a different style.
2 - Provide a useful code completion, by not only triggering it after
having typed '.' or '->' but also while typing any text (based on
mostly occurring text)
3 - Select the code completion box when pressing right arrow (not only enter or tab)
4 - Add a tooltip when typing a function (what is already called
CallTip by Scintilla) that show the function prototype (like shown in
the current code completion) which highlight the current argument
being typed. I don't know if it is currently possible to quickly get
the comment before the function declaration.
5 - (Harder) provide a go shortcut (or button) that directly goes to
the item-under-the-cursor's declaration. (this is linked with the
previous remark)
6 - (Harder) provide a context sub menu to quickly jump to symbol
declaration in the current file
This requires being able to only parse the current file (or filter the
token list by filename)

Tell me if you've already done this.
For 1), I think I could append some code in the parser OnThreadEnd
method (so that opening the code window is still very quick when no
parsing information is available), and in EditorManager :: Open (or
cdEditor constructor, let me know what is best)). This code will
simply add the list of names to scintilla text editor with a new style
based on their types. The SetKeyWords method of wxStyledTextCtrl
allows creating a new set of styled keyword. Then we should call the
StyleSetxxx methods to change it. I don't want to deal too much with
the dialog boxes, so maybe you will have to add new a configuration
item in the style list editor dialog.
Of course, every time the parser finishes a new step, it will update
the view (maybe there will be flicker here, I don't know, this
requires testing).

For 2), this doesn't requires parsing the current file again. The idea
is to fill a list of already typed word (like English words) sorted by
first letter, and frequency of occurring. When the user start typing a
word (after pressing whitespace like ' ', enter key, tab, etc...), the
list is parsed and if the current typed characters are found in a word
from the list, a tooltip is displayed with the suggested word. What is
cool here, is that because of frequency information, it is possible to
have the best possible match for the user.
This will also require implementing the calltip calling in cbEditor.

3) This is a simple line of code to add the right arrow character to
the selection in the autocomplete thanks to SetFillsUp method of
Scintilla. Currently I don't see that method in wxStyledTextCtrl, so
maybe we will have to add it, or directly call scintilla object
method.

4) I need your comment for this
5) This could be done by adding code in the shortcut handler to parse
the parser token list in order to find the same token, or if numerous
token are available, fill a popup menu with each possible token.
6) Same thing as above.

Please tell me what you think about this

takeshimiya

  • Guest
Improving code completion to a usable state
« Reply #1 on: May 19, 2005, 06:00:58 am »
I think that if you manage to implement all the things that the parser of Visual Assist X do, there isn't need for more.

If you haven't seen you want to take a look, it's a codecompletion plugin for MS Visual C 6/7/.NET and also other languages.

The best and most complete codecompletion plugin that I know, the only drawback it's that is only for MS Visual Studio and isn't opensource.

Here is the site: http://www.wholetomato.com/ It's recommended by wxWidgets team indeed.

Anonymous

  • Guest
Improving code completion to a usable state
« Reply #2 on: June 22, 2005, 09:11:23 pm »
Someone who used Visual Assist X would never want to develop without it :D

takeshimiya

  • Guest
Re: Improving code completion to a usable state
« Reply #3 on: July 27, 2005, 10:01:59 am »
I'm very interested in this

Offline Funto

  • Multiple posting newcomer
  • *
  • Posts: 81
Re: Improving code completion to a usable state
« Reply #4 on: July 27, 2005, 10:18:16 am »
So do I, but no moderator/developper responded to X-Ryl669's suggestion :(

morteoh

  • Guest
Re: Improving code completion to a usable state
« Reply #5 on: July 27, 2005, 11:13:36 am »
It would be nice if the completion wasnt dependent on case, if I have Object::Register, and I type "obje" it should show up in the completion box, also Object::regi should appear. Its kinda annoying ;-)

Also, I agree that you should look to Visual Assist X to see what should be implemented, it completely rocks. (MSVC.NET 2003 standard completion is also good).

- Morten

Offline Profic

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Improving code completion to a usable state
« Reply #6 on: July 27, 2005, 11:27:56 am »
It would be nice if the completion wasnt dependent on case, if I have Object::Register, and I type "obje" it should show up in the completion box, also Object::regi should appear. Its kinda annoying ;-)
Look in settings for code completition plug-in. There are checkbox names "case-sensitive match" (or similiar) and IS checked by default :)
Not fear, nor tears can reach me now, the light seems so clear as the night fades away (c) Tristania - Beyond The Veil

morteoh

  • Guest
Re: Improving code completion to a usable state
« Reply #7 on: July 27, 2005, 11:38:22 am »
Ooops, sorry ;-) (started using CB two hours ago) hehe.

One big thing though, is it possible to have it code-complete methods/macros/classes in ALL include paths? so that std::co would return std::cout.. the setting for GLOBAL include-dirs, doesn't really work, std::co gives me nothing, just std:: gives me std::__ioinit..

Also, when I use #include " is lists every file two times.. is it possible to change this?

Are the new proposed changes going to happen with the plugin already there, or are we talking a new project? I'm interested in coding some of this, since a good IDE with code-completion is one of the things i miss the most about Linux! :) (coming from MSVC.NET/Visual Assist X).

- Morten
« Last Edit: July 27, 2005, 11:43:45 am by morteoh »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Improving code completion to a usable state
« Reply #8 on: July 27, 2005, 05:18:41 pm »
Yiannis told me he'd be taking a break when he published RC1, so maybe he'll answer, maybe he won't ;-)

Code completion is an existing codeblocks plugin, but I haven't looked at the event handling code (the one where the interesting things happen). The problem here is that NOBODY but Yiannis has actually looked at the codecompletion's sourcecode, so we're kinda blind in here.

Anyone (including existing devs) is welcome to work on it :)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Improving code completion to a usable state
« Reply #9 on: July 27, 2005, 06:36:53 pm »
(somehow I must have missed this topic; I can't quite remember it...)

Quote
Yiannis told me he'd be taking a break when he published RC1, so maybe he'll answer, maybe he won't
I 'm gonna be taking a 2-3 weeks long vacation starting some time next week, so I won't be available to answer questions. I hope you don't take it personal ;)

@morteoh:
Currently the parser only follows header files with an extension (.h;.hh;.hpp;.hxx). That's why you don't see the std namespace's classes. They 're not using an extension.
The new proposed changes are not going to happen, unless someone implements them ;)
Sorry, but I don't have the time for this. Some of the x-ryl669 suggestions are simpler, some are harder. The point is that someone needs to sit and implement them. I can fix bugs in this plugin, maybe even add some easy-to-add features but that's about it. The rest of the project needs my attention too and if I work on those suggestions I 'm not gonna have any free time for the rest...
That's the current situation, which of course may change in the future.
And, of course, my help to anyone willing to work on it is a given :)

Finally, my difficulty-rating on x-ryl669's questions:

1) easy to add
2) hard
3) already works
4) hard
5) easy
6) easy

Yiannis.
Be patient!
This bug will be fixed soon...