Vscode: Support Elastic Tabstops

[be5invis]

ref: http://nickgravgaard.com/elastic-tabstops/

[hax]

FYI, here is my experimental implementation for Atom: https://github.com/hax/atom-elastic-tabstops

[be5invis]

@hax Maybe they can consider the Sulime Text's implementation, which is adding spaces before tabs. It will perform better compatibility if you copy and paste the code into someplace else.

[hax]

@be5invis But it's not REAL Elastic Tabstops and lose many benefits of it. And as the original author, such implementations could not call itself "Elastic Tabstops". 🐹

[be5invis]

@hax I think an extension is insufficient. Maybe you should push a PR.

[hax]

@be5invis I think you are right, and that's why I didn't start to migrate my implementation for atom to vsc 🤔

[douglasg14b]

This would be pretty nice to have.

[NickStrupat]

@be5invis is it that the extension API is not deep enough to support this feature?

[lillem4n]

Is there a chance we will see this implemented?

[djmisterjon]

Is there a chance we will see this implemented?
I also need to do this sometime !

[gwimm]

Is there any work done on this?

[djmisterjon]

Is there any work done on this?

nice alternative here, but with some bug with comment.
https://marketplace.visualstudio.com/items?itemName=lmcarreiro.vscode-smart-column-indenter

[flying-sheep]

Today this extension only works with *.ts, *.js and *.json files

pass

[lillem4n]

Is there any work done on this?

nice alternative here, but with some bug with comment.
https://marketplace.visualstudio.com/items?itemName=lmcarreiro.vscode-smart-column-indenter

Is this actually using tabs or just pushing in spaces? If it is the latter I'd say it is not at all the same thing.

[martin-t]

Judging by the tests it seems it uses spaces which completely misses the point of elastic tabstops (which is that you don't need to reindent every time the length of the longest line changes so you have nice diffs AND always perfect columns).

[egasimus]

@lillem4n @martin-t I beg to differ. This argument (espoused by the author of the original concept, no less) was what IMHO prevented the adoption of elastic tabstops back in the days of Sublime Text when there was a pretty nice plugin for it.

The sad truth is we can't make elastic tabstops ubiquitous overnight; in an editor that does not support them, tab-based elastic tabstops would look wrong. However, the space-based approximation is completely portable - one could even maintain the alignment manually (like some of us do anyway), with the plugin taking over if available. A sort of "progressive enhancement", if you wish.

Thanks for the plugin link @djmisterjon, I'm going to give it a spin now.

[lillem4n]

@egasimus I see your point, but that implementation is something else. Indentation with tabs and alignment with spaces is enhancement from just spaces, but the risk there is it never progresses. It just works "good enough" and will stay that way. I'd love indentation perfection. :)

[martin-t]

At the risk of making the issue OT...

@egasimus Automatically creating tables with spaces might be a step in the right direction for some uses but it needs a different name. A lot of codebases avoid adjusting the column width in tables because it creates too much diff noise (which arguably is an issue with diff algos being too primitive). Calling it elastic tabstops will turn people off from it even though the true elastic tabstops would solve their issues.

Reusing the name of a good idea for a half-baked implementation is really not cool. At best it creates confusion among people who know both implementations and they end up talking past each other - both using the same terms but meaning different things. At worst people who don't know any better run into the bad implementation and discard the whole idea as bad. In my experience people are very prone to confusing bad ideas and bad implementations and the effort spent explaining "no, i mean the true elastic tabstops, they don't have these issues" is time that could have been spent more productively.

[lillem4n]

Oh, also, it is already named "Smart tabs": https://www.emacswiki.org/emacs/SmartTabs :)

[ExE-Boss]

Smart tabs is using spaces for alignment, so you get the same diff problems that were already mentioned.

[lillem4n]

@ExE-Boss Yes, that was my point. Smart tabs already exists as a different concept and does not solve the problem fully that elastic tabstops does.

[vanniewelt]

As many have pointed out, any implementation that uses spaces for alignment instead of tabs absolutely misses the point of "elastic tabstops" and should not be called such. Space alignment has that "diff problem" but the biggest issue is, in my opinion, that it assumes monospace font which is an absolute deal-breaker for anyone who likes to use proportional fonts (and "proportional" here does not necessarily mean some quirky Comic Sans, but very decent semi-proportional code fonts such as iA fonts or Input).

Why would someone want to use proportional font for code? For variety of reasons. It is simply aesthetically pleasing when letters have their own space and aren't forced to fit into uniform rectangles (more elaborate argument here). When one writes markdown, it is very sensible to use such proportional font. Elastic tabstops would be then an absolute killer feature for markdown tables — one could use proportional fonts and align table columns whithout needing to adjust all other rows — and the tabs would behave as in any text processor.

[martijn]

When writing Go (golang), the formatter aligns struct declarations using the elastic tabstops algorithm but the output looks messy in a proportional font for obvious reasons. Would this feature request, if ever implemented, fix that? Or is that another problem altogether?

It's a minor issue seeing ragged tabs in Go code, but since proportional fonts work so well otherwise it would be awesome to complete that functionality and free us from the monospace grid once and for all :)

[flying-sheep]

aligns struct declarations using the elastic tabstops algorithm

Important distinction, it’s called the “elastic tabstops lite” algorithm:

This hack looks at cells above and below the one that's being edited and appends/removes spaces to/from the ends of them to keep things lined up. It changes the contents of the buffer (ugh!) rather than changing the view.

This does keep things aligned but it has some significant disadvantages over proper elastic tabstops:

• only works with monospaced fonts
• means text cannot be replaced outside the editor through the use of sed etc. and still line up
• mixes tabs and spaces
• columns of text suddenly jump to the next fixed tabstop position once a cell gets too wide
• obviously an ugly hack

Inserting spaces in the buffer to push text to the next fixed tabstop position is obviously an ugly hack but I'm charitably going to call this "elastic tabstops lite" since it does have a similar effect even if the tabstops aren't being moved at all. If you end up implementing this hack, please use the name "elastic tabstops lite" so that users don't get confused.

[cblp]

Is it possible to add spaces only in view, stripping them when saved to disk?

Drawback: This still won't work with proportional fonts.

[isral]

4 years (T_T)

[Fire-]

Do we have an idea of the work breakdown required to actually implement this functionality?

[isral]

I implemented Elastic Tabstops Lite.
It's just a temporary solution though.

[isral]

I made Elastic Tabstops Mono.
This time it's a Visualization, not Formatters (not modify file).
Only works with monospaced fonts though.
Still a temporary solution though.
I keep both extensions because both have pros and cons.

[flying-sheep]

I made Elastic Tabstops Mono.

Oooh really cool! What’s the disadvantage of that one compared with ETL?

[isral]

I made Elastic Tabstops Mono.

Oooh really cool! What’s the disadvantage of that one compared with ETL?

Everything is broken:

• Cursor position around tab
• Vertical block selection
• ...

[isral]

Is it possible to get font width?
At least if I assume monospaced fonts used.

[Felice-Enellen]

I've used elastic tabstops in a few different contexts and I have always found them to be absolutely wonderful.

If we could get them to go mainstream I really think it would be a major, positive revolution in how we format code.

If VSCode would implement them (and after the botched multi-cursor horrorshow that is presented as "column selection" in VSCode, I have to emphasize: implement them _correctly_), I think it could go a long way towards making the concept mainstream.

They really are great. If you haven't ever looked into them, check out Nick's site, as mentioned in the OP:

http://nickgravgaard.com/elastic-tabstops/

I dream of a day when people just expect elastic tabstops in every editor, by default, the same way they currently expect static tabstops now. They're kind of the code equivalent of the underscore/asterisk markdown that's become the de facto way to format italics on the web.

[namibj]

If VSCode gets support for them, it would stop me from moving to Emacs and implementing them there. I know Emacs already handles mixed fonts/sizes inline quite well, allowing e.g. WYSIWYG markdown editing.

My motivation is that I want multi-column alignment to work for the font I will be using regardless, which is Input Sans, likely in a lighter, narrower variant than the default (but that depends on the screen and setup).