Elastic tabs

[stoneym]

This would be much better if implemented as the inventor intended. The use of spaces as padding completely destroys the concept, and the original purpose of being able to code with a proportional font and still have your indents line up.

I agree with the inventor. We should be using spaces and tabs semantically. Spaces to separate keywords and tabs to indent code. Nothing else. Nada.

I would love if Sublime Text would implement this natively. It would have to to ever work properly. The changes necessary to the rendering engine for a plugin to handle this would be the same changes necessary for the editor to just do it. It could be an optional rendering mode and quite honestly should be fairly trivial to implement. There needs to be no counting or trickery, etc. You don’t need defined widths for tabstops anymore and you don’t need to define them at all really. You don’t have to care about font sizes or weights or kerning or anything. You only need to be able to detect if you have made all the text in a “column” visible. Here is the best example I can think of to explain the implementation that I would want.

Imagine that you were using Microsoft Excel or Libre Office/Open Office Calc with no grid lines visible. A nice blank canvas. Now imaging there is an option for columns to autosize themselves to the longest text in the column as you type. Anytime you hit tab it would simply take you to the next column in that row. When you hit enter it takes you to the next row and puts you in the first column that has data in the previous row. If the previous row has no text it plops you in the first column.

That is a proper elastic tabstops implementation. Until editors stop counting spaces and/or tabs and depending on monospaced fonts we won’t ever be out of this formatting mess when we try to look at some other group’s or individual’s code. If most major editors adhered to the elastic standard all code, monospace or proportional font, would be a lot easier to read and a lot more portable.

As an aside, and an alternate solution to the problem, I offer up the Gupta SQL Windows editor. It was a love it or hate it, definitely no in between, proposition. It was formatted as an outline. Everything treated like nested bullet points in word are, only it worked better. You never had to worry about tab width, spaces instead of tabs, tab stops, etc. Control flow was handled by indentation. For me it is still the best editor I ever used. It made life a lot easier when picking up the moron’s code from the cube next to you. It made certain things very clear and kept newbies from shooting themselves in the foot. I still do some maintenance work from time to time for old customers and I always enjoy working in this editor again. I am probably alone but I would prefer this even over elastic tabs. A modern and updated implementation that is.

[etatoby]

Still relevant in 2016. Still sorely needed.

[researchITeng]

much wanted feature!

[daanx]

Still very relevant in 2017! I would love to see this feature as it essentially enables the use of proportional fonts.
It would be great if SublimeText could support truly elastic tabstops (as opposed to the current plugin) – i.e. SublimeText should implement flexible tab positions per line.

There is currently a plugin for Atom that does get this right and it is very nice to be able to program with readable proportional fonts.

Let’s make SublimeText cutting edge

[Remi]

Interesting idea, though it does require the coder to actively use tabs in places desiring alignment when normally one might just hit a space. For instace,

entity mything is
    port (
        clk : in std_logic; -- this is a clock
        reset : in std_logic; -- this is a reset
        d : in std_logic; -- D flop input
        q : out std_logic -- Q output
    );
end entity mything;

Usually we’d like to align the : marks, the mode words, the type, and the comments. If you hit tab for all these things, it aligns quite nicely the way you’d like on the fly. But… you have to remember to hit tab in places where the natural flow would be to hit space.

Still, one could train oneself to do that, but it might feel awkward if one needed to transition between editors for whatever reason. Though that argument is true of any editor switch. Clearly you use different skills between vi, emacs, and notepad’esque editors, so maybe it doesn’t really matter all that much.

[matj1]

Elastic tabstops are useful not only in code (where I probably wouldn’t use them anyway because I align only with indentation), but they are useful for viewing tables in LATEX and Markdown with a proportional font.

This table can’t be aligned if it’s to be rendered with an unspecified proportional font, but an elastic tabstop at the end of each cell would make it aligned:

| Name | Surname |
| ---- | ---- |
| Joe | Dawkins |
| Elizabeth | Dean |

Name	Surname
Joe	Dawkins
Elizabeth	Dean

If there will be elastic tabstops supported in Sublime Text, I may use them for coding or not, but I will definitely use them for tables in Markdown, LATEX and other such formats.

[Jollywatt]

Elastic tabstops are the necessary answer to the problem of semantic indentation, wherein one tab means one level, with never the need for purely visual spaces or tabs. This is especially true for variable-width fonts, which are arguably the future of legible code.

Sublime Text is the closest to perfect of any text editor, in my opinion, when it comes to typography and variable-width fonts. Even VSCode does not render tab indentation correctly unless a monospace font is used. ST could easily become the gold standard for code/markdown typography were it possible to implement elastic tabstops.

As it seems to me, the minimal change required of the Sublime API to enable implementation of (true) elastic tabstops (first as a plugin, then perhaps more natively) is one of the following:

• Allow tab stop locations to be specified per line before rendering. By default, each line would specify the locations [w*n for n in ℕ], where w is the optical width of a space times the tab width setting.
  Because ST correctly handles fixed-width tabs for variable-width fonts, the current text rendering implementation must treat tabs as ‘jumps to absolute tabstop locations’, as opposed to merely rendering the equivalent number of spaces. Thus, it should not be drastically difficult to 1) make the locations variable, and 2) make the setting per-line.

• Alternatively, allow tab characters to be assigned an individual width before being rendered. This may be easier or harder depending on ST’s text rendering model.

Given either of these capabilities, and the ability to calculate the rendered width of a string of text (not containing tabs), a plugin would easily be able to calculate tabstop locations for all lines in a single pass of the document. When editing a line at indentation level n, only those lines ‘near’ to the one being edited would need to be re-rendered, where ‘near’ means “without a line with less than n tabs between it and the line being edited.”

I hope the devs consider this stepping-stone addition to the API!