Elastic tabs

[mathelec]

Before SublimeText, I needed this feature. But now, I just use multi-select…

[adzenith]

I guess I don’t really see how one substitutes for the other. I use multi-select and elastic tabstops together and it’s fantastic.

[tobia]

This does not work at all with a proportional font!

PS: I had not realized this thread was old. But it’s still not working!

[adzenith]

[quote=“tobia”]This does not work at all with a proportional font!

PS: I had not realized this thread was old. But it’s still not working![/quote]

Unfortunately there’s no way to get it to work with a proportional font: the API doesn’t allow either determining character width or inserting arbitrary-width spaces. The first could be worked around by opening the font myself and figuring out the character widths, but the second is a dealbreaker. Sorry!

[Stefano.Rausch]

Any chances that with the advent of ST3 elastic tabs could become reality?

[adzenith]

No, we still don’t have API support. This plugin is as close as you can get (and it doesn’t yet work in ST3 due to API changes).

[qgates]

While I’m not a fan of elastic tabs per se, I do feel there’s room for improvement in Sublime’s tab handling, the implementation for which should be fairly straightforward.

What I’m talking about here is simply definable tabstops. Just about every decent editor has this, and it’s essential if an editor is to become a programmer or technician’s “go to” for editing any kind of text files in the field. I have to drive another editor simply because Sublime is lacking in this basic area. And it’s a showstopper for a whole bunch of colleagues.

So, my old favourite “Brief” had simply a command “tabs” that went something like this “tabs 5 25 40 45”. That would define tabstops for the current buffer at those positions, and the remaining tabstops would be at a repeating interval of the last two (50,55,60,65 etc.). Some editors augment this by allowing tabstops to be left, centre and right aligned, though I see this as fairly pointless and only useful for formatting tables that are coded into tab delimited text files (in that case, you may just as well load stuff up in your favourite WP)

This is needed because text output files from numerous sources are tab delimited, and it’s not possible to work with such files formatted even remotely correctly in Sublime. Traditional programmers prefer this approach since it gives flexibility as to how things are spaced out horizontally. Moreover, a number of older, less popular programming languages work with particular indentation positions. The above tabstop model would support use of tabs or spaces in much the same way that Sublime does presently; knowing tabstop positions allows Sublime to convert tabs to spaces and spaces to tabs in the same way it does at present.

Sublime is already set up with very flexible configuration for this with its default, user, filetype and project preferences.

[mark4]

this would drive me absolutely CRAZY if i had the feature turned on.
it would drive me absolutely crazy if you didnt

[adzenith]

[quote=“mark4”]this would drive me absolutely CRAZY if i had the feature turned on.
it would drive me absolutely crazy if you didnt [/quote]

Wait, what?

[mark4]

[quote=“adzenith”]

[quote=“mark4”]this would drive me absolutely CRAZY if i had the feature turned on.
it would drive me absolutely crazy if you didnt [/quote]

Wait, what?[/quote]

Lol… One of the things im MAJORLY anal retentive about is source formatting. Cluster $*&# scatterbrain source formatting just drives me up the wall. I always indent by the same distance and always using spaces NEVER tabs. I always place my comments in the same column (i avoid interleaving comments with code etc). My source formatting is very VERY consistent across all my source files!

Having my indentations automaticlaly adjust themselves as i wrote code would be like eating garlik flavored ice cream… just WRONG!

but 99 times out of 100, when i look at someone elses sources which are cluster *$%! scatter brained i have to first reformat them just to be able to read them and retain what little sanity i have left. If you (they?) used this auto formatting even if the end result was not exactly to my liking it would be MUCH MUCH more consistent within the source file. So… i could not use this feature if it was ever implemented but if everyone else did it would be cool

thats what i meant ~

[tobia]

Unfortunately there’s no way to get it to work with a proportional font: the API doesn’t allow either determining character width or inserting arbitrary-width spaces.

Does it tell you what tab stop you’re at? Meaning which visual tab stop a given tab character is aligned to? If it does, then you could have an option to insert consecutive tabs to fake the elastic tabstops, instead of spaces. So that the plugin would only have to change the number of consecutive tab characters to keep the columns aligned. It would sometimes waste a bit of space, as in this example, but it would not be too bad.

[adzenith]

No, there’s no way to find out what tabstop you’re at. Scenarios like this are difficult:

[quote]iiiii ⇥ ⇥
mm ⇥
[/quote]

The tabs are being translated to single spaces by the forum software, unfortunately, but five i’s need two tabs, and two m’s need one tab, and there’s no way to figure that out using the Sublime API – you’d have to figure out what font is being used and do the math yourself.

[adzenith]

Support for ST3 has been added! Woo!
Thanks to lunixbochs for the edit abstraction.

[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!