Comment by kragen | Hacker News Reader

Comment by kragen | Hacker News Reader

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

further details are in nestable.md in

    git clone http://canonical.org/~kragen/sw/pavnotes2.git

Why do you think it can't shrink below 1?

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

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

    00000000: 696e 7420 736f 6d65 4465 6d6f 436f 6465  int someDemoCode
    00000010: 2820 0969 6e74 2066 7265 642c 0a09 696e  ( .int fred,..in
    00000020: 7420 7769 6c6d 6129 0a                   t wilma).      .

(note the explicit space following the left paren) and render

    00000030: 696e 7420 736f 6d65 4465 6d6f 436f 6465  int someDemoCode
    00000040: 2809 696e 7420 6672 6564 2c0a 0969 6e74  (.int fred,..int
    00000050: 2077 696c 6d61 290a                       wilma).

as the more acceptable

    int someDemoCode(int fred,
                     int wilma)

which i think differs from gravgaard's intended semantics

I see. Yeah, in this case I'd also prefer no space betwen ( and int

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?

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

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."

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

Reply on news.ycombinator.com