Bug 203954

You can expand the items by keyboard using the ALT key (See http://zwabel.wordpress.com/2008/12/10/code-navigation-in-kdevelop4-meet-the-magic-modifier/).

Generally, the minimal completion mode is mainly ment as a kind of 'typing assistant', it doesn't contain any information with the items, and isn't ment to be used for browsing. So why is it such a problem here if the items are there multiple times? At least for the typing assistance, it doesn't make a big difference.

(In reply to comment #1)
> You can expand the items by keyboard using the ALT key (See
> http://zwabel.wordpress.com/2008/12/10/code-navigation-in-kdevelop4-meet-the-magic-modifier/).

Thanks. However, releasing the alt key moves the cursor to the File menu, and pressing arrows while Alt is pressed scrolls the expanded description (documentation), not the cursor across the entries. Are these bugs I should file?

> Generally, the minimal completion mode is mainly ment as a kind of 'typing
> assistant', it doesn't contain any information with the items, and isn't ment
> to be used for browsing. So why is it such a problem here if the items are
> there multiple times? At least for the typing assistance, it doesn't make a big
> difference.

Yes, the thing is, as a typing assistant, it should allow me to quickly scroll and select the desired item. However, as with example above, I have to press the down arrow 5 times just to get to g2(). Since the 5 g() entries do exactly the same, it just doesn't make sense to have them there.

Of course, expanding them shows different results, but I think that could be dealt with some other way. For example, show the duplicates only after expanding (not sure about the details though). The full completion would still show all the signatures.

With the following code:

struct A {
	void g(int) { }
	void g(float) { }
	void g(short) { }
	void g(double) { }
	void g(bool) { }
	void g() { }
	template <typename T> void g() { };
};

the minimal completion could show only "g()", "g(args)", "g<>()", which would really improve the usability of this feature. There are less things to read and select from this way.

The current completion dialog doesn't even show which ones are templates, so the selection process is somewhat blind (choose the sixth "g" to have the template, etc...).

With large classes with lots of overloaded functions the popup gets real messy. For example,

#include <QString>

void f()
{
    QString s;
    s.  // shows 6 compare entries, 18 (!!) arg entries, etc...
}

Releasing ALT should definitely not move you into the file menu.

But ALT+Arrow allows you to navigate within the expanded information, so that one is not a bug.

About the completion: 'Typing assistant' to me means that you type, and at some point maybe press 'enter' to speed it up a bit. Scrolling through a list and selecting an item is not really assisted typing, but rather a kind of 'browsing', and that is what the full completion mode should be used for.

Additionally it could lead to other problems: For example, overloaded functions may return different types, and then the context type-matching cannot pick the correct one any more to highlight entries.

Overall I agree, it would be good if the minimal completion would merge items with the same name at some point. But it's such a low benefit given the needed work that it probably won't happen any time soon.

(In reply to comment #3)
> Releasing ALT should definitely not move you into the file menu.

Filed as bug # 203962.

> About the completion: 'Typing assistant' to me means that you type, and at some
> point maybe press 'enter' to speed it up a bit. Scrolling through a list and
> selecting an item is not really assisted typing, but rather a kind of
> 'browsing', and that is what the full completion mode should be used for.

Yes, but when there are similarily named functions (at least if they start similarily) and you want to select the second one, pressing enter on the first one is not something you want. And to get to the second one, you have to scroll.
Plus, it's a subjective thing. Some people use it only occasionally, and some people use it all time time, as a real fast assistant (especially when not not at expert level with a new API).
It's like "I don't care how many overloads are there, I just want a quick list to choose from, not 18 entries for arg()". Full completion doesn't meet this criteria.

> Additionally it could lead to other problems: For example, overloaded functions
> may return different types, and then the context type-matching cannot pick the
> correct one any more to highlight entries.

I don't think I understand this. By highlight you mean the yellow background that I get when I move the mouse over something? How is that tied to code completion? I thought it was a parser feature - I open a file and it does that, not depending on my choices which I may or may not have made in the past when typing that code.

If you mean that you somehow filter the function list by return type if I type:
int i = a.  // shows only the ones returning int
then I still don't see a problem - you can still filter them and then collapse the similar entries into one.

> Overall I agree, it would be good if the minimal completion would merge items
> with the same name at some point. But it's such a low benefit given the needed
> work that it probably won't happen any time soon.

Well, the work part I understand :)
I think the "low benefit" is a subjective thing though.

*** Bug 215202 has been marked as a duplicate of this bug. ***

Maybe a good way to deal with this could be having a multilevel menu.

First level shows method names without overloads and, if you select one with overloads another level is expanded with all the overloads of that method.