[TuringTest]

The origin text that you're cutting will have a precise syntax determining where the block starts and ends. Just copy it to the new position, and change the indentation level to that of the target position, maintaining the same block definition. You know, the same thing that would be done if there were start and end delimiters; because in Python, indentation changes ARE block delimiters, with a well-defined syntax.

It's not rocket science, just following the language indentation rules for defining blocks. If the language parser can do it, why not the text editor?

[dmitriid]

> The origin text that you're cutting will have a precise syntax determining where the block starts and ends.

Will it? Are you sure?

> Just copy it to the new position, and change the indentation level to that of the target position, maintaining the same block definition.

"Just" copy. "Just" manually re-indent it.

Remember, we're talking about an IDE automatically figuring out proper indentation for something.

> If the language parser can do it, why not the text editor?

Because constructs that are valid from the compiler's point of view may be ambiguous fro the program's point of view: https://news.ycombinator.com/item?id=34235121

[TuringTest]

>> The origin text that you're cutting will have a precise syntax determining where the block starts and ends.

> Will it? Are you sure?

Yes, it's defined as part of Python specification. https://docs.python.org/3/reference/lexical_analysis.html#in...

Indentation increasing or decreasing generates INDENT and DEDENT tokens, which are used as block delimiters.

> Remember, we're talking about an IDE automatically figuring out proper indentation for something.

The IDE doesn't need to figure out whether the program is correct. Only has to treat code blocks as defined by the language syntax. In your linked example:

  if x > 0:
    function1()
    function2()
    function3()


  if x > 0:
    function1()
    function2()
  function3()

The IDE should treat the blocks as if defined with delimiters this way:

  if x > 0: {
    function1()
    function2()
    function3()
  }


  if x > 0: {
    function1()
    function2()
  }
  function3()

Because that's how Python will interpret them. So, the IDE would do exactly the same behavior with curly bracket delimiters and with changes in indentation, because in both cases there is a precise rule to define where blocks start and end.

[thargor90]

Do you know any IDE or editor that implements this? I would love to try it.

[TuringTest]

I've just tried Spyder, and it seems to work that way.

With this code:

    indent(1)
    
        indent 2

        if x<0:
            function 1
            function 2
        function 3

if you select the if block starting the selection at the "if" (i.e. ignoring the whitespace at its left) up to function 3, and paste it right under indent(1), it produces the following:

    indent(1)
    if x<0:
        function 1
        function 2
    function 3    
    
        indent 2

        if x<0:
            function 1
            function 2
        function 3

Yet if you select the whole line including the initial indentation whitepace and paste it at the same place under indent(1), then it doesn't change the block indentation:

    indent(1)
        if x<0:
            function 1
            function 2
        function 3
    
    
        indent 2

        if x<0:
            function 1
            function 2
        function 3

That looks sensible to me; if you're moving whole lines it will paste them unchanged, but if you move the cursor to select specifically a keyword and its context, it treats it as a code block, reformatting its indentation to that of the place where you are pasting it.

[dmitriid]

Where as in a language that actually has blocks you don't need to make these arbitrary decisions and hunt for the exact way of copying a block of text.

[TuringTest]

Python has blocks, in the same way that Javascript has sentences even if you don't end all of them with semicolons.

[dmitriid]

> The IDE doesn't need to figure out whether the program is correct. Only has to treat code blocks as defined by the language syntax.

Exactly. It treats these blocks as such. And it will inevitably format them incorrectly from the programmer's point of view.

> because in both cases there is a precise rule to define where blocks start and end.

And this precise rule inevitably formats code incorrectly from the programmer's point of view in a significant amount of cases.

[TuringTest]

> And this precise rule inevitably formats code incorrectly from the programmer's point of view in a significant amount of cases.

Only for programmers who are significantly unaware of how the Python language structures its code.

It's not that difficult really. And if you have problems visualizing them, you could use editors like Visual Studio Code, which highlights indentation so that you can see the start and end of blocks with colors, way easier than with start and end brackets.

[kaba0]

Would you put your arm in fire that I could correctly copy-paste that code from your HN comment as well? I’m not so sure, yet a Java fragment would sure work just fine.