classification
Title: Interactive: Move to same indentation level as previousline
Type: enhancement Stage: resolved
Components: Versions: Python 3.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, emilyemorehouse, mbussonn, serhiy.storchaka, terry.reedy
Priority: normal Keywords:

Created on 2017-01-21 22:56 by 12345 67890, last changed 2017-04-01 20:30 by terry.reedy. This issue is now closed.

Messages (19)
msg285970 - (view) Author: 12345 67890 (12345 67890) Date: 2017-01-21 22:56
Not sure if anyone has ever thought about this, but it would be nice if the interactive interpreter set the same indentation level as the previous line. Of course this isn't urgent, but what do others think?
msg286066 - (view) Author: Jim Fasarakis-Hilliard (Jim Fasarakis-Hilliard) * Date: 2017-01-23 09:57
I'm not exactly sure what you mean but, since this isn't a bug per se and is more of a subjective opinion on how the REPL should handle the indentation level, you should probably ask *first* on python-ideas to get input from other members. (See https://docs.python.org/devguide/faq.html#suggesting-changes)
msg286090 - (view) Author: 12345 67890 (12345 67890) Date: 2017-01-23 15:03
I did not mark this as a bug. I marked it as an "enhancement" and I said that the priority was low.

"I'm not exactly sure what you mean"

In an IDE when developing in python, each time you press enter, the cursor is set to the same indentation level as the previous line so that you don't need to type spaces on every new line to return to the same indentation level. I am merely suggesting that the interactive interpreter do the same thing. 

"is more of a subjective opinion"

You are of course correct that this is a subjective opinion. But it's not just my subjective opinion. As I said, it's what nearly every IDE does including (maybe?) the one that you're using.
msg286108 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-01-23 19:07
Posting an idea directly to the issue tracker is fine as long as it's done in a reasonable fashion (i.e. not rudely).

As for the specific idea, I assume this is for the REPL as used in a shell and not in IDLE. If you want to propose a patch that can work cross-platform in both a Windows and UNIX shell where dedenting works consistently then it might be considered.
msg286109 - (view) Author: 12345 67890 (12345 67890) Date: 2017-01-23 19:22
I hope I haven't been rude; the idea here was to see what the feeling of the core developers was about this idea.

As for the patch, that will probably come after the Python workflow has been fixed because doing it then will save everyone time and as I have said, this is low priority.
msg286111 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-01-23 19:56
No, I don't think you were rude, 12345 67890. I was just giving the standard explanation as some people are not pleasant and you never know who might read this issue later and benefit from the reminder.
msg286112 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-01-23 20:32
Adding at least 'dumb indentation' (repeat last indent) to the REPL would make it at least a bit more usable.  (This still would not be a good as an IDE, like IDLE, that does smarter indentation, such as adding an additional indent after a compound statement header ends with ':'.)

The simplest patch would be to slice and echo the initial whitespace (spaces and tabs) of each line that needs to be followed with a secondary prompt.  What I don't know is whether, on every console, a printed tab always has the same effect as a tab entered by a user.
Testing would be needed.
msg286113 - (view) Author: Jim Fasarakis-Hilliard (Jim Fasarakis-Hilliard) * Date: 2017-01-23 20:47
Thanks for the standard explanation, Brett. I was just following the devguide too strictly and assumed python-ideas is the first place one should go :-).

As for the idea, it seems others wish/wished it too (first paragraph: https://docs.python.org/3/tutorial/interactive.html#alternatives-to-the-interactive-interpreter)
msg286118 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-01-23 21:30
The point I was trying to get at above is that simply printing a prompt and making the use enter the entire line should work on every console, while anything fancier may not be so reliable.  Thinking more, I realize that my patch outline is incomplete. After 'line = input(prompt + indent)', line will not include the indent. A printed indent will have to be added to the input received from the user.  (In IDLE's Shell and editors, the indents that IDLE insert()s into a text widget are indistinguishable from those types by a user and *are* included in the user input that IDLE reads.)  An associated issue is that cross-platform automated tests would be difficult to impossible.

More experiment reveals the fatal problem: in REPL mode, python reads stdin and writes to stdout and stderr.  In the Windows console, and I am sure others, printed output cannot be deleted.  In particular, printed input spaces, such as the one at the end of '>>> ' cannot be deleted.  So dedenting, as in the following example, would not be possible.  One cannot input() a negative string.

if possible:
    print('I like it')
    write_patch()
    test()
else:
    print('too bad')
    reject_idea()

So unless I am wrong, the idea must be rejected.
msg286124 - (view) Author: 12345 67890 (12345 67890) Date: 2017-01-23 22:41
It probably won't be trivial, but it definitely is possible. Suplemon has the exact functionality needed and it's only dependency is CPython. The only question is: how much code is this going to add?

[1]: https://github.com/richrd/suplemon
msg286125 - (view) Author: 12345 67890 (12345 67890) Date: 2017-01-23 22:46
In addition, windows allows direct console control via the win32 API and the code for that isn't too lengthy.
msg286690 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-01 20:39
Any autoindetation breaks pasting from the clipboard since there is no way to distinguish characters entered from the keyboard from characters pasted from the clipboard. In IDLE or other visual shell we can add a special menu entry and hotkeys for pasting from clipboards without autoindenting, but in a REPL in text terminal this is not possible.

IPython3 solved this issue by adding special magic functions, but this is not a way for CPython.
msg286695 - (view) Author: 12345 67890 (12345 67890) Date: 2017-02-01 21:00
That one is pretty tricky. The only way that I can think of is to delay indentation until the first character is typed, and not to indent if it is a space or tab. 

From: Serhiy Storchaka
Sent: Wednesday, February 1, 2017 2:39 PM
To: xoviat@gmail.com
Subject: [issue29339] Interactive: Move to same indentation level as previousline

Serhiy Storchaka added the comment:

Any autoindetation breaks pasting from the clipboard since there is no way to distinguish characters entered from the keyboard from characters pasted from the clipboard. In IDLE or other visual shell we can add a special menu entry and hotkeys for pasting from clipboards without autoindenting, but in a REPL in text terminal this is not possible.

IPython3 solved this issue by adding special magic functions, but this is not a way for CPython.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue29339>
_______________________________________
msg286700 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-01 21:17
> The only way that I can think of is to delay indentation until the first character is typed, and not to indent if it is a space or tab.

This will not help for "else" or "except".
msg286826 - (view) Author: 12345 67890 (12345 67890) Date: 2017-02-02 21:13
The user is going to have to outdent anyway if we return them to the previous indentation level. Essentially it would be this:


[ENTER]

set_cursor_to_previous_indentation_level()

if first_char_in_is_space:
    erase_first_char_in()
    reset_cursor_to_zero_indentation()
    type_first_char()
else:
    pass


So if we have this line:

        some_line

[ENTER]

        some_line
        ^

[BACKSPACEX4]

        some_line
    ^
<---- cursor direction

The other case is

        some_line

[ENTER]

        some_line
        ^

[SPACEX4]

        some_line
    ^
----> cursor direction

Does that make sense?
msg287618 - (view) Author: 12345 67890 (12345 67890) Date: 2017-02-11 19:02
I guess the workflow has been fixed so that I can submit a PR! I wasn't expecting this so soon, but I will get around to this as soon as I have time.
msg287737 - (view) Author: Matthias Bussonnier (mbussonn) * Date: 2017-02-14 06:11
> IPython3 solved this issue by adding special magic functions, but this is not a way for CPython.

IPython 5 improve on that with prompt toolkit. It does not break paste, as prompt_toolkit has a bracketed-past mode, that most terminal emulator support  (control chars sent by terminal "hey I'm pasting", "hey I'm done pasting"). So it works nicely. IPython 6 even will remove the need for magics to activate paste mode.

Though it's far from trivial to implement and to get it "right".

Once you start giving indentation to user, they start to be demanding, like indenting 1 more on `:`, and one less on `return`, `pass`... , multiple line string. etc...

See https://github.com/ipython/ipython/issues/9283 for some of the issues and limitation you can hit.

If you decide to implement this kind of things, there are likely a lot you can borrow from IPython, the InputSplitter class has likely the sate needed to give you the indent level to use in readline.
msg289629 - (view) Author: 12345 67890 (12345 67890) Date: 2017-03-14 23:13
Folks, I have decided that I no longer have the time to resolve this issue.
msg289634 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-03-15 03:03
I am inclined to close this.  Any objection?
History
Date User Action Args
2017-04-01 20:30:30terry.reedysetstatus: open -> closed
resolution: rejected
stage: needs patch -> resolved
2017-03-15 03:03:39terry.reedysetmessages: + msg289634
2017-03-14 23:14:2412345 67890setnosy: - 12345 67890
2017-03-14 23:13:5412345 67890setnosy: brett.cannon, terry.reedy, serhiy.storchaka, mbussonn, emilyemorehouse, 12345 67890
messages: + msg289629
2017-03-14 20:36:46Jim Fasarakis-Hilliardsetnosy: - Jim Fasarakis-Hilliard
2017-02-14 06:11:26mbussonnsetnosy: + mbussonn
messages: + msg287737
2017-02-11 19:02:3512345 67890setmessages: + msg287618
2017-02-02 21:13:5712345 67890setmessages: + msg286826
2017-02-01 21:17:39serhiy.storchakasetmessages: + msg286700
2017-02-01 21:00:4612345 67890setmessages: + msg286695
title: Interactive: Move to same indentation level as previous line -> Interactive: Move to same indentation level as previousline
2017-02-01 20:39:08serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg286690
2017-01-24 06:34:35emilyemorehousesetnosy: + emilyemorehouse
2017-01-23 22:46:1912345 67890setmessages: + msg286125
2017-01-23 22:41:2112345 67890setmessages: + msg286124
2017-01-23 21:30:20terry.reedysetstage: needs patch
messages: + msg286118
versions: + Python 3.7
2017-01-23 20:47:32Jim Fasarakis-Hilliardsetmessages: + msg286113
2017-01-23 20:32:55terry.reedysetnosy: + terry.reedy
messages: + msg286112
2017-01-23 19:56:52brett.cannonsetmessages: + msg286111
2017-01-23 19:22:2512345 67890setmessages: + msg286109
2017-01-23 19:07:17brett.cannonsetnosy: + brett.cannon
messages: + msg286108
2017-01-23 15:03:2312345 67890setmessages: + msg286090
2017-01-23 09:57:15Jim Fasarakis-Hilliardsetnosy: + Jim Fasarakis-Hilliard
messages: + msg286066
2017-01-21 22:56:1512345 67890create