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.

You are trying to slice a fine cut longitudinally through a hair, using a razor blade - this is a difficult thing to do :) You can argue that "technically" you are correct, but even on your own blog you say "The problem is that we're using tabs and spaces to format text for aesthetic reasons rather than treating them semantically" - that is, you are aware that most people consider the semantic of tabs differently to the ideal TUI utopia, and you want this "to change". Sure, I even agree with you. But it's just a wee bit on the "hypocritical" side to then turn around and say, and I quote your words again, "I am not actually changing the behaviour of tab characters" !! I assume you are trying to provide "reasonable logic grounds" to assist any movement in the direction you suggest (again, which I agree could be ideal in many circumstances, but certainly not in all circumstances). However, it ought go without saying that contradicting yourself (in the words you use --as others receive/ interpret those words--, is only going to weaken, not strengthen, your case . . .

A tab character tells the editor to position the text that follows it at the next tabstop. That doesn't change under elastic tabstops.

From a certain 'not inclusive of all existing semantic usage(s)' point of view, you are correct.

From many points of view of 'existing semantic for TAB', you will find vehement opposition based on --existing semantic for TAB--, and this ought be obvious.

All elastic tabstops does is set the positions of those tabstops.

No it does not! Here is why the words you have used are being charged as laced with hypocrisy (which I admit may well be completely unintended on your part) - existing semantic for "tab char" is indeed "set the position of tabstops, in a flexible, user-chosen way". This is the --existing-- usage! In Vim, I can set ts to 8 when trying to please the Linux kernel C boffins, to 4 (and replace with space characters) when treading in the godforsaken Python world, and to 3 (but don't replace with spaces), when programming in the truly enlightened Java modality. This is a LOT of flexibility! In fact, Vim is SO flexible, that I can configure it to know about EACH of these different tab requirements based on filetype, so I don't have to keep changing the ts setting every time I open a new file! This is close to TAB nirvana! And so! Although all of this complies with the common understanding of your words "All elastic tabstops does is set the positions of those tabstops", we must delve deeper to find the true disagreement. But the point is - if you wish to establish buy-in to your concept (even changing the -existing- (dominant) semantic for TAB, it may well behoove us (and when I say us, I mean us as in you :) to use words which express your concept with a little more precision.

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.

Again, not quite. Elastic tabstops have a little more different semantic to existing tabstops - you know this, I know this, and it is not in our interest for you or anyone to pretend they don't - that just generates counter-productive kickback.

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.

Not at all! Did "there's only one TAB key" make Python files in the slightest any more challenging than C files, or indeed the ultimately supreme "TAB is 3 spaces" Java files? Absolutely not! Let's say you go write a Vim module to implement elastic tabstops and save the TUI world from eternal damnation of limited TAB stop options we currently face. Since all the language syntax recognition machinery is already in place, all I then have to do is set elastictabs=true in my .vimrc and BAM! elastic tabstops shall be the one tab to rule them all (did I mention "BAM!"??). Either the Tab key works they way I want, or not. If it doesn't, I change my vim settings.

Thirdly, introducing a new whitespace character would just introduce all sorts of pain.

Possibly, but are you at all, possibly slightly, just remotely may be, ignoring the possibility that it might also -solve- certain problems?

People already have problems telling the difference between space and tab characters.

Yet they do. Successfully so. In Vim, "listchars" is your friend! Seriously, such problems as visualizing eol, tab, space, end-of-para and more, are well and truly solved by competent editing software - if you think this is not the case, you're selling yourself short with substandard software and so you probably need to dump Emacs and bite the bullet and learn Vim. Like seriously.

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.

Ok, you may have hear the little logical concept called "strawman" - if not, it's easy to search for and learn about, and it would be good for you to recognize that that's what you just did. A low ball by some standards, too. With listchars, I successfully, and optionally for each one, identify (or don't, if I prefer to ignore), tab, space and eol. Even xterm with standard X fixed fonts at relatively small point size has a dozen or so interesting chars to use to be "obviously different" enough to normal chars, to identify everything I need to. And anyway, you've (sort of impressively) snuck TWO strawmans in your one sentence here - the second being that "most people don't use two different indentation styles in the one text file, but I'm going to ignore this fact and pretend it's a major issue, and that now we'll have three or more indentation styles in MOST text files, and it's a massive issue and truly this is why we have to replace the -existing- semantic for TAB in order to save the world". I mean please, nice try, but TWO strawmen in the ONE sentence? I think this might be a case of premature rigorlogicus setting in - you might want to get that looked at :) :)

Thanks for thinking about the problem, but I don't think this is the right solution.

Your think might need more thunking. Thanks for responding, Zenaan

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