Kakoune: Support for elastic tabstops

Created on 8 Nov 2017  路  3Comments  路  Source: mawww/kakoune

Native support would be cool for elastic tabstops.
http://nickgravgaard.com/elastic-tabstops/

Most helpful comment

Unfortunately, if we restrict elastic tabstops to the interface I think they will not be very useful, as it means pressing j or k will likely jump around vertically, as we cannot respect the horizontal alignment. Imagine the following text:

function_call()<tab>// this is a comment
<   elastic tabs   >// this is the next line

Visually with elastic tab the two this words in the comments are aligned, but if you are on the second one, and hit k, you will jump somewhere in function_call. Which character you'll be on depends on what the value of tabstop actually is.

I expect such a behaviour will be enough either to make users not enable elastic tabs in Kakoune, or ask for deeper support of elastic tabs so that vertical movements take them into account.

All 3 comments

Although I really like the idea of elastic tabstops, adding support for them in Kakoune would be tricky, as it means vertical position of a character is now dependent of the surrounding lines, making vertical movement logic pretty complex.

More specifically, the problem is that we try to maintain predictability of commands, a command should give the same result if run directly by the user, or inside a hook, or another special context. In order to do that, we cannot have commands being dependent of the display, except for display specific things, such as clicking with the mouse somewhere. Supporting elastic tabstop would hence need to be integrated deep inside Kakoune's internal, which would be possible but would make lots of operations much slower as they would not be line local anymore, but would depend on surrounding lines.

In my view, although the idea is nice, elastic tabstops would be too intrusive to support for their current prevalence.

The implementation don't have to change the internals, because it only affects the interface, not the buffer content. You can even have two windows of the same buffer, one with elastic tabstops, and one without it.

More specifically, the problem is that we try to maintain predictability of commands, a command should give the same result if run directly by the user, or inside a hook, or another special context.

It should give you the same result, because an expanded tab is still one character. Going through an expanded tab with hjkl movement is one keypress alike, no matter if it is diplayed in one terminal cell or more.

Unfortunately, if we restrict elastic tabstops to the interface I think they will not be very useful, as it means pressing j or k will likely jump around vertically, as we cannot respect the horizontal alignment. Imagine the following text:

function_call()<tab>// this is a comment
<   elastic tabs   >// this is the next line

Visually with elastic tab the two this words in the comments are aligned, but if you are on the second one, and hit k, you will jump somewhere in function_call. Which character you'll be on depends on what the value of tabstop actually is.

I expect such a behaviour will be enough either to make users not enable elastic tabs in Kakoune, or ask for deeper support of elastic tabs so that vertical movements take them into account.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lenormf picture lenormf  路  3Comments

lenormf picture lenormf  路  4Comments

abitofalchemy picture abitofalchemy  路  3Comments

alexherbo2 picture alexherbo2  路  3Comments

radare picture radare  路  3Comments