There is a new standard to solve the "multitude of existing standards" standard problem :) : https://editorconfig.org/ Oblig. XKCD: https://xkcd.com/927/ https://www.explainxkcd.com/wiki/index.php/927:_Standards Obligatory superiority sneer against all new standards aside, THIS new "editor config" standard appears to be one of the better standards, and possibly the ideal place to encourage "elastic tabs". Certainly given the dominance of Git in the DVCS world, this standard has a fine chance of becoming similarly dominant in the editor world. Enjoy, On Fri, May 19, 2017 at 10:05:16AM +0100, Nick Gravgaard wrote:
Hi Zenaan,
Using a character other than tab has been suggested before (either a new unicode code point or an existing one that's no longer widely used like vertical tab), but I disagree for a few reasons.
The first thing to note is that I am not actually changing the behaviour of tab characters. A tab character tells the editor to position the text that follows it at the next tabstop. That doesn't change under elastic tabstops. All elastic tabstops does is set the positions of those tabstops. If you run vi for instance, by default the tabstops are set at every 8 (or 4 or whatever) characters. If you run a word processor, the tabstops can be set manually at different positions on different lines. In these cases, and in the case of elastic tabstops, the tab character does the same thing.
Secondly, existing keyboards have a tab key. I think using a character which is impossible to insert using a regular keyboard would greatly damage adoption.
Thirdly, introducing a new whitespace character would just introduce all sorts of pain. People already have problems telling the difference between space and tab characters. It would be very difficult to understand 2 kinds of tab character with 2 sets of tabstops (one static, one elastic) in the same file.
Thanks for thinking about the problem, but I don't think this is the right solution.
Nick
On Fri, 19 May 2017, at 02:00, Zenaan Harkness wrote:
Hi Nick,
I kinda get that the future awaits and all the sins of past TUIs shall be forgiven: http://nickgravgaard.com/elastic-tabstops/
but I think you're pushing the metaphorical heap of cow dung uphill to change the "standard behaviour of tab stops".
However, Unicode is large and fullsome of characters, private code planes and future possibilities, and so a new ELASTIC_TAB character is perhaps the way to truly solve this existential crisis which all programmers and markdown authors face.
This way, the new super tab shall be semantically unified within itself, and not compromised by existing expectations and semantics, which is probably critically foundational to getting wide support for elastic tabs.
Time for someone to talk to someone from Unicode...
Regards, Zenaan