Awesome idea, some decades-old MS Word niceties would be a big improvement in formatting, unfortunately no popular editors (even the new modern ones) seem to be properly engineered to allow implementing it
Huh, this might actually not be that difficult to make nowadays - modify a copilot plugin to prompt LLM for "grammar check" instead of completions, run it in the background like error checker, and use that output to add the blue squiggly lines to parts of code the LLM has an opinion on.
i keep coming back to gravgaard's idea, though i think the minimum width of a tab should be 0 spaces and not 1; it plausibly permits adding not just proportional fonts (as gravgaard points out) but also multiple font sizes to plain text without losing all ability to do layout
i think you should be able to nest multiple lines within such a 'table cell' by enclosing it between form feed and vertical tab, which are both conventionally considered whitespace, and are therefore allowed already in the grammars of conventional free-form languages like c, java, js, and scheme. nesting tables within table cells permits almost infinitely flexible layouts, as we all remember from the days before css; and, although the layout algorithm is not as trivial as emulating a teletype, it's fairly simple, linear time, and very fast (as long as you don't try to add word wrap or something)
(you probably also want rowspan and colspan; these should be indicated by putting carriage return and backspace, respectively, in the cells spanned into, like \^ in tbl)
a 'terminal emulator' using such a format would probably need an alternative to character-cell cursor addressing; probably the best alternative is to have multiple cursors, with one escape sequence to move cursor X to the active cursor (forgetting its previous position) and another escape sequence to exchange the active cursor with cursor X
there's no need for escape sequences to look like line noise either
the illustrations on gravgaard's page show a minimum of one space between columns, even in places where that seriously compromises the desired formatting, such as
int someDemoCode( int fred,
int wilma)
i think it would be better to represent that, where actually desired, by
you wouldn't use the tab ('horizontal tabulation') character to add space, but rather to separate table columns; you would use the space character to add space
But table columns are separated visually by whitespace otherwise you can't separate them in many cases when the text is glued together! (in richer formatting schemes this is achieved by border padding)
So, say, for TSV files (where you can't add spaces as that would affect the field values) you'd just have an editor with this feature let the max-width columns be glued, correct?
And speaking of wiki, the key part of tab is this (the etymology is just a historical artifact that should have no effect on what the best design is):
> Pressing the tab key would advance the carriage to the next tabulator stop.
The tabulation stops is another great missing feature from the MS Words of the world
if you don't have an escape sequence to set border padding for the current column or table, a simple expedient is to insert a space at the end of the widest cell of each column, or every cell if you don't know which cell is widest (say, because you're programmatically producing output to be rendered in an unknown font). it's true that there are occasional tsv files where that would corrupt your data (because they contain unquoted strings that aren't trimmed of trailing spaces on input), but those files are already in trouble with conventional terminals if a trailing space matters, because that data corruption would be invisible
if you have a header line, and your field names do get trimmed on input (or discarded), you can insert the padding spaces there
for tabular data display, escape sequences to insert vertical rules between columns are also desirable
the tab-stop mechanism is just a 19th-century limitation in the mechanical typewriter technology of the time. we can design new systems today that do what we think is most useful; from my point of view, arranging information in a table is more useful than advancing to the next tabstop
here's some output i got from vmstat 5 today
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1557232 132264 121644 1632328 1 4 34 48 17 57 12 5 83 0 0
0 0 1557232 132004 121652 1632368 0 0 0 9 561 971 1 1 98 0 0
1 0 1560816 233716 119836 1534920 0 717 0 4020 1286 2227 13 5 82 0 0
0 0 1560816 234220 119844 1534920 0 0 0 10 863 1919 3 2 95 0 0
ugh
as it happens, arranging text in tables also gives you the ability to do a flexible visual layout that accommodates proportional fonts of multiple sizes, so you can also stop using ugly typewriter fonts
we can stop imitating the typewriter's flaws now, we've had pixels for 60 years already. the question is how to make pixels as easy to use as a typewriter
Yeah, that's poor design to have to manually align with hardcoded chars (and is especially tedious when editing tables, where you would need to scan the whole table several times (for each column) to find the widest and add a space, then redo that manual action on table edits) when we're taking about a feature that allows automatic alignment
(not sure how escape sequences help in the editor, that would still be extra manual chars inserted into each column?)
I think a better approach would be for the editor to zero tabs in semantic locations like function(arguments)
The tabstops aren't mechanical limitations in apps, the allow you to manually adjust the offset, which works great, eg, for comments (set all comments at a tabstop at column 80 even for not-contiguous blocks of code, where elastic tabstops wouldn't work, although proper design would also need semantic awareness not to conflict)
it's true that it might be important for it to not be too much work to hand-edit tabular data represented this way, without gluing together text in separate columns so it misleadingly looks like a single string
you could have your editor insert the trailing space automatically (perhaps with exceptions for cases like function(<tab>arguments)), then manually delete the space in the cases where you don't want whitespace between table columns; this might even be a good default for things like editing c and js, which is kind of annoying to do without editor support for auto-indentation
you could very reasonably have a single escape sequence that sets a minimum padding for all the columns present on the current line; prepending it to the first line of a tsv file on output, or appending it to the last, might cover the tsv-editing case relatively well. or you could nest the tsv file inside a form-feed/vertical-tab pair, and define the escape sequence to apply to everything inside that cell
my concern is to make the format able to express general layouts, not to make it maximally compressed
manually adjusting tabstops is only an adequate replacement for a general string representation for nested tabular text layouts in a few niche special cases like a single developer looking at their own code. it doesn't help vmstat or ls to produce more readable output, enable a program to use multiple font sizes in its output without worrying about font metrics or html reflow speed, make tabular data easy to edit, replace the windowing system, or even enable two developers editing the same plaintext code on different computers to format it so the other person can read it easily
vanilla elastic tabstops are i think not very well suited to keeping comment blocks on the right aligned across multiple indentation levels of code; my proposal of nested table cells can do that in the special case where all your lines are the same height. alternatively, even with gravgaard's vanilla proposal, you can keep your comment blocks aligned, as long as you put them to the left of your code and not the right
btw i saw that someone downvoted your comment, so i upvoted it; hopefully that keeps it from falling back into the grey. you're bringing up some important considerations even if not all your points are well thought out ;)
> you could have your editor insert the trailing space automatically (perhaps with exceptions for cases like function(<tab>arguments)), then manually delete the space in the cases where you don't want whitespace between table columns
That's just as bad, manual fiddling is precisely what autoformatting algorithms are supposed to solve. Especially in the more painful cases of tables. Also, inserting many spaces in large tables is a rather costly operation, I have to use debouncing in the current elastic tabstops plugins that align with spaces to avoid that cost on every keypress. Also, you're asking to differentiate between the two invisibles (tabs and spaces), that would require making one of them visible, but then in many cases that visibility would be legal and thus just visual noise
> you could very reasonably have a single escape sequence that sets a minimum padding for all the columns present on the current line;
You can't do that since in many languages these sequences would be invalid input
> my concern is to make the format able to express general layouts, not to make it maximally compressed
Yet your format can't do that without a lot of manual fiddling
> manually adjusting tabstops is only an adequate replacement for a general string representation for nested tabular text layouts in a few niche special cases like a single developer looking at their own code
This also works in such niche special case as non-code editing
if a format supports layouts with space between columns and layouts without, you do need some user-interface action ("manual fiddling") to choose between them, whatever the default is
if you only support one of the two options, it's true that you don't need that user-interface action, but that's not because it requires less manual fiddling to achieve the same result; it's because it can only achieve the result that the more expressive format could achieve without manual fiddling, while the other option becomes impossible instead of fiddly
and that's true regardless of whether the fiddling-free option has the extra spacing or lacks it
you seem to have been responding to an earlier edition of my comment, by the way, because your response no longer makes sense in context because i already clarified some things you misunderstood; i mention this partly in case other people are puzzled as to what you are talking about
i didn't realize you'd implemented elastic tabstops yourself! which editors did you write it for?
i don't agree that relayout of a large table with new column widths is an inherently expensive operation (in the absence of word wrap) but i can easily believe that there are software environments that make it so
I agree with you mostly, but it's funny how you say we should move on, but then suggest using pixels, as if that wasn't repeating the problem with aligning to characters.
The alignment logic should be separated from the appearance: use some codepoint to mark each cell of a column, calculate the minimum x from all cells of the column, and then - when displaying text - apply eventual font hinting to round up (right) this x…
yes, agreed; specifically I had in mind codepoint 9
i wasn't suggesting manually positioning text pixel by pixel, but rather taking advantage of the potentials unlocked by displaying text with pixels rather than a teletype
int animateIndenting(
int startingIndent, /// Starting indent, in spaces
int endingIndent, /// Ending indent, in spaces
int animationTimeMs /// Animation time in milliseconds
) {
...
}
is tempting. It's an interesting idea. Whether it's a good idea. It's hard to be completely objective when, for a brief time in the 80s, I spent one third of all my coding time maintaining elaborately baroquely indented Pascal comments. (Not my coding standard. It was fashionable at the time).
That the formatter doesn't replace tabs with space... quaintly
optimistic. A great shame, since requiring that people use
editors with this feature for all eternity, or have ridiculously random indentation of comments is a non-starter.
The key difference you are outlining here is form vs function. The latter example is perfectly reasonable because you are adding actual “content” and restructuring around that. I don’t think any reasonable person could object to that - coding guidelines bedamned.
GP’s example is just finicky window dressing based on indulging a personal aesthetic based on what the author things “looks good” on a particular day, with a particular font on a particular screen.
What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools.
EDIT
> What happened to "code is primarily to be read, occasionally to be executed"?
Exactly this. Code should be readable for all. It goes through all sorts of other actors and tooling, not just your painstakingly configured IDE.
>> What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools.
> as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers …
All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against.
We have many, many coding standards most of which discourage tabs and fancy formatting but developers get special exemption because “ma creativiteh”
> plaintext code directly is an idea that needs to die.
Yes let’s throw out some things that work perfectly well to accommodate a few malcontent crybabies.
At the end of the day our laws and most of our written communication depends heavily on plaintext and that’s not gona change any time soon just because a few people don’t want to learn how to use it properly.
> What we should be striving for in code style is the lowest common denominator most bare bones structure that can be read, understood and modified with the most rudimentary of tools.
What happened to "code is primarily to be read, occasionally to be executed"? You're suggesting we should be optimizing for the wrong thing.
To be honest, this is just another unsolvable issue that's a direct result of us insisting on keeping the code as plaintext and insisting we work directly on it and only it, the single source of truth, using bare-bones tools.
It's really as dumb as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers, decorators, landscapers and others - were forced to use the same, single, canonical, flat technical drawing. You can imagine they'd be wasting much time on endless holy wars on the right drawing scale, right colors, line thickness, where to put the legend, how to make annotations, etc. - where the real problem is that a single flat piece of paper (or digital equivalent) can't possibly accommodate all their needs at the same time.
We're like that, and here we're discussing whether to align labels on the drawing to the left or to the right, in hopes it'll somehow make an impenetrably dense drawing an iota more readable. We're going as far as to play with dark monadic magick, inventing convoluted drawing techniques in order to somehow squeeze layout of cables, water pipes and air vents in a way that makes decorators shut up about not being able to visualize the building in their heads, because the plan is too dense or too non-local or whatnot. And we're so proud that we automated the ability to xerox the plan for different teams to add more squiggles independently, and then merge them into a new unified plan the next day, and even have an audit trail by putting SHAs on everything.
Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.
> Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.
I use Obsidian, because it's a cool notepad software that stores everything as plain text. This means at any point in time, if Obsidian stops being developed (and supported by up-to-date OSes), or there's a new better software, or stops being free to use - I can just stop using it, and I still have my notes. This is just one of many strengths of the plain text. Compatibility is another.
I know, I'm not actually editing those plain text files directly. I can, however.
Plain text as a storage format is fine; it's inefficient, but has longevity benefits you mention.
Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.)
The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously.
The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.
> All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against.
This is a huge logical error. You just proposed to use the lowest common denominator, but then your response to the analogy is that other people are constrained by rules. Yes, they are constrained by rules, that are very complex, and even then, the constraint ensures a minimal standard, it doesn't block you from creativity. Fire prevention rules will define how wide a corridor has to be, but it won't forbid you to build a wider corridor or to paint its walls.
BTW editing your post to answer a post below you wasn't the smartest thing to do…
No I meant the standardised approach is the lowest common denominator. It’s the least common unit that has been agreed upon. Category Error at worst, but well within colloquial bounds.
I've found that code formatting in general is massively overrated. Same with consistent function naming.
Once you get over the initial OCD it is quite liberating to not be bound by any rules. And with languages such as C you end up mixing all kinds of naming conventions anyway.
What matters much more are idioms, matching interfaces and descriptive names.
> What matters much more are idioms, matching interfaces and descriptive names
Once you get over that as well, it's also quite liberating to not be bound by rules. This does go into unlawful-chaotic territory for some people though
We space users all use the tab key. We just make sure our editor replaces them with spaces as we type because of decades of bitter experience with how mixed tabs and spaces behave over time.
The more interesting question is why tab users haven't noticed that we use mandatory auto-code-formatting these days, to make sure all your tabs are belong to us.
> The more interesting question is why tab users haven't noticed that we use mandatory auto-code-formatting these days, to make sure all your tabs are belong to us.
I'm guessing they're using an equivalent of `M-x tabify` running automatically after opening a file.
Excerpt from documentation on `tabify` in Emacs:
Convert multiple spaces in region to tabs when possible.
A group of spaces is partially replaced by tabs
when this can be done without changing the column they end at.
If called interactively with prefix ARG, convert for the entire
buffer.
Personally, I'm a "space user", and I only have `delete-trailing-whitespace` run on save (`before-save-hook`); at work, we have a pre-commit hook that untabifies committed changes (and then another to run language-specific autoformatter).
Yeah, great idea, let's adopt it. Then in three years from now juniors can add "tab management" to their "to learn" list and get into flamewars which "tab management" tool or plugin is the best.
Not everything Google does is gospel, it feels kind of weird that you post these without further context.
Although most coding guidelines seem to have converged towards spaces over tabs (see [1], [2],[3], your source, and many more), it also causes accessibility issues, especially for visually impaired people.
Some people require larger fonts, making space-indented lines go offscreen quicker. Some people require braille displays, which have a limited line length. A tab takes a single character on these, vs multiple (usually 4) for space-indented code. Some people require bigger indents to be able to process them better.
Not even considering disabilities, some people prefer 2 spaces, some 4, and some whatever pleases them. Working with tabs allows everyone to work on the same codebase with their own preference. By definition this is a subjective matter, and trying to enforce a preference across a whole codebase or programming language is needlessly opinionated.
Plus, the 2 first example use case in the article can't be solved either with spaces or standard tab stops.
> Four spaces should be used as the unit of indentation. The exact construction of the indentation
> (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4).
While leaving tabs vs. spaces "unspecified", specifying stabstops of 8 spaces actively discourages tabs
Thanks for all the additional info! I should have added that my preference is for the definition of a unified gospel throughout the codebase/organization, Google's just being the one we ended up picking.
>Working with tabs allows everyone to work on the same codebase with their own preference.
This is where the problem starts. As someone who has to integrate code from a dozen devs, it seems that everyone has a sligthly different usage of tabs (TFA adding one more). If we can ever set everyone on the same page with tabs, I am fine with it. It's just that in production it always seems to cause problems. Spaces are easier to specify.
For the case of disability support, I'd risk to guess that different usages of tabs would end up derailing accessibility software just as much as it derails integration. But I'd prefer deferring this opinion to someone who has experience with it.
I've been using proportional fonts in emacs since many years ago, I can't remember how many. When I find code aligned with spaces to a horizontal position I keep it there. If I have to modify it I realign everything. Example
a = 1
ab = 2
abc = 3
becomes
a = 1
change = 2
abc = 3
Nobody ever said a word about it.
In Elixir projects we've been using the language code formatter for years and it forces a coding style like mine by default.
One of my pet peeves is when I go to the trouble of lining up my indents, usually for some good reason like improving clarity or readability and some busybody comes along and flattens it all for no good reason other than pandering to their own personal aesthetic.
One of my pet peeves is when I go to the trouble of flattening indents, usually for some good reason like improving clarity or readability and some busybody comes along and indents it all for no good reason other than pandering to their own personal aesthetic.
Honestly, I use spaces because virtually all tooling and coding conventions that exist prefer spaces over tabs, but I don't understand how it came that spaces won over tabs in the programming world. So much energy wasted on counting spaces in text documents, it's absurd.
Please engage with the substance of my comment rather than just further iterating the argument that’s in your head. It is equally frustrating whether tabs or spaces.
I press tab in emacs and it inserts or removes the right amount of spaces to indent the line. I press newline and it creates a new line with the correct space based indentation.
If I'm in Python I can press tab multiple times to cycle through indentation levels or do it manually with space and the deletion keys.
This is something we've discussed[1] in the development of Topiary, deferring the process to the formatter. It's not a priority issue for us right now, but given the lack of universal editor support for elastic tab stops, having the formatter do this seems like a reasonable solution.
> Rather than saying that a tab character places the text that follows it at the next Nth column, we should say that a tab character is a delimiter between table cells in a manner more reminiscent of how they're used in tab separated value (TSV) files. When used for text or code I call this format "Tab Separated Columns". Seen in this light, we can see that space aligned files are analogous to the old fixed width data files, and we all know the advantages that delimited files have over those.
If we're lifting abstraction one level up - from dumb plaintext to delimited records - maybe it's time to revive the ASCII control characters that were specifically meant for this? I'm talking about ASCII 28 to ASCII 31 - file, group, unit and record separators.
my variant proposal in https://news.ycombinator.com/item?id=37938960 provides for arbitrarily deeply nested structures instead of a pick-like static four levels, and does so while maintaining compatibility with historical definitions of "whitespace" for the purpose of things like parsing c; i'm curious to hear what you think, though i know you're not such a fan of backwards compatibility
it does not; the idea is not to insert extra space characters into files, but to display tab characters as a quantity of whitespace sufficient to visually align columns vertically
My memory might be incorrect, but I recall using a version of MacPascal in the early 90s, that gave you absolutely no control whatsoever over indentation - pressing tab or space outside of a quoted string did nothing at all. The editor indented automatically according to the code you typed and some (presumably) hard coded rules.
It was the most liberating thing I had ever encountered in the act of coding, and I still yearn for it.
62 comments
[ 3.3 ms ] story [ 108 ms ] threadi think you should be able to nest multiple lines within such a 'table cell' by enclosing it between form feed and vertical tab, which are both conventionally considered whitespace, and are therefore allowed already in the grammars of conventional free-form languages like c, java, js, and scheme. nesting tables within table cells permits almost infinitely flexible layouts, as we all remember from the days before css; and, although the layout algorithm is not as trivial as emulating a teletype, it's fairly simple, linear time, and very fast (as long as you don't try to add word wrap or something)
(you probably also want rowspan and colspan; these should be indicated by putting carriage return and backspace, respectively, in the cells spanned into, like \^ in tbl)
a 'terminal emulator' using such a format would probably need an alternative to character-cell cursor addressing; probably the best alternative is to have multiple cursors, with one escape sequence to move cursor X to the active cursor (forgetting its previous position) and another escape sequence to exchange the active cursor with cursor X
there's no need for escape sequences to look like line noise either
further details are in nestable.md in
That's exactly what's happening in currently rudimentary implementations like in Sublime Text, where width can be smaller if needed for alignment
The "spec" also doesn't seem to mandate a minimum
But then in your design how would you Tab to actually add whitespace, not just vertically align? Would then 2nd tab have a width of 1 space?
https://en.wikipedia.org/wiki/Tab_key
> The word tab derives from the word tabulate, which means "to arrange data in a tabular, or table, form."
So, say, for TSV files (where you can't add spaces as that would affect the field values) you'd just have an editor with this feature let the max-width columns be glued, correct?
And speaking of wiki, the key part of tab is this (the etymology is just a historical artifact that should have no effect on what the best design is):
> Pressing the tab key would advance the carriage to the next tabulator stop.
The tabulation stops is another great missing feature from the MS Words of the world
if you have a header line, and your field names do get trimmed on input (or discarded), you can insert the padding spaces there
for tabular data display, escape sequences to insert vertical rules between columns are also desirable
the tab-stop mechanism is just a 19th-century limitation in the mechanical typewriter technology of the time. we can design new systems today that do what we think is most useful; from my point of view, arranging information in a table is more useful than advancing to the next tabstop
here's some output i got from vmstat 5 today
ughas it happens, arranging text in tables also gives you the ability to do a flexible visual layout that accommodates proportional fonts of multiple sizes, so you can also stop using ugly typewriter fonts
we can stop imitating the typewriter's flaws now, we've had pixels for 60 years already. the question is how to make pixels as easy to use as a typewriter
(not sure how escape sequences help in the editor, that would still be extra manual chars inserted into each column?)
I think a better approach would be for the editor to zero tabs in semantic locations like function(arguments)
The tabstops aren't mechanical limitations in apps, the allow you to manually adjust the offset, which works great, eg, for comments (set all comments at a tabstop at column 80 even for not-contiguous blocks of code, where elastic tabstops wouldn't work, although proper design would also need semantic awareness not to conflict)
you could have your editor insert the trailing space automatically (perhaps with exceptions for cases like function(<tab>arguments)), then manually delete the space in the cases where you don't want whitespace between table columns; this might even be a good default for things like editing c and js, which is kind of annoying to do without editor support for auto-indentation
you could very reasonably have a single escape sequence that sets a minimum padding for all the columns present on the current line; prepending it to the first line of a tsv file on output, or appending it to the last, might cover the tsv-editing case relatively well. or you could nest the tsv file inside a form-feed/vertical-tab pair, and define the escape sequence to apply to everything inside that cell
my concern is to make the format able to express general layouts, not to make it maximally compressed
manually adjusting tabstops is only an adequate replacement for a general string representation for nested tabular text layouts in a few niche special cases like a single developer looking at their own code. it doesn't help vmstat or ls to produce more readable output, enable a program to use multiple font sizes in its output without worrying about font metrics or html reflow speed, make tabular data easy to edit, replace the windowing system, or even enable two developers editing the same plaintext code on different computers to format it so the other person can read it easily
vanilla elastic tabstops are i think not very well suited to keeping comment blocks on the right aligned across multiple indentation levels of code; my proposal of nested table cells can do that in the special case where all your lines are the same height. alternatively, even with gravgaard's vanilla proposal, you can keep your comment blocks aligned, as long as you put them to the left of your code and not the right
btw i saw that someone downvoted your comment, so i upvoted it; hopefully that keeps it from falling back into the grey. you're bringing up some important considerations even if not all your points are well thought out ;)
That's just as bad, manual fiddling is precisely what autoformatting algorithms are supposed to solve. Especially in the more painful cases of tables. Also, inserting many spaces in large tables is a rather costly operation, I have to use debouncing in the current elastic tabstops plugins that align with spaces to avoid that cost on every keypress. Also, you're asking to differentiate between the two invisibles (tabs and spaces), that would require making one of them visible, but then in many cases that visibility would be legal and thus just visual noise
> you could very reasonably have a single escape sequence that sets a minimum padding for all the columns present on the current line;
You can't do that since in many languages these sequences would be invalid input
> my concern is to make the format able to express general layouts, not to make it maximally compressed
Yet your format can't do that without a lot of manual fiddling
> manually adjusting tabstops is only an adequate replacement for a general string representation for nested tabular text layouts in a few niche special cases like a single developer looking at their own code
This also works in such niche special case as non-code editing
if you only support one of the two options, it's true that you don't need that user-interface action, but that's not because it requires less manual fiddling to achieve the same result; it's because it can only achieve the result that the more expressive format could achieve without manual fiddling, while the other option becomes impossible instead of fiddly
and that's true regardless of whether the fiddling-free option has the extra spacing or lacks it
you seem to have been responding to an earlier edition of my comment, by the way, because your response no longer makes sense in context because i already clarified some things you misunderstood; i mention this partly in case other people are puzzled as to what you are talking about
i didn't realize you'd implemented elastic tabstops yourself! which editors did you write it for?
i don't agree that relayout of a large table with new column widths is an inherently expensive operation (in the absence of word wrap) but i can easily believe that there are software environments that make it so
The alignment logic should be separated from the appearance: use some codepoint to mark each cell of a column, calculate the minimum x from all cells of the column, and then - when displaying text - apply eventual font hinting to round up (right) this x…
i wasn't suggesting manually positioning text pixel by pixel, but rather taking advantage of the potentials unlocked by displaying text with pixels rather than a teletype
- do not indent code that way
- do not align comments on the side
Before
After This kind of control over indentation and alignment borders on OCD. You should be using a code formatter anyway, so indentation is auto-fixed.That the formatter doesn't replace tabs with space... quaintly optimistic. A great shame, since requiring that people use editors with this feature for all eternity, or have ridiculously random indentation of comments is a non-starter.
GP’s example is just finicky window dressing based on indulging a personal aesthetic based on what the author things “looks good” on a particular day, with a particular font on a particular screen.
What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools.
EDIT > What happened to "code is primarily to be read, occasionally to be executed"?
Exactly this. Code should be readable for all. It goes through all sorts of other actors and tooling, not just your painstakingly configured IDE.
>> What we should be striving for in code style is the lowest common denominator most bare bones strucure that can be read, understood and modified with the most rudimentary of tools.
> as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers …
All the above have to abide by building codes, use standardised parts and tools and most have to conform to certified standards which their work is then also validated against.
We have many, many coding standards most of which discourage tabs and fancy formatting but developers get special exemption because “ma creativiteh”
> plaintext code directly is an idea that needs to die.
Yes let’s throw out some things that work perfectly well to accommodate a few malcontent crybabies.
At the end of the day our laws and most of our written communication depends heavily on plaintext and that’s not gona change any time soon just because a few people don’t want to learn how to use it properly.
What happened to "code is primarily to be read, occasionally to be executed"? You're suggesting we should be optimizing for the wrong thing.
To be honest, this is just another unsolvable issue that's a direct result of us insisting on keeping the code as plaintext and insisting we work directly on it and only it, the single source of truth, using bare-bones tools.
It's really as dumb as if, when designing a building, everyone involved - architects, plumbers, electricians, HVAC engineers, decorators, landscapers and others - were forced to use the same, single, canonical, flat technical drawing. You can imagine they'd be wasting much time on endless holy wars on the right drawing scale, right colors, line thickness, where to put the legend, how to make annotations, etc. - where the real problem is that a single flat piece of paper (or digital equivalent) can't possibly accommodate all their needs at the same time.
We're like that, and here we're discussing whether to align labels on the drawing to the left or to the right, in hopes it'll somehow make an impenetrably dense drawing an iota more readable. We're going as far as to play with dark monadic magick, inventing convoluted drawing techniques in order to somehow squeeze layout of cables, water pipes and air vents in a way that makes decorators shut up about not being able to visualize the building in their heads, because the plan is too dense or too non-local or whatnot. And we're so proud that we automated the ability to xerox the plan for different teams to add more squiggles independently, and then merge them into a new unified plan the next day, and even have an audit trail by putting SHAs on everything.
Seriously, our whole approach and tooling ecosystem is tripling down on idiocy. Editing the same, single source of truth, plaintext code directly is an idea that needs to die.
I use Obsidian, because it's a cool notepad software that stores everything as plain text. This means at any point in time, if Obsidian stops being developed (and supported by up-to-date OSes), or there's a new better software, or stops being free to use - I can just stop using it, and I still have my notes. This is just one of many strengths of the plain text. Compatibility is another.
I know, I'm not actually editing those plain text files directly. I can, however.
Plain text as representation to read, write and edit is also fine - many things are best expressed this way, and text lends itself to be edited efficiently by advanced tools (e.g. vim, Emacs, or sed, awk, etc.)
The issue is not with either of them alone. The problem seems from using the same plaintext documents for both storage and representation simultaneously.
The solution is to have a storage format optimized for storage - which could just as well stay plaintext - but all reading, writing and editing to be done through tools that render you a representation best suited for what you need at the moment. This could be plaintext prose now, plaintext code an hour from now, and a pile of editable, graphical state machine diagrams tomorrow.
Plaintext is for interchange not storage. You can optimise for storage by putting .gz on the end of it.
> writing and editing to be done through tools that render you a representation best suited for what you need at the moment.
XML? XSLT?
This has been tried and it’s easily done if you want nobody to like you.
The crux of the issue is interchange. Neither of the things you have so vociferously decried. As usual, somewhere in the middle.
The lowest common denominator is plain text and that’s what works best en masse for all the participants and tooling.
This is a huge logical error. You just proposed to use the lowest common denominator, but then your response to the analogy is that other people are constrained by rules. Yes, they are constrained by rules, that are very complex, and even then, the constraint ensures a minimal standard, it doesn't block you from creativity. Fire prevention rules will define how wide a corridor has to be, but it won't forbid you to build a wider corridor or to paint its walls.
BTW editing your post to answer a post below you wasn't the smartest thing to do…
The code formatters aren't good enough (and also elastic tabstops work realtime)
What matters much more are idioms, matching interfaces and descriptive names.
Once you get over that as well, it's also quite liberating to not be bound by rules. This does go into unlawful-chaotic territory for some people though
This won't do much to sway these programmers
We space users all use the tab key. We just make sure our editor replaces them with spaces as we type because of decades of bitter experience with how mixed tabs and spaces behave over time.
The more interesting question is why tab users haven't noticed that we use mandatory auto-code-formatting these days, to make sure all your tabs are belong to us.
;-P
I'm guessing they're using an equivalent of `M-x tabify` running automatically after opening a file.
Excerpt from documentation on `tabify` in Emacs:
Personally, I'm a "space user", and I only have `delete-trailing-whitespace` run on save (`before-save-hook`); at work, we have a pre-commit hook that untabifies committed changes (and then another to run language-specific autoformatter).Not all. I've seen people hit spaces repeatedly…
,
We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key."
https://google.github.io/styleguide/cppguide.html#Spaces_vs....
Although most coding guidelines seem to have converged towards spaces over tabs (see [1], [2],[3], your source, and many more), it also causes accessibility issues, especially for visually impaired people.
Some people require larger fonts, making space-indented lines go offscreen quicker. Some people require braille displays, which have a limited line length. A tab takes a single character on these, vs multiple (usually 4) for space-indented code. Some people require bigger indents to be able to process them better.
Not even considering disabilities, some people prefer 2 spaces, some 4, and some whatever pleases them. Working with tabs allows everyone to work on the same codebase with their own preference. By definition this is a subjective matter, and trying to enforce a preference across a whole codebase or programming language is needlessly opinionated.
Plus, the 2 first example use case in the article can't be solved either with spaces or standard tab stops.
---
[1] https://peps.python.org/pep-0008/#tabs-or-spaces
> Spaces are the preferred indentation method
[2] https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
> Use four spaces for indentation. Don't use tabs
[3] https://www.oracle.com/technetwork/java/codeconventions-1500...
> Four spaces should be used as the unit of indentation. The exact construction of the indentation > (spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4).
While leaving tabs vs. spaces "unspecified", specifying stabstops of 8 spaces actively discourages tabs
>Working with tabs allows everyone to work on the same codebase with their own preference.
This is where the problem starts. As someone who has to integrate code from a dozen devs, it seems that everyone has a sligthly different usage of tabs (TFA adding one more). If we can ever set everyone on the same page with tabs, I am fine with it. It's just that in production it always seems to cause problems. Spaces are easier to specify.
For the case of disability support, I'd risk to guess that different usages of tabs would end up derailing accessibility software just as much as it derails integration. But I'd prefer deferring this opinion to someone who has experience with it.
Do you want to say: Google bad, Google good or what?
In Elixir projects we've been using the language code formatter for years and it forces a coding style like mine by default.
Honestly, I use spaces because virtually all tooling and coding conventions that exist prefer spaces over tabs, but I don't understand how it came that spaces won over tabs in the programming world. So much energy wasted on counting spaces in text documents, it's absurd.
Who on earth is counting spaces?
If I'm in Python I can press tab multiple times to cycle through indentation levels or do it manually with space and the deletion keys.
[1]: https://github.com/tweag/topiary/issues/170
If we're lifting abstraction one level up - from dumb plaintext to delimited records - maybe it's time to revive the ASCII control characters that were specifically meant for this? I'm talking about ASCII 28 to ASCII 31 - file, group, unit and record separators.