Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324754

Summary: Auto-completion inserts random symbols
Product: [Tools] CDT Reporter: Victor Yagusevich <vic9101987>
Component: cdt-editorAssignee: Project Inbox <cdt-editor-inbox>
Status: ASSIGNED --- QA Contact: Jonah Graham <jonah>
Severity: minor    
Priority: P3 CC: zeratul976
Version: 7.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Victor Yagusevich CLA 2010-09-08 10:55:38 EDT
Build Identifier: 20100617-1415

To reproduce these bugs you should create a source file with only one line:

#include "my.h"

Bug I: Auto-completion writes additional symbols '__' before showing proposals.
#include !{cursor}!"my.h" ==> #include __!{proposals list}!"my.h"

Bug II: Auto-completion writes characters 'de' and doesn't show proposals
#inclu!{cursor}!de "my.h" ==> #include !{cursor}!de "my.h"

Where !{cursor}! is a cursor position from where auto-completion was executed, !{proposals list}! is a pop-up window with a list of proposals which appears after executing auto-completion.

See also bug 324384

Reproducible: Always
Comment 1 Anton Leherbauer CLA 2010-09-13 04:21:13 EDT
(In reply to comment #0)
> Bug I: Auto-completion writes additional symbols '__' before showing proposals.
> #include !{cursor}!"my.h" ==> #include __!{proposals list}!"my.h"

This can happen if only macros starting with "__" are defined.  The default is to insert the common prefix of all proposals (see preferences C/C++ > Editor > Content Assist).  I.e. it's a feature.

> Bug II: Auto-completion writes characters 'de' and doesn't show proposals
> #inclu!{cursor}!de "my.h" ==> #include !{cursor}!de "my.h"

That's a (minor) bug.
Comment 2 Nathan Ridge CLA 2017-01-02 20:03:09 EST
(In reply to Anton Leherbauer from comment #1)
> > Bug II: Auto-completion writes characters 'de' and doesn't show proposals
> > #inclu!{cursor}!de "my.h" ==> #include !{cursor}!de "my.h"
> 
> That's a (minor) bug.

This is not specific to #includes; it also happens for keywords.

For example:

  constex!{cursor}!pr int waldo = 42;

gives:

  constexprxpr int waldo = 42;

Basically, content assist doesn't realy look at what's after the cursor, only what's before.

I agree with Toni that this is a low-priority bug.