3 ms·

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 a

by eviks 3y ago

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?

kragen 3y ago
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 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."
- eviks 3y ago
  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
  - kragen 3y ago
    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
    - eviks 3y ago
      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)
      - kragen 3y ago
        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 ;)

by eviks 3y ago

kragen 3y ago

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

eviks 3y ago
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
- kragen 3y ago
  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
  - eviks 3y ago
    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)
    - kragen 3y ago
      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 ;)