Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Lol, the commit message is just great https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

It's good that Linus is really exercising those 3rd party tools! They should send some money his way for helping them test their code.



> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

This web view renders tabs as spaces, so it's not possible so see what was changed.


These are a bit easier to see what's going on:

https://github.com/torvalds/linux/commit/d5cf50dafc9dd5faa1e...

https://github.com/torvalds/linux/blob/d5cf50dafc9dd5faa1e61...

Unfortunately Github doesn't have a way to render symbols for whitespace, but you can tell by selecting the spaces that the previous version had leading tabs. Linus changed it so that the tokens `default` and the number e.g. `12` are also separated by a tab. This is tricky, because the token "default" is seven characters, it will always give this added tab a width of 1 char which makes it always layout the same as if it were a space no matter if you use tab widths of 1, 2, 4, or 8.


People use tab width of 3 ;) just to keep us on our toes


Indentation by steps of 3 spaces is common in old Fortran 77 code. This is LAPACK for example. Scroll down to about line 400 to see actual code, not comments.

https://github.com/Reference-LAPACK/lapack/blob/master/SRC/c...


Tab width of 3 is actually really nice in languages like Lua or Ruby that have `end` as a delimiter. It makes nested blocks "step" down very aesthetically.


Do all text editors render "tab" with variable width, taking you to the next tab stop? For some reason up until now I was thinking that was always a word processor thing and I incorrectly assumed (perhaps because we usually don't use tabs for their original purpose) that a tab character was always rendered as constant width.


It's a typewriter thing and meant for writing tables, so tab has always advanced the cursor to the next "tabular" stop. What would be the use case of having them fixed width?


I don't know of any text editors that don't render variable width tabs based on the tabstop position. In programming environments we usually only use tabs at the beginning of the line for indentation, it's a bit more rare to use them for alignment due to inconsistent tabstop settings.

There's also Elastic Tabstops if you want to go all in on using tabs for alignment: https://nick-gravgaard.com/elastic-tabstops/


I maintain, that if everybody used a sufficiently smart editor, tabs for indentation and spaces for alignment would be the objectively correct choice.


If everybody used a sufficiently smart editor, and used sufficiently smart codegen, and we removed all the existing breakage from our tools and infrastructure, yes. I wish I lived in that world.

TBH my money is on that never happening, but maybe we will skip to an even higher level, where the canonical format for source code is the AST rather than plain text - indentation, braces, line length, all the things that humans care about but the computer doesn’t become render settings.


It’s happened more than once. Itemis built a whole pile of tools on it, and the things it enables (stacked DSLs lowering to C, for example).

Sadly, nobody wanted it. Check out https://mbeddr.com and weep for what could have been.


As long as we agree that the line length limit will be based on tab=8... are there smart editors that can check that?


I consider line wrapping to also be part of a sufficiently smart editor, and line limits should also go away in an ideal world.

The limiting factor on line length should be "is this too complex for your coworkers to understand"


A sufficiently smart editor can figure out everything by itself and doesn't need preformatted text.


More importantly not all editors use monospace font and can render tab shorter than space, so tabs in the middle of text make little sense.


Yes. This is the point of tabs. I'm convinced the whole tabs vs spaces thing is really people who understand this vs people who don't.


This gets to a dimension of the problem that is often overlooked: Git web viewers, like every other code viewer we use carries its own notion of the position of the tab stops.

Notably, this includes CLI shells, connected to a "terminal emulator", where what is being emulated is an ancient piece of hardware:

https://en.wikipedia.org/wiki/Teletype_Model_33

Semantics of the ASCII tab byte code:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

A far-downstream consequence of this is that source code formatted to an assumption of tab stops at other than 8-column intervals, as is not uncommon in Javascript, produces unreadable CLI output from diff, git-diff, ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: