Hacker News new | ask | show | jobs
by thargor90 1256 days ago
What I hate about python/yaml/etc is that copy/paste + reformat does not work.

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.

1 comments

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.

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

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

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.

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

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

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?

> 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

>> 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.
Do you know any IDE or editor that implements this? I would love to try it.
> 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.

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.