[TuringTest]

That's only because editors are not programmed to do the work.

An IDE with proper language support for a whitespace-aware language should be able to parse the AST figuring out the code structure from the indentation level; then it could reformat it at the proper indent level when you copy and paste it elsewhere, just like it does with a delimiter-based language.

[lelanthran]

> That's only because editors are not programmed to do the work.

No; it is not decidable where a block ends and the next line of the out block starts when there is no marker for block ends ('}', or 'END', etc).

[TuringTest]

Of course it is decidable, the programming language has very strict rules to determine it. That's why you need language support in the editor, not just finding matching open/close delimiters.

[lelanthran]

> Of course it is decidable, the programming language has very strict rules to determine it.

No, it's not. The programming language grammar can reject things, but it cannot determine certain class of mistakes which explicit terminators ("}" and so on) can, which is why programs like `indent` existed for decades for other languages, but have yet to exist for Python which is already 30 years old.

If no one has cracked that particular nut for 30 years, you can't with a straight face claim that it is obviously possible. It looks more impossible with each passing year.

[TuringTest]

If a program cannot determine when a block code starts and ends from indentation alone, then it is not correct Python; the language needs a deterministic process to determine what sequence of commands belong to the same block, otherwise it couldn't compile.

If you're talking about failing to determine blocks which are NOT correct Python, then I don't have a problem with those failing to be correctly indented under copy/paste. The vast majority of use cases would still be well served.

[kaba0]

We are talking about pasting code into another, where both can fail to be correct at the time and you may or may not want to output to be correct. Nonetheless, your intent can’t be determined due to multiple ambiguous “good” outputs, e.g. should insertion start at the current level and keep at it, did the copy happen from a “dumb” medium without leading whitespace so that it should be tried to be indented first, etc. Sure, you can have a look at the resulting code and fix, but we all know that humans err a lot, this is something that works braindeadly easily with non-whitespace ”aware” languages.

[lelanthran]

> If you're talking about failing to determine blocks which are NOT correct Python, then I don't have a problem with those failing to be correctly indented under copy/paste.

Then maybe you shouldn't have replied to parent who said:

>> Yes it forces clean indentation, but it gives the writer the burden to take care of it. That sucks. Let the computer do the work.

> The vast majority of use cases would still be well served.

Well, sure, because the burden for ensuring the code is correct falls onto the programmer, whereas with other languages we can just let the computer do that.

[TuringTest]

You can't let the computer ensure the correctness of code.

I replied to dismiss your assumption that adding delimiters as '}' or 'END' will ensure the correctness of code in a way that a code with indentation delimiters can't do. It's similar to saying that in, a language where statements are not finished by semicolon, it's not decidable where sentences end, so this forces the developer to decide on the correctness of statements. OF COURSE there are ways to define where a statement ends without adding a semicolon to each one, just like there are ways to decide where blocks end in an indent-based programming language; they are embedded in the language syntax.

Heck, C is notorious for producing incorrect code for NOT using meaningful indentation and relying on delimiters instead. If you write:

   if (x>0)
       function(1);
   else
       function(2);

And then you expand the else block:

   if (x>0)
       function(1);
   else
       function(2);
       function(3);

Then function(3) will be compiled out of the if sentence, when it's clearly part of the else block.

[dmitriid]

No, they couldn't. There are too many places where the identation can go either way.

Just because you paste a bunch of code after `then` in Python doesn't mean all of it goes into `then`.

[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]

> 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.