[issue23441] rlcompleter: tab on empty prefix = insert spaces
Martin Sekera added the comment: 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 copypaste 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). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23441 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23441] rlcompleter: tab on empty prefix = insert spaces
Martin Sekera added the comment: 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). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23441 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23441] rlcompleter: tab on empty prefix = insert spaces
Martin Sekera added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23441 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23441] rlcompleter: tab on empty prefix = insert spaces
Martin Sekera added the comment: 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. -- nosy: +Martin Sekera Added file: http://bugs.python.org/file38487/rlcompleter-tab.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23441 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
