classification
Title: IDLE - tabbing in a string always brings up file completion window
Type: behavior Stage: patch review
Components: IDLE Versions: Python 3.7, Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Tom F, roger.serwy, terry.reedy
Priority: normal Keywords: 3.3regression, patch

Created on 2012-10-11 16:48 by roger.serwy, last changed 2017-06-23 03:58 by terry.reedy.

Files
File name Uploaded Description Edit
issue16198_check_matches.patch roger.serwy, 2012-10-11 18:05 review
Messages (8)
msg172663 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2012-10-11 16:48
Pressing <Tab> while the cursor is in a string will bring up the file completion dialog rather than inserting a tab (or 4 spaces). This behavior is rather annoying in a text editor especially when editing multiline doc strings.

This behavior is new to the 3.3 series as a consequence of issue14937. Arguably, it is a regression.

The logic for bringing up the file completion window when pressing Tab in a string needs to be revised. If the string already contains a partial match, then bring up the window when pressing Tab, otherwise insert a Tab character or spaces.

Alternatively, the Ctrl+Space key sequence will already bring up the file completion dialog, so having an automatic Tab completion behavior is not absolutely necessary.

This issue can also be triggered in the shell. Start a string and then press tab twice.
msg172670 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2012-10-11 18:05
Attached is a preliminary patch. It checks to see if the cursor is on a line within a multiline string in order to avoid displaying the ACW. As a last resort, it checks to make sure that a valid match exists before opening the ACW when mode == COMPLETE_FILES.

A test is still needed. See issue15392.
msg172702 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-10-11 22:13
On windows, one tab brings up the box and in 3.2.3 and 2.7.3 also. Perhaps they should be revised also.

The difference is that in those latter two, <space> dismisses the box whereas in 3.3.0, it does not, making it even more obnoxious. Two more tabs inserts something. Tab within a comment just enters a tab converted to spaces.

I think that maybe tabs within strings should always do the same as within comments. Perhaps one way is enough. (I am guessing that other editors use <tab> for this, so I can see the desire to use it.) There needs to be a way to get tabbing within multiline strings. I did not see 'file completion' in Options/Configure/Keys. Is it there under a different name?

I was puzzled by the example path d:/Biblioteca/Técnica/informática/Python from #14937 until I retried in 3.2.3. In 3.3.0, a / disables filename completion. I reopened this issue.

If one types 'd:\' and there is no d:, <tab> inserts spaces and ^space is ignored. I do not like this kind of inconsistency (or magical behavior shift). If you ask for file names, better to bring up a blank box, or a one-line box [<no matches>].
msg172943 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2012-10-15 04:23
> I think that maybe tabs within strings should always do the same as within comments. Perhaps one way is enough. (I am guessing that other editors use <tab> for this, so I can see the desire to use it.) There needs to be a way to get tabbing within multiline strings. I did not see 'file completion' in Options/Configure/Keys. Is it there under a different name?
Tab completion for file names is a convenience feature in IDLE, since 
file I/O requires specifying file names in strings. The given patch 
restores tabbing within a multiline string.

There is no configuration option for file completion.

>
> I was puzzled by the example path d:/Biblioteca/Técnica/informática/Python from #14937 until I retried in 3.2.3. In 3.3.0, a / disables filename completion. I reopened this issue.
I can use either "/" or "\" for file completion under Windows 7 with 
3.3.0. Try "C:/" instead.
>
> If one types 'd:\' and there is no d:, <tab> inserts spaces and ^space is ignored. I do not like this kind of inconsistency (or magical behavior shift). If you ask for file names, better to bring up a blank box, or a one-line box [<no matches>].
I agree that it is inconsistent, but then again, file-completion in a 
string with Tab is a convenience feature. There is no good way to 
specify "ask for file names" unless you create a separate key binding 
just for that. Sometimes, a Tab is just a Tab.

The behavior introduced by the provided patch will only provide the file 
completion box (or automatic fill-in) if the given string already 
partially matches a file in the file system.
msg228304 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-10-03 03:58
I have had problems entering docstrings because of this.  Box should not come us when tab on successive lines.  (There really should be autoindent, maybe this interferes.)
msg255308 - (view) Author: Tom F (Tom F) Date: 2015-11-25 00:00
I've found this to be annoying as well especially in docstrings, hopefully this will help in the meantime.

If you SHIFT + Tab it will at least resolve the problem of bringing up files and remains as the usual tab function.

It makes me wonder if it is a bug at all though?
msg270898 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-07-21 00:58
It is intentional that <modifier> <tab> be treated as a normal tab.  The autocomplete_event tab handler begins with
    if hasattr(event, "mc_state") and event.mc_state:
        # A modifier was pressed along with the tab, continue as usual.
        return

To fix the problem with tabs at the beginning of a line within multiline strings, I am adding to the condition a clause to catch tabs at the beginning of lines, whether within a multiline string or not.

    or not self.text.get("insert linestart", "insert").strip()

Tests still pass with this addition.  I need to add a test that fails without it.

I think a tab should bring up completion box even immediately after an opening quote, as in
    open('<tab>
Typing a letter fails to open a box if there is only one completion, so that is not a foolproof way to get a box with all choices.
msg296667 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-23 03:58
I pushed a patch on another issue that fixed tabbing on lines after the first line within multiline strings.  With 3.6, I verified that tabbing anywhere on the same line of an opening quote, except immediately after the quote, brings up the box.
History
Date User Action Args
2017-06-23 03:58:16terry.reedysetmessages: + msg296667
versions: + Python 3.6, Python 3.7, - Python 2.7, Python 3.4, Python 3.5
2016-07-25 00:08:07terry.reedylinkissue27609 dependencies
2016-07-21 00:58:37terry.reedysetmessages: + msg270898
2015-11-25 00:00:17Tom Fsetnosy: + Tom F
messages: + msg255308
2014-10-03 03:58:24terry.reedysetstage: needs patch -> patch review
messages: + msg228304
versions: + Python 2.7, Python 3.5, - Python 3.3
2012-10-15 04:23:10roger.serwysetmessages: + msg172943
2012-10-11 22:13:32terry.reedysetmessages: + msg172702
2012-10-11 18:05:15roger.serwysetfiles: + issue16198_check_matches.patch
keywords: + patch
messages: + msg172670
2012-10-11 16:48:41roger.serwycreate