rlcompleter: tab on empty prefix => insert spaces

[arigo]

BPO	23441
Nosy	@arigo, @pitrou, @larryhastings, @ned-deily, @ezio-melotti, @bitdancer, @berkerpeksag, @vadmium, @1st1
Files	rlcompleter_tab2space.diff: Patch rlcompleter-tab.patch: fixes rlcompleter behavior on empty lines issue23441.diff issue23441_rev1.diff

^{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 = <Date 2015-07-27.21:13:46.330>
created_at = <Date 2015-02-11.10:21:44.695>
labels = ['deferred-blocker', 'type-bug', 'library']
title = 'rlcompleter: tab on empty prefix => insert spaces'
updated_at = <Date 2015-11-19.20:12:34.332>
user = 'https://github.com/arigo'

bugs.python.org fields:

activity = <Date 2015-11-19.20:12:34.332>
actor = 'yselivanov'
assignee = 'none'
closed = True
closed_date = <Date 2015-07-27.21:13:46.330>
closer = 'berker.peksag'
components = ['Library (Lib)']
creation = <Date 2015-02-11.10:21:44.695>
creator = 'arigo'
dependencies = []
files = ['38093', '38487', '40032', '40039']
hgrepos = []
issue_num = 23441
keywords = ['patch']
message_count = 33.0
messages = ['235733', '235735', '235750', '235767', '236219', '238102', '238103', '238107', '238238', '238240', '238245', '238377', '238390', '238392', '242276', '246398', '246399', '246400', '246423', '246424', '246444', '246481', '246483', '246670', '247435', '247438', '247477', '247481', '247482', '247484', '247486', '254869', '254932']
nosy_count = 12.0
nosy_names = ['arigo', 'pitrou', 'larry', 'ned.deily', 'ezio.melotti', 'r.david.murray', 'dabeaz', 'python-dev', 'berker.peksag', 'martin.panter', 'yselivanov', 'Martin Sekera']
pr_nums = []
priority = 'deferred blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23441'
versions = ['Python 3.4', 'Python 3.5', 'Python 3.6']

[arigo]

In the interactive prompt:

>>> if 1:
... <press tab here>

Pressing tab here should just insert 4 spaces. It makes no sense to display all 500 possible "completions" of the empty word, and using tab to indent is a very common feature of any editor with a Python mode.

Patch attached.

[vadmium]

Main bug report: bpo-22086.

Can you say if this works when the cursor is not at the start of the entry? E.g. after an existing tab (Ctrl-V Tab on GNU readline) or space, or after an embedded newline (Ctrl-V Enter).

What happens if you press backspace after pressing tab? Do you have to backspace four times? Another options is to insert a literal tab code instead of spaces.

[arigo]

Ah, thanks, I missed there was already an issue.

The patch's logic is as follows: when pressing tab anywhere in the line, if the word to complete is empty (which might be for any number of reasons, like the cursor is after another space or a non-word character), then suggest as completion a string of N spaces, where N is a number from 1 to 4 so that the cursor ends up being aligned to a multiple of 4. You have to press backspace several times to remove all these spaces.

Indeed, it could also suggest a single '\t' character, which would be simpler and revert exactly to the old behavior (including a single backspace to remove the whole tab). I didn't do it only because it would typically indent to 8 characters instead of 4. If people think it is anyway a better idea, I can submit a second (simpler) patch doing that.

[pitrou]

Thanks a lot for doing this. I think it's a good improvement. I prefer 4 spaces myself (tabs usually insert 8 spaces, which is too wide), but I'm open to other opinions.

[bitdancer]

Looks good to me. I prefer 4 space indent as well, and since we have essentially deprecated the use of tabs for spacing in Python, I'd rather not reintroduce it here for the (minor) benefit of making backspacing easier. Just think about the copy and paste consequences....

I'll miss vi's autoindent more than I will smart backspace, but python never had that to start with so I'm not asking for it :).

I presume someone could add an enhancement for smart backspace if they were motivated to do so, but I'd say that is a separate issue.

[MartinSekera]

Is it necessary to force a predefined tab width (4) onto the user here? I prefer 2-character tabs for example, and have all my terminals set up accordingly (setterm --regtabs 2). I presume many people prefer 8-column tabs, hence the default width in most software.

Additionally, the user shouldn't have to backspace 4 characters to remove one level of indentation. Not only is it annoying, it is also prone to errors if the user miscounts (and ends up with an IndentationError).

I've been using the attached patch (just 5 lines) to emulate the behavior familiar from unix shells: pressing tab activates the completion function, but indents if the line is empty (i.e. '' or all whitespace). It also indents properly if the cursor is moved to whitespace in front of a line, as one would expect.

[pitrou]

4 spaces is the recommended indent width in PEP-8. That's what most Python users will expect.

[ezio-melotti]

+1 for 4 spaces.

Smart backspace would be nice too, but I agree it's a separate issue (unless it's trivial to implement). Deeply-nested code in the interactive interpreter is uncommon, and the lack of smart backspace never bothered me.

[MartinSekera]

Copy that. Would the patch be acceptable if the '\t' was simply changed to 4 spaces?

To discuss further, it is my opinion that the interpreter should output a \t character when the TAB key is pressed, as this is the behavior of nearly every shell and interpreter (that doesn't autocomplete all the time) there is, including all versions of python. Introducing new behavior for the sake of compliance with PEP-8 (which, as it itself states, applies only to "the Python code comprising the standard library in the main Python distribution"), is in my opinion unnecessary and confusing (since to clear n indent levels the user has to backspace 4n times).

[bitdancer]

No program that I work with (and I use cli all the time) outputs a tab when I press the tab key. Now, true, I think I had to configure vi so that that was the case, but nothing else that I remember. Of course, most of those programs use readline and come with some sort of configuration such as what we are (belatedly) supply in python's command line. So, to me, outputting an actual tab character would be *less* consistent with my general (modern) computing experience. Especially since we are, in fact, talking about python now doing "autocomplete all the time" :)

[MartinSekera]

In the end it doesn't matter what characters end up on the terminal. What matters is the UX of not having to press backspace several times to unindent. That's sloppy design.

The issue of forcing a custom indent width on a user who might have their tab stops setup differently is another, albeit smaller, issue. I think the interpreter has absolutely no reason to do what's basically UI work (aligning tabbed text with tab-stop columns as in the first patch). That's the terminal's job.

[bitdancer]

The CLI is a UI. We're using readline facilities (ie: "the terminal") to improve it. And people cut and paste from the interactive terminal, so I think the presence of tab characters is a negative from that perspective as well.

[MartinSekera]

But tab characters are rendered by the terminal into spaces. During stdout processing, when the term encounters a \t (0x09), it inserts (into the term buffer that is displayed to the user) as many spaces (0x20) as needed to move the cursor to the nearest tab-stop (setterm --tabs will display them for you). Why do we need to duplicate this inside Python?

There are no copy&paste issues either, try it yourself: when you copy and paste tab-indented text from the terminal, your text will contain spaces instead of tabs (at whatever width you have your terminal tab stops configured for).