User setting: invoke autocompletion on demand instead of automatically

[GoogleCodeExporter]

Congratulations on new release! :)

In both interpreter and editor window, when I hit Enter to accept 
autocompletion, it fails to auto-complete, but just inserts newline after 
autocompletion trigger.

If I select autocompletion with mouse-click then it behaves as expected - 
autocompletion is successful

Latest iep on Windows XP

Original issue reported on code.google.com by klo...@gmail.com on 19 Dec 2012 at 4:19

[GoogleCodeExporter]

Use TAB to accept auto-completion. I have marked this as a feature request to 
add the option to autocomplete on ENTER.

Original comment by almar.klein@gmail.com on 19 Dec 2012 at 7:34

• Changed title: User setting: autocompletion on Enter
• Changed state: Accepted
• Added labels: Milestone-Release3.2, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I think this is a tricky thing. The problem as the autocompletion is 
implemented at this moment (being: it appears automatically), is that two 
windows are more or less 'in focus' at the same time: the editor/interpreter 
window and the autocompletion popup. Whether the Enter key is processed by any 
of the windows is therefore not very clear to the user. It is now always 
processed by the editor/interpreter, but the arrow keys are processed by the 
popup, although they have a very functional use in the editor/interpreter as 
well. This is, in my opinion, not intuitive. Moreover, my reaction time is 
approximately equal to the delay time of the autocompletion window, resulting 
in ambigious results (if I'm slightly faster typing {"d" Arrow-up}, I get my 
own history entry starting with 'd', if i'm just a little too slow, I get the 
autocompletion window showing everything starting with 'd'. If I'm really 
lucky, I get both (my own history line as well as the autocompletion, which at 
that moment don't match anymore).

In my opinion, the only true way to solve the problem, is to make sure that the 
user 'actively chooses which window processes the key event', which can be done 
by showing the autocompletion popup window after a specific keystroke (I 
suggest 'tab'). The popup then gets full focus, and will process all keys 
(including arrows and the enter key).

I am aware that this is majorly different from how it is now, and therefore a 
choice could be provided to the user, between two different behaviors for 
autocompletion:
* "Always show autocompletion popup window",
which is approximately as it is at this moment. As soon as the 
editor/interpreter detects something which could be autocompleted, a popup 
window appears. Arrow keys, home, end, page-up/down and tab are processed by 
the popup as they are now (home and end added to the current list). The enter 
key indicates a newline in the editor/interpreter. Escape hides the 
autocompletion window. After any of these keys is pressed (indicating that the 
user wants to interact with the popup), the enter key is also processed by the 
popup and functions identically to the tab key. In order to show the difference 
in behavior of the enter key, the blue background indicating the currently 
selected word in the popup should be gray if the enter key is not processed by 
the popup (indicating that this window 'does not really have focus').

* "Show autocompletion popup after pressing Tab"
After pressing Tab, the autocompletion popup shows up and gets complete focus 
and processes all keys. This includes the keys explained above, and also all 
other keys: if the user tries to type a word which does not exist in the 
autocompletion list, the character typed is not added and a warning sound is 
played. 

My favorite option would be the latter; I want to choose myself when the 
autocompletion popup appears (I usually don't want it).

Original comment by gijsvano...@gmail.com on 23 Jan 2013 at 4:33

[GoogleCodeExporter]

What about letting the user choose what keys "complete" the auto completion? 
TAB, ENTER, or both?

I think an option to only show the auto-completion on demand is realistic. 
Perhaps for this often both ENTER and TAB should work by default.

I don't like the enter-becomes-usable-if-first-using-arrow-keys approach. It 
makes the behavior inconsistent, and sometimes you simply want the first choice.

Original comment by almar.klein@gmail.com on 23 Jan 2013 at 9:40

[GoogleCodeExporter]

In error I've added a separate issue for what you're describing, Almar (Issue 
No. 167). I think both of your suggested improvements are good ideas:
- Config: "Always show autocompletion"
If checked: Always pops autocompletion window.
If unchecked: Pops only on TAB
- Config: "Key used for autocompletion"
May be Enter, Tab or whatnot. Personally I feel the Enter is the obvious 
choice, but might be more comfortable for some to use TAB in case the first AC 
option is the right one.

Original comment by zaha...@gmail.com on 27 Feb 2013 at 12:45

[GoogleCodeExporter]

Issue 167 has been merged into this issue.

Original comment by almar.klein@gmail.com on 27 Feb 2013 at 1:16

[GoogleCodeExporter]

Original comment by almar.klein@gmail.com on 6 Mar 2013 at 11:14

• Added labels: Milestone-Release3.3
• Removed labels: Milestone-Release3.2

[GoogleCodeExporter]

Update: Checked how much change is needed to implement this approach. To see 
whether it is feasible to get this into release 3.2 (up next week).

The problem is that we would need to change a bit with respect to which 
components get to process key events first. I'm afraid that we break stuff in 
the process, which is why I defer this to version 3.3. 

Original comment by almar.klein@gmail.com on 6 Mar 2013 at 3:24

[GoogleCodeExporter]

Original comment by almar.klein@gmail.com on 6 Mar 2013 at 3:26

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Good news: I found a relatively simple way to enable configuration of the keys 
that accept the completion.

For now, you can only set this via the logger shell, via:
iep.config.settings.autoComplete_acceptKeys = []  # fill in your setting here

This should be a list of strings (e.g. 'tab', 'enter') or single characters 
(e.g. '(').

The setting to invoke the autocompletion with the tab-key instead of 
automatically, will have to wait. Renaming the issue to reflect the new status.

Original comment by almar.klein@gmail.com on 6 Mar 2013 at 10:23

• Changed title: User setting: invoke autocompletion on demand instead of automatically

[GoogleCodeExporter]

For your information: the config value 
iep.config.settings.autoComplete_acceptKeys should now be a string (not a 
list). See issue 200.

Examples:
  * 'Tab' - default
  * 'Tab space . ('
  * 'Enter Return'

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

[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