Autocompletion not invoked in-place after exit

[GoogleCodeExporter]

Incompleted commands do not invoke autocomplete after the menu has been 
clicked-off from.
Examples:
1. "prin" will invoke the AC menu, however if click-off (clicked-outside the 
menu) the menu will not reappear upon clicking Down (or Up), as one might 
expect.
2. The same goes for incomplete commands that refer to methods, such as 
"random. shuffl".

At the same time, Down and Up do not retain the 'recent commands' 
functionality, and in essence function as unassigned.

The whole AC menu exit and re-invocation is in my mind a bit unintuitive (in 
general, not in IEP specifically), and am not sure what's the best way to 
handle it. In the context of shells it also raises the issue of retrieving 
commands history etc. so some clever solution might be due.

Original issue reported on code.google.com by zaha...@gmail.com on 12 Mar 2013 at 6:07

[GoogleCodeExporter]

Should note AC operates as usual if backspacing and re-typing, but it's a 
circumvention rather than a solution.

Original comment by zaha...@gmail.com on 12 Mar 2013 at 6:09

[GoogleCodeExporter]

To be honest, I don't really see the problem. But maybe I'm just too used to 
the current mechanism. 

In order to re-show the AC after it has been hidden is not straightforward. 
Perhaps the user intended to hide it. When should it be shown again? If it 
would be shown as soon as the cursor is located at the end of the incomplete 
word, it would be annoying. Further, there is no way to reliably detect whether 
a word is incomplete.

Therefore I think that the current mechanism is not so bad; it starts to help 
you as soon as you are typing a word. There has also been discussion to show 
the AC only when the user explicitly asks for it (see issue 134).

Can you perhaps be more specific of how you think AC can be improved?

Original comment by almar.klein@gmail.com on 12 Mar 2013 at 10:35

[GoogleCodeExporter]

Not when placed at the end of a word, but when replaced there and after Up or 
Down have been typed - that's the common AC implementation. See for example 
here: http://jqueryui.com/autocomplete/
Type "Pyth" then click away, and the menu will disappear. Click on the text box 
again then type either Up or Down - the menu will reappear with the same 
contents.

The situation with IEP at the moment is that the Up and Down keys behave as-if 
unassigned the moment you click away, neither autocompleting nor fetching 
recently entered commands.

Original comment by zaha...@gmail.com on 13 Mar 2013 at 3:25

[GoogleCodeExporter]

In the jquery example, there is no usage for the up/down keys. In IEP there is; 
in the editor the user probably just wants to move the cursor one line 
above/below.

In the shell I don't think you'd want such behavior either, because of 1) 
consistency and 2) command history.

The command history does work: 
  * type "isinstnace(3, str)" and press enter
  * type "isinstnace(3, int)" and press enter
  * now type "isi" and make the autocomp disappear
  * put the cursor at the end of "isi" and press up/down

Original comment by almar.klein@gmail.com on 13 Mar 2013 at 9:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

That's true.

The command history complicates it, indeed, but otherwise I think consistency 
would only benefit from it since it does work the same way elsewhere.

Ah, yes - it's the same problem we've discussed elsewhere - commands that are 
not in the command history are thus not replaced. Try typing some new command 
that you haven't typed before, off-click before completing and then click back 
- the command history will not function and neither will AC.

Original comment by zaha...@gmail.com on 13 Mar 2013 at 10:01

[GoogleCodeExporter]

As part of migrating our code repositories from Googlecode
to Bitbucket, all IEP issues are now tracked at 
https://bitbucket.org/iep-project/iep/issues

To view this issue, use this link (with X replaced by the issue number):
https://bitbucket.org/iep-project/iep/issue/X

Issues on Bitbucket can be created by anyone. Commenting on issues requires 
login via Bitbucket, Google, Twitter or Github.

Original comment by almar.klein@gmail.com on 11 Jun 2013 at 2:40

• Changed state: Moved