Author Topic: Fighting with autocomplete  (Read 21215 times)

Tom Plunket

  • Community Member
  • Posts: 14
  • Hero Points: 0
Fighting with autocomplete
« on: November 06, 2007, 04:00:40 AM »
I would love autocomplete if it did what I wanted.  Unfortunately, it usually does that which I do not want, so I try turning it off.  Unfortunately, it still does what I don't want.

My 12.0.3 setup: Options->File/Exn Setup->C
Auto-Complete "Enable" unchecked, everything else grayed.
Context Tagging: List members has all checked except "completion on space"  Parameter information has auto-display and auto-list checked.  Goto to symbol declaration, and show info for symbol under mouse.

I think this is everything.

Unfortunately, it still stabs knives in my back at every turn.

One example: I have a struct named "CameraParameters".  I start using it in a new file, and I read those parameters and jam them into a camera object, so I type "camera" (note, lower-case 'c' even!).  I type -> or . and my "camera" is changed to "CameraParameters".

This sort of thing happens all of the time.  I like Slickedit otherwise.  I just don't understand why it does auto-completion when I have everything turned off.

Another example, today I was writing some debugging code.  I typed
  printf("Network

Then hit <space> because I was going to write "Network packet received", but SlickEdit for some reason saw a type used in the local scope (not even a variable, a type!) and replaced the quote-Network with unquoted NetworkStatus.  Huh?  When is a type a valid parameter to anything?

Finally, what really got me fuming yesterday...

I'm typing a comment.  I type a backslash followed by a space or a newline, oh thanks for putting a # right in there.  Not what I wanted.  Not anything I've EVER typed EVER in my life.  What the heck is it doing "auto-correcting" my comments?

I like the members being listed.  I just don't want them filled in unless I press something that doesn't belong in the source file.  Like, say, 'tab'.  Space, comma, parenthesis, I want none of these to trigger autocomplete because autocomplete is usually wrong.

How can I achieve this?

thanks.

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: Fighting with autocomplete
« Reply #1 on: November 06, 2007, 11:37:47 AM »
I've unckecked 'Insert selected' in the 'Auto-complete' tab to avoid possible auto-insertions of autocompleted items. Maybe it's a workaround for you since autocomplete is not completely disabled.
HS2

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
Re: Fighting with autocomplete
« Reply #2 on: November 06, 2007, 04:07:07 PM »
I like to better understand the typing in a comment problem.  Can you give enough information that I can reproduce this problem?

Tom Plunket

  • Community Member
  • Posts: 14
  • Hero Points: 0
Re: Fighting with autocomplete
« Reply #3 on: November 06, 2007, 08:05:13 PM »
I've unckecked 'Insert selected' in the 'Auto-complete' tab to avoid possible auto-insertions of autocompleted items. Maybe it's a workaround for you since autocomplete is not completely disabled.
I have that entire panel disabled, and Insert Selected is unchecked anyway.

Tom Plunket

  • Community Member
  • Posts: 14
  • Hero Points: 0
Re: Fighting with autocomplete
« Reply #4 on: November 06, 2007, 08:06:54 PM »
I like to better understand the typing in a comment problem.  Can you give enough information that I can reproduce this problem?
My repro steps (autocomplete is completely disabled, remember):

Create a new C/C++ file.
enter '/* \' (slash star space backslash)
hit <enter>
Find that a # is inserted instead of a newline.

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: Fighting with autocomplete
« Reply #5 on: November 06, 2007, 08:49:28 PM »
Seems to be an issue also with Auto-Complete enabled. In this case a completion list with various comment formatting tokens is displayed and no entry is selected. On <ENTER> the 1st entry is inserted which shouldn't happen (if nth. is selected).
@Tom: As a workaround to avoid any add. actions on SPACE / ENTER you could use SHIFT-SPACE/ENTER.

HS2

jbhurst

  • Senior Community Member
  • Posts: 405
  • Hero Points: 33
Re: Fighting with autocomplete
« Reply #6 on: November 06, 2007, 08:56:15 PM »
Just for the record, when I try the '/* \' + Enter sequence (in a fresh vanilla CUA config, with AutoComplete disabled), I don't get any funny behavior. 

However, I have experienced some weird auto completions in the past, most notably in XML files.

Regards

John Hurst
Wellington, New Zealand



hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: Fighting with autocomplete
« Reply #7 on: November 06, 2007, 09:10:12 PM »
Found that unchecking Auto-list members (???) avoids the ENTER-after-BACKSPACE-in-comment trouble.
HS2

Tom Plunket

  • Community Member
  • Posts: 14
  • Hero Points: 0
Re: Fighting with autocomplete
« Reply #8 on: November 07, 2007, 06:19:54 PM »
Unchecking auto-list members appears to fix at least some of the problems.  ...which is disappointing because the actual listing of members seemed to be the one part of autocomplete that actually worked.  I guess it just pulls in a bunch of functionality which does not.  :(

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6826
  • Hero Points: 526
Re: Fighting with autocomplete
« Reply #9 on: November 08, 2007, 02:12:27 PM »
In order to reproduce the comment "/* \<Enter>" problem you need to remove the */ after the cursor. 

I just made a change in V13 so that Enter just does an Enter if there is no item selected.  This is similar to how the Space key works.

I make no warranties to this change just yet.  This needs to be tested in a major release.  Backup up your original codehelp.e before making any changes.


Replace the last line of the "case ENTER:" in the function codehelp_key() in codehelp.e:
Change:
         ListHelpReplaceWord();
To:
      if (ginListHelp && !gListHelp_pending &&
          gListHelp_ctltree_wid.p_AlwaysColorCurrent) {
         ListHelpReplaceWord();
      } else {
         DoDefaultKey(key,true);
      }

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: Fighting with autocomplete
« Reply #10 on: November 08, 2007, 02:49:00 PM »
Thanks a lot Clark - looks good so far. If I recognize sth. strange I'll post a report.

There is one more maybe related issue I've seen.
When doing e.g. if - completion incl. auto-surround and I use 'autocomplete' (which is bound to a key) to complete a variable in the expression I can't use the cursor keys to select an item in the autocomplete list.
The surround box/marker is changed instead. If I use TAB to complete up to the longest uniq. prefix the auto-surround mode is cancelled. Same happens on TAB if 'use TAB to cycle thru list' is configured.
That's different to the behaviour of 'list-symbols' when used to complete the expression where the the auto-surround mode is retained. I think it's better if the behaviour of both features would be consistent except there is a good reason that this is not possible.

HS2

hs2

  • Senior Community Member
  • Posts: 2761
  • Hero Points: 292
Re: Fighting with autocomplete
« Reply #11 on: December 11, 2007, 04:08:23 PM »
FYI: The latest hotfix r21 contains an updated 'codehelp.e' but unfortunately Clark's patch was not implemented.
So don't forget to re-patch it after installing hotfix r21 ;)
HS2

Dennis

  • Senior Community Member
  • Posts: 3955
  • Hero Points: 515
Re: Fighting with autocomplete
« Reply #12 on: December 11, 2007, 09:00:34 PM »
Let's return to the original problem:  The case where you type "camera" and get "CameraParameters" unexpectedly.  I'll fill in the missing details necessary to actually reproduce the problem.

1) You are calling a function and attempting to pass camera->something; as an argument.

Code: [Select]
    someFunction( camera->something );
2) When you type the open paren for the function, because you have it enabled, auto-list-parameters comes up.

3) For whatever reason, your variable "camera" is not in the list.
    I'll assume for the sake of argument it is due to preprocessing not being configured.

4) CameraParameters is in the list.

5) You proceed to type "camera", which is a lowercase prefix match of "CameraParameters".

6) Nothing in the list matches exactly, so SlickEdit smartly selects the case-insenstive match,
    assuming that you were saving yourself time by typing the lowercase prefix of the symbol.
    Sure, we could disable this feature, but it would essentially cripple list-members because
    you would have to type symbols in their exact case to find anything.  Note also, if you
    type a mixed case identifier, as long as the language is case-sensitive, list-members will
    be case-sensitive.  Basically, if you took the time to type something in upper-case (more
    effort than just typing lowercase), we assume that you know what you want.

7) "CameraParameters" is selected in the list, and you type "-".
    Because CameraParameters was selected, and displayed as such,
    we make the silly assumption that it is what you want and we
    replace "camera" with "CameraParameters".

So, there you have what is really happening.  It has nothing to do with the "Auto Complete" feature -- this is Auto-list compatible parameters -- and it is doing exactly what it should be expected to do at each point.

The problem goes away entirely if your "camera" variable is actually visible to the tagging engine.  I believe there is four word saying about the relative quality of results being directly proportional to the quality of the inputs.

We could cripple list-members and make it force you to do more work in order to complete a symbol, but I imagine that the people who have trained themselves to take advantage of the way it works now would be rather upset.

On your end, you could go ahead and turn off "Auto-list compatible parameters" and "Auto-list compatible values", because these features are probably not helping you anyway, and you can bring them up on demand with a Ctrl+Comma anyhow.

evanratt

  • Senior Community Member
  • Posts: 300
  • Hero Points: 23
Re: Fighting with autocomplete
« Reply #13 on: December 11, 2007, 09:30:02 PM »
If you look at some of my past posts you can see that I've also had issues where autocomplete does not seem to do what I want it to, or what I believe it should do. I have had this same situation come up and, while I do understand your analysis Dennis, it leaves me with two questions:

1) I am confused by the fact that even with Auto-completion completely disabled you say that SlickEdit can replace what we're typing due to the Auto-List Compatible Parameters and Auto-List Compatible Values settings. I guess I was under the impression that these settings only affect whether or not parameters are listed, and Auto-complete would be responsible for actually replacing text as I type. I find that I do like to have compatible parameters and values listed, but unless I hit tab I don't want them to automatically replace what I'm typing. Is it possible to show these lists, but have nothing selected in them by default, so they don't stomp the text that's already there?

2) This may be a separate but related issue. I am not convinced that the list is missing the intended variable (in this case, "camera") due to valid reasons such as preprocessing not being configured. I have had very similar issues arise where the correct variable is not listed (and there is nothing special being done with it; no macros being used, etc), but a tag from a completely separate file and scope, for instance, is selected instead, with the only connection between the two being the first few letters of the variable name. Next time this happens I'll double check and make sure there isn't any preprocessing or anything that could be confusing the tagging.

Dennis

  • Senior Community Member
  • Posts: 3955
  • Hero Points: 515
Re: Fighting with autocomplete
« Reply #14 on: December 11, 2007, 11:15:46 PM »
Apparently a lot of people are confused about the difference between auto-complete, auto-list members, and auto-list parameters.

They share some visual cues, but they are separate mechanisms.

FYI:  We do have plans to consolidate the mechanisms in a future, future release, but it is no trivial task, so for the time being it's best to learn how they work.

If you pay attention, and learn what to expect in what situations, it's easy to know which mechanism you are dealing with.

The additional visual cues in auto-complete are obvious.  But more obvious is the fact that auto-list members and auto-list parameters are triggered when you type certain characters.  For example, the member access operator or an open parenthesis.  Type "->" in C and you should be expecting auto-list members to come up.

Auto-complete is a "hinting" system.  It will display a list of choices, but does not complete anything unless you hit Tab or select an item in the list and hit Enter.  It will not select anything automatically, unless you configure it to "Auto select unique items".

Auto-list members (and the other Context Tagging auto-list options) are more aggressive, because they work on the assumption that they have already done a fair amount of symbol analysis and they are attempting to display all the symbols visible in your current scope.  Of course, if you tagging isn't configured correctly, symbols might be missing.  Unfortunately, Context Tagging can't know about symbols it was never told about.

Auto-list members has been implemented this way since version 4.0 of Visual SlickEdit.  Now is not a good time to change it's behavior in a fundamental manner.  The corner cases that would be fixed would be overpowered by the mainstream cases that would be crippled.  When we merge the features, we can pull auto-list members under the umbrella of auto-complete, and it will therefore become a hinting system (and never replace text unless you specifically select something from the list).

Finally, to address your second concern:  Auto-list parameters has a lot of work to do.  It not only finds symbols in your current scope, but it also analyzes their types and determines if they might be assignment compatible with the current argument for the function you are calling.  To make that problem more tractable, we limit the search to locals, class members, and globals in the current file.  So, yes, there may be a global in another file that auto-list parameters doesn't see.

If you feel like auto-list parameters or auto-list compatible values are getting in your way, you should turn them OFF.  You can easily bring them up on-demand by hitting Alt+Comma.  The main reason that we have them ON by default is so that users will learn that they exist.  Otherwise, these great features would be completely buried.