Enhancement: Give an option to consider indention/block deep.

[SK-Genius]

Don't provide ElasticTabstop over lines with different indent deep.

expected:

f(x, y):
[->]if x > y:
[->][->]temp[->]:= x
[->][->]x[---->]:= y
[->][->]y[---->]:= temp
[->]start[->]:= 1
[->]end[--->]:= 10
[->][...]

unexpected:

f(x, y):
[->]if x > y:
[->][------>]temp[->]:= x
[->][------>]x[---->]:= y
[->][------>]y[---->]:= temp
[->]start[->]:= 1
[->]end[--->]:= 10
[->][...]

[nick-gravgaard]

Sorry, I should have replied to this earlier.

I did think about doing this back in 2006 as can be seen in the comment section of this blog post:

Without using knowledge of the language being edited (block delimiters, etc) perhaps it could be fixed by taking note of which lines contain leading tabs and treating them slightly diferently.

I've had that idea at the back of my mind for weeks but I'm a little reluctant to implement it. The problem is that I don't want the system to be too complicated or users may think it's unpredictable.

but I never did it!

That was silly of me. I'll make it a configurable setting, and then we can all try it out! 😀

[geroldmeisinger]

I think this is an interesting option to have as it would also give people the option to choose "begin-block character on same line" instead of "on new line" in some cases, like JSONs:

{
→   "myint"↔   : 123,
→   "myfloat"↔ : 0.5,
→   "mystr"↔   : "abc",
→   "myobj0"↔  : {
→   →    "id"↔   : 0,
→   →    "name"↔ : "Alfa"
→   }

and because the braces on same line code style for functions is so common:

without indent awareness:

foo↔       (v => "Alfa")↔  // some
foobar↔    (v => "Bravo")↔ // comments
foobarbaz↔ (v => {↔        // here
↔          myint↔         = 123
↔          myfloat↔       = 3.14
↔          mystr↔         = "abc"
↔          return "Charlie"
})

with indent awareness:

foo↔       (v => "Alfa")↔  // some
foobar↔    (v => "Bravo")↔ // comments
foobarbaz↔ (v => {↔        // here
→   myint↔   = 123
→   myfloat↔ = 3.14
→   mystr↔   = "abc"
→   return "Charlie"
})

I redesigned your examples with whitespace characters for better readability (→ indent tab, ↔ elastic tabstop):

expected:

f(x, y):
→   if x > y:
→   →   temp↔ := x
→   →   x↔    := y
→   →   y↔    := temp
→   start↔ := 1
→   end↔   := 10
→   ...

unexpected:

f(x, y):
→   if x > y:
→   →      temp↔ := x
→   →      x↔    := y
→   →      y↔    := temp
→   start↔ := 1
→   end↔   := 10
→   ...

for testing (contains actual \t characters):

f(x, y):
	if x > y:
		temp	:= x
		x	:= y
		y	:= temp
	start	:= 1
	end	:= 10
	...

counter example:

switch-cases (also see more examples, orignal argument):

switch(myvar)
{
→   case "Alfa":↔     foo(1, 2, 3);
→   ↔                 break;
→   case "Bravo":↔    foobar(123, 234, 345);
→   ↔                 break;
→   case "Charlie": ↔ foobarbaz(12345, 23456, 34567);
→   ↔                 break;
}

can be fixed with additional indent breakers:

switch(myvar)
{
→   case "Alfa":↔     foo(1, 2, 3);
→   ·↔                break;
→   case "Bravo":↔    foobar(123, 234, 345);
→   ·↔                break;
→   case "Charlie": ↔ foobarbaz(12345, 23456, 34567);
→   ·↔                break;
→   →   break;
}

[geroldmeisinger]

another counter example

multi-line statements

foo(↔ aVeryLongParameter,
↔     anotherParameterWithLongName,
↔     lastParamterWithWiiiideName)
{
	...
}

but can be fixed with different code style:

foo(
↔ aVeryLongParameter,
↔ anotherParameterWithLongName,
↔ lastParamterWithWiiiideName)
{
	...
}

or be fixed with additional indentation-breakers:

foo(↔ aVeryLongParameter,
·↔    anotherParameterWithLongName,
·↔    lastParamterWithWiiiideName)
{
	...
}

[geroldmeisinger]

Another good reason why you want to use this feature is for transitioning. While your text editor may support elastic tabstops and everything looks good, in all other tools it probably won't.

in a text viewer with no elastic tabstop support (tabsize=4)

def foo(x, y):
→   if x > y:
→   →   temp→   = x→# store temp
→   →   x→  = y→# swap
→   →   y→  = temp→# restore temp
→   start→  = 0→# set start
→   end→= 12345→# set end

Now you may be tempted to replace the elastic tabstops in the file with alignment spaces and revert them back in the viewer:

def foo(x, y):
→   if x > y:
→   →   temp··= x······# store temp
→   →   x·····= y······# swap
→   →   y·····= temp···# restore temp
→   start·····= 0······# set start
→   end·······= 12345··# set end

This only works under the following assumptions:

• there can be no multiple spaces in strings(!) or the implementation needs language aware features for quotes: print('Hello , World!')
• there were no manual alignment spaces inserted by the user (e.g. to align numbers)
• padding is larger than 2 (at least for saving in the file)

The best solution for this is to insert a tabs after alignment spaces to denote "spaces aligned elastic tabstops".

in a text viewer without elastic tabstop support (tabsize=4):

def foo(x, y):
→   if x > y:
→   →   temp··→ = x······→  # store temp
→   →   x·····→ = y······→  # swap
→   →   y·····→ = temp···→  # restore temp
→   start·····→ = 0······→  # set start
→   end·······→ = 12345··→  # set end

For the sake of the argument let's assume we actually wanted the equalsigns to line up like this. In a text viewer with no elastic tabstop support and tabsize=6 it will look like this:

def foo(x, y):
→   if x > y:
→   →   temp··→       = x······→  # store temp
→   →   x·····→       = y······→  # swap
→   →   y·····→       = temp···→  # restore temp
→   start···→ = 0······→  # set start
→   end·····→ = 12345··→  # set end

A tabsize=6 is exotic but the general problem here is that the indent tabs change the visual position of any following tabs and under certain circumstances will change the way it was aligned in the elastic tabstops situation.

One way to solve this is to use spaces for indent tabs. However this force an indentation style onto the user and this is undesired.

With "indentaware spaces aligned elastic tabstops" the users have the option:

def foo(x, y):
→   if x > y:
→   →   temp··= x·····# store temp
→   →   x·····= y·····# swap
→   →   y·····= temp··# restore temp
→   start··= 0······# set start
→   end····= 12345··# set end

For the sake of the argument lets assume we wanted the equalsigns to line up like this now.

using tabs before alignment spaces in a text viewer with no elastic tabstop support (tabsize=4):

def foo(x, y):
→   if x > y:
→   →   temp··→ = x·····→   # store temp
→   →   x·····→ = y·····→   # swap
→   →   y·····→ = temp··→   # restore temp
→   start··→= 0······→  # set start
→   end····→= 12345··→  # set end

using tabs before alignment spaces in a text viewer with no elastic tabstop support (tabsize=6):

def foo(x, y):
→     if x > y:
→     →     temp··→     = x·····→   # store temp
→     →     x·····→     = y·····→   # swap
→     →     y·····→     = temp··→   # restore temp
→     start··→    = 0······→  # set start
→     end····→    = 12345··→  # set end

Now because the elastic tabstops were aligned with the indentation level in the first place their relative position won't change.

[geroldmeisinger]

@nick-gravgaard because of all these reasons, and most notably because indent-scoped languages (like Python) and the "braces on same line code style" are so commonplace, I would even argue that this option should be the official definition of elastic tabstops by the Gravgaard Committee, because they make transition more smoothly.

[SK-Genius]

Hi @geroldmeisinger,

I found your VSCode extension "Elastic Tabstops Lite Redux" how already implements that feature and that's the reason i go back to Elastic Tabstops.

🥇

[geroldmeisinger]

yea, my first feedback. I'm happy it was useful! please also leave a rating in marketplace