Not this again

https://github.com/prettier/prettier/issues/7475#issuecommen...

> Blind programmers have no problems with it.

We're struggling with the wrong problem if we aren't asking why the editor can't treat blocks as entities that are displayed however we want.

  > why the editor can't treat blocks as entities

If you have something like:

  var (
    x     = foo
    other = bar
  )

  coolFun(arg1,
          arg2)

  ->coolFun(arg1,
  ->        arg2)

  --->coolFun(arg1,
  --->        arg2)

  ------->coolFun(arg1,
  ------->        arg2)

The problem is when you start doing stuff like:

  if (one) {
  ------>if (two)
             bar();
  ------>else
             xxx(); 
  }

That's what people mean with "don't mix tabs and spaces", not "if you use tabs then the space shall never appear in the file under any condition".

This is clearly false. You said this after giving a perfect example of how it's done with tabs.

  -------->coolFun(arg1,
  -------->------->arg2)

https://superuser.com/questions/710019/why-there-are-11-tabs...

> This is clearly false. You said this after giving a perfect example of how it's done with tabs.

I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.

When I made my original comment I thought what I was replying to was an example of "tabs to indent and spaces to align" immediately followed by a statement that the only way to use tabs is to both indent and align.

Aligning lines in the same block

    ____var a; // indented with a tab
    ____var b; // indented with a tab

    ____var a, // indented with a tab
    ____----b, // indented with a tab, then aligned using spaces

Another alternative is elastic tabs, where tabs are used for both of those, but are converted to an indentation/alignment number of characters semantically. I like the idea, but I've yet to see a good implementation.

Personally I'm a fan of all spaces, but that's mostly because every company I've worked at has used that.

int foobar(int a,

___________int b) // should only ever have spaces (using _ here because HTML)

But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong).

The other issue I have is that diffs break alignment between undented code and anything with tabs because the tabs "eat" the leading space, but unindented lines are offset by one.

I've had some editors that made tab-space conversion an option, but it was never mandatory.

I've not done lots of development with other editors, but Kate didn't do it and the few times I used Visual Studio, it also had similar behaviors (I'm assuming VSCode inherited that stuff).

[1] https://editorconfig.org/

https://lore.kernel.org/keyrings/20221109025019.1855-2-linux...

If HN mangles the link, it is the addition of the `key_create` function in this thread: https://lore.kernel.org/keyrings/20221109025019.1855-2-linux...

https://nickgravgaard.com/elastic-tabstops/

It's the second step that drives me nuts. Why can't/doesn't alignment happen at first step? The inconsistencies of alignment using true tabs, in a monospace plain text environment, grosses me out and decrements my faith in the underlying systems. I appreciate editors w/ settings like `insert spaces when pressing tab` and `the number of spaces a tab is equal to`.

The problem of leading spaces not changing their size can be solved through programming.

Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them.

The use of tabs is detrimental to code bases. Whenever tabs creep in, invariably people use different tab settings and make a dog's breakfast out of the code.

Code exhibits indented sub-structures that are internally indented, but not themselves not aligned to a tab stop, but aligned with something. One kind of example is something like:

  function_name_of_random_length(lambda (a, b) {
                                     if (a < b) {
                                         indented();
                                     }
                                 },
                                 arg2);

So I'm not convinced the problem you're describing should ever happen.