Great, no scrolling through thousands of lines to find the right one!

Now next time I read anything about why any Python libraries are named what they are named, I’m going to hear Dr Doofenschmirtz voice. Thank you for that.

Anarchist: tab with set to 1

It’s not just “might”. Termux is pretty much the only good choice for programming on Android.

I think 9 is the best size for indent (matter of preference), do you think I should switch to space

I think you should switch to an exorcist.

Ah, the best kind of indent. A tab and a space.

Why would you ever need 9 other than trolling people on the internet?

When you’re operating on such a low level of abstraction, it’s no wonder you don’t need deep nesting.

What environment are you using that has a hardcoded tab size?

• Termux
• SourceHut
• “View page source” in the browser

Github uses 8 as a default. It’s configurable though.

What environment are you using that has a hardcoded tab size?

Microsoft Windows’ Notepad. I have sometimes used that when on a public computer.

Do not mix tabs and spaces.

Its impossible to automate checking that tabs were only used for indentation and spacing for precise alignment. So you then take on a burden of manually checking

You end up with the issue where someone didn’t realise and space idented or anouther person used tabs for precise alignment and people forget to check the whitespace characters in review and it ends up going inconsistent and becoming a huge pile of technical debt to fix.

Use only one, you can automate enforcement and ensure the code renders consistency.

My spontaneous reaction is that making some sort of braille oriented setting for some or hopefully most editors used by people with braille displays (I have no idea if using a “normal” editor even makes sense if you’re using a braille display) is the most pragmatic solution to their screens being taking up by spaces.

First of all, convincing everyone to use tabs is a monumental task. Convincing people with braille displays to use more convenient tools on the other hand seems pretty easy, why wouldn’t you want to use more convenient tools?

Secondly, there is a large amount of code written with spaces today, so even if people switch with tabs in the future you might still want to be able to read legacy code.

Thirdly, I don’t think that the choice of tabs vs. spaces is completely arbitrary because of alignment. Using tabs for indentation and space for alignment leads to a lot more micro management of whitespace compared to just using spaces. I would guess that alignment isn’t very braille friendly anyway, but it does make the code more readable for other people. Having a good braille editor affordance might be closer to letting us have our cake and eat it too.

Of course, I don’t know what this would look like exactly, and maybe there’s some sort of obstacle that I’m overlooking, I do want to be clear that this is just of the top of my head as someone who has never used a braille display.

struct Ident arr = [
{
.id
= 0,
.name
= "Bob",
.pubkey
= "",
.privkey
= ""
},
{
.id
= 1,
.name
= "Alice",
.pubkey
= "",
.privkey
= ""
}
];

seconded on not aligning things. its the whole source of the problem in the first place and doesnt even serve a purpose

You might not understand how to do it properly so here’s the idea:

Tabs will let you reach the indentation level of the current block, then from here, you’ll use spaces to align stuff property. Here’s an example, where >••• are tabs (I’m exaggerating alignment for the sake of the example) :

>•••if (condition1 == true
>••• || condition2 != false)
>•••{
>•••>•••struct ident people[] = [
>•••>•••>•••{
>•••>•••>•••>•••.name   = "bob",
>•••>•••>•••>•••.pubkey = "value1",
>•••>•••>•••},
>•••>•••>•••{
>•••>•••>•••>•••.name   = "alice",
>•••>•••>•••>•••.pubkey = "value2",
>•••>•••>•••}
>•••>•••];
>•••>•••secureConnection(people[0].name, people[0].pubkey,
>•••>•••                 people[1].name, people[1].pubkey,
>•••>•••                 CRYPTO_ALGO_DEFAULT);
>•••}

As you can see, everything will stay correctly aligned as long as it’s within the same block.

You’re confusing using tabs for indentation and spaces for alignment with using tabs and spaces for indentation. This means each line starts with tabs. Next you optionally have spaces for alignment with previous lines. Then you have content (like code or comments). Because you never have a tab following a space the alignment is never destroyed by adjusting how wide a tabstop is.

Looks like you missed the point. This is about indentation, not formatting.

Use tabs to indent your lines, but if you want to align a parameter with the parenthesis on the line above or something like that, you add spaces after the indentation tabs.

That way if someone wants to they can configure their tab length to 20 spaces and the indentation will remain consistent and the code will remain aligned.

Using only tabs for indentation and only spaces for alignment will never result in crap alignment when adjusting tabstops because the alignment does not use tabs.

This is using both tabs and spaces for alignment.

--->func foo(int i,
--->--->     int j);

Observe what adjusting the tabs does,

->func foo(int i,
->->     int j);

This uses only spaces for alignment,

--->func foo(int i,
--->         int j);

When converted the alignment is maintained because the tabstops aren’t used for alignment, only for indentation.

->func foo(int i,
->         int j);

I think you have it backwards. If you use tabs for indentation and spaces for alignment it works great for any tab size.

It is when you use a tab just as a compressed representation of 8 spaces and use them for alignment as well that it goes to shit. (because you have made the sin of tab == 8 spaces instead of the correct tab = 1 indent level)