5 ms·

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 t

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

by eviks 3y ago

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 ;)

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