elastic tabstops

Zenaan Harkness zen at freedbms.net
Fri May 19 04:11:34 PDT 2017


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



More information about the cypherpunks mailing list