[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

editorconfig.org - 927 configuration standards rolled into one - was Re: elastic tabstops

There is a new standard to solve the "multitude of existing
standards" standard problem :)


Oblig. XKCD: https://xkcd.com/927/

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.


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