Hacker News Reader

Comment by ginko | Hacker News Reader

It‘s a source of problems with mismatched tabs/spaces being used for indentation between team members for fairly little upside. Imo it also makes moving blocks of code more cumbersome.

View on HN

Shrubbery, Rhombus's first-pass indentation-sensitive syntax, has a syntax form to facilitate copy-paste.

With guillemets, « and », you can make a section of Shrubbery code indentation-insensitive. The idea for copy-paste it to "armor" the section you want to copy with guillemets in the right places, and unarmoring it after posting.

This needs editor support to do fluidly, but imo it's much better than trying to copy-paste the indentation-sensitive syntax.

The Guillemets syntax is described here: <https://docs.racket-lang.org/shrubbery/group-and-block.html#...>

I can't tell from my 5 minutes of poking DrRacket whether it supports this "armoring", I've been writing Shrubbery in nvim, which, unsurprisingly, does not support it.

In DrRacket mark the section (with shift+arrows) then use tab or shift+tab.

That's horrifying.

At least it shows that the authors are aware of this issue and planned for it.

Any language with significant indentation ends up specifying "Indent with spaces, not tab characters" for just that reason. As I recall, Python had that as a recommendation while F# ended up with it as a requirement, but it's been a while since I looked at that so I could be wrong. But in my experience, the category "people who complain about significant whitespace" is nearly a subset of the category "people who prefer tabs over spaces for indentation".

(Moving blocks of code around is not a real problem if your editor is capable of easily highlighting the thing that was just pasted. Because then you just hit that key binding, then press `>` or `<` — or Tab/Shift+Tab if you are using an inferior editor ;-) — until the indentation is where you need it. I haven't found it to be a big problem in practice when writing Python, though mileage will likely vary).

>Because then you just hit that key binding, then press `>` or `<` — or Tab/Shift+Tab if you are using an inferior editor ;-) — until the indentation is where you need it.

But that's cumbersome compared to moving the block of code and hitting Tab to have your superior editor immediately indent the block at the right level.

For me, the alternative solution makes much more sense for a language with significant indentation, i.e. to use only tabs for indentation and to completely prohibit spaces before the first printable character of a line.

I do not know why I have never seen this solution in practice.

It depends on the language's indentation requirements. That can work in Python, where you never need to line things up with characters above that aren't a multiple of an indent level. But in F#, at least a few years ago when I tried it, there are times when you would need (or strongly want) to line things up with other characters. For example, this example from https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/...:

    functionName
        arg1
        arg2
        arg3
        (function
         | Choice1of2 x -> 1
         | Choice2of2 y -> 2)

Note how the | needs one extra space in order to line up with the word "function", due to the open parenthesis. If you're using tabs for indentation, that means you need a series of tabs plus one trailing space after the tabs, in order to line up the | correctly.

Any situation where you must have a mixture of tabs and spaces for code to work right leads to a nightmare. Because it makes you have to turn on visible whitespace in your editor and peer closely at the lines. I have a simple rule: "Do NOT make me care whether there are tabs or spaces in this file!" If it's significant whether a line is indented with a tab or space, then that rule is broken, and you're probably in for a bad time. (Case in point: Makefile syntax).

I did not take this in consideration, because for such code, with brackets and separators, I prefer to align the separators with the opening and closing brackets, like this:

  ( ...
  | ...
  | ...
  | ...
  )

  { ...
  ; ...
  ; ...
  ; ...
  }

I just checked, and lining up the | with the open parentheses does work in modern F#. I believe they revamped the indentation rules a few years back, because I definitely remember things like that not working back when. So perhaps now your idea would be feasible. However, there was definitely a time in the past when F#'s indentation rules would have been problematic for tabs, and that fact is why the F# compiler still forbids tab characters outside of string literals or comments. (And there are still indentation styles recommended, though not required, by the official F# style guidelines that would require the use of spaces. Which is another reason to avoid tabs in F# code, because they're less flexible than spaces. Usually the reason to prefer tabs is because they're more flexible, but the slightly-peculiar nature of F#'s indentation rules means tabs are less flexible in F# code.)

That's why you use an autoformatter.

IMO the biggest downside is that it gets awkward to do closures and inline expressions and things like that. For example Python's `lambda` and if-else expression which are super weird and special snowflakey compared to the equivalents in e.g. Rust or OCaml or even Tcl.

Maybe there's a way to do it nicely; I haven't thought about it too much.

You can't autoformat broken indentation with significant whitespace since it would make the program not parse (or parse incorrectly)

I was responding to

> mismatched tabs/spaces being used for indentation between team members

Well yes. Say you check out a project that's all tabs but your editor is using spaces for indentation. You change a line and now the program is broken. Calling the auto-formatter won't help you.

This is literally not a problem. All Python projects use 4-space indentation. You would not have your editor configured for tabs when editing a Python program.

It's really not an issue at all in practice. The issue of making moving code more awkward is true but really barely an inconvenience. It's not difficult to select it and press tab a couple of times.

As I said the biggest issue is with closures and expressions that you might want on one line.

>This is literally not a problem. All Python projects use 4-space indentation.

Tell that to the one team at my old workplace that used spaces for all their scripts.

Like I said it’s a stupid source of errors that can be mitigated through style guides and tooling but it’s still a source of errors.

Reply on news.ycombinator.com