Repository navigation
IDLE - tabbing in a string sometimes brings up word completion window #60402
Description
| BPO | 16198 |
|---|---|
| Nosy | @terryjreedy, @serwy |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2012-10-11.16:48:41.154>
labels = ['expert-IDLE', 'type-bug', '3.10']
title = 'IDLE - tabbing in a string always brings up file completion window'
updated_at = <Date 2020-06-07.22:04:37.676>
user = 'https://github.com/serwy'bugs.python.org fields:
activity = <Date 2020-06-07.22:04:37.676>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2012-10-11.16:48:41.154>
creator = 'roger.serwy'
dependencies = []
files = ['27533']
hgrepos = []
issue_num = 16198
keywords = ['patch', '3.3regression']
message_count = 8.0
messages = ['172663', '172670', '172702', '172943', '228304', '255308', '270898', '296667']
nosy_count = 3.0
nosy_names = ['terry.reedy', 'roger.serwy', 'Tom F']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue16198'
versions = ['Python 3.10']
Activity
serwy commentedon Oct 11, 2012
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 multi-line doc strings.
This behavior is new to the 3.3 series as a consequence of #59142. 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.
serwy commentedon Oct 11, 2012
(PATCH - adds 11 lines to autocomplete.py, needs test and conversion to PR. tjr)
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.
terryjreedy commentedon Oct 11, 2012
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 #59142 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>].
serwy commentedon Oct 15, 2012
There is no configuration option for file completion.
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.
terryjreedy commentedon Oct 3, 2014
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.)
TomF commentedon Nov 25, 2015
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?
terryjreedy commentedon Jul 21, 2016
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.
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.
terryjreedy commentedon Jun 23, 2017
I pushed a patch on another issue that fixed tabbing on lines after the first line within multiline strings. With 3.6 and 3.11 I verified that tabbing anywhere on the same line of an opening quote, except immediately after the quote, brings up the box.
[-]IDLE - tabbing in a string always brings up file completion window[/-][+]IDLE - tabbing in a string sometimes brings up word completion window[/+]terryjreedy commentedon Oct 5, 2022
My local branch strcomp currently has a slight revision of the 'match' part of Roger's patch, and it seems to work as promised.
The 'multiline-string' part is not needed. I will skip the 'empty' part until a find trigger case for a test. It seems to be a separate issue. I might consider dumping tab for path completion, but wanting literal tab chars in strings is rare (and they are not converted to spaces). '\t' is better for getting a tab in the string object. Maybe literal tabs should become r'\t'.
pythongh-60402: Fix Tab in a string in IDLE
serhiy-storchaka commentedon Sep 15, 2026
#157593 implements the "match" part of Roger's patch: Tab in a string opens the file name list only if some file name starts with the text before the cursor. The multiline part is covered by that too, since on a continuation line the text before the cursor is never a file name.
gh-60402: Fix Tab in a string in IDLE (#157593)
[3.13] gh-60402: Fix Tab in a string in IDLE (GH-157593) (#157632)
[3.14] gh-60402: Fix Tab in a string in IDLE (GH-157593) (#157631)
[3.15] gh-60402: Fix Tab in a string in IDLE (GH-157593) (#157630)