kakoune: EditorConfig does not expandtab

@mawww, it was mentioned several times in this thread, and I’ve also thought about the fact that there are some languages¹ which directly expect spaces to be used for indenation, either because of language parser implementation, or because language standard strongly suggests it. Isn’t this good enough reason to include smarttab.kak to the core and handle <kbd>Tab</kbd> and <kbd>></kbd> keys through it for better programming experience? This issue has popped up several times, and majority of users expect this thing to be builtin. (Again, it is presented in 99% of editors).

Smarttab.kak has barely changed since I’ve wrote it, and had served me well, as well as other users. I’m fine with it being a plugin, but I still think that this is a first-class feature of any code editor. I know that one of the reasons not to ship it is this, but I think we have better ways to teach users write hooks.

^{1: Such languages would be all Lisps, Python, Rust.}

Here’s how I configured indentation:

define-command auto-setup-indent %{
	# … other ways of inferring indentwidth …
	editorconfig-load
	modeline-parse
	evaluate-commands %sh{
		if [ $kak_opt_indentwidth -eq 0 ]; then
			printf "smarttab\n" # from smarttab plugin
		else
			printf "expandtab\n" # also from there
		fi;
	}
}
hook global BufOpenFile .* auto-setup-indent
hook global BufNewFile .* auto-setup-indent

(full version also configures smarttab’s softtabstop)

It’s honestly silly that the scripts shipped out of the box don’t include all of smarttab and parts of something like this. Making the tab key “magic” should be done in a couple lines of config, not a whole screen of config.

What you are asking for is for <tab> in insert mode to be treated as an indentation command, which is relatively common among editors, especially non-modal ones, but is not strictly what editorconfig is supposed to be doing.

<tab> as an indentation command is far more useful by default than <tab> as a means of inserting literal tab characters. If that is what you want, just escape with ^V. The cases where this doesn’t save keystrokes are massively outweighed by those where it does. Unless actually indenting with tab characters, which is not kak’s default, almost everybody using kak’s defaults would hardly ever use the tab key in insert mode. That is bad use of keyboard real estate.

Though I realise this is a separate issue, which I’ve made here: #3136.

Thanks for your perspective @mawww. It sounds like you have given it quite a bit of thought.

To me, indent_style defines the indentation style, not the <tab> key behaviour

To me, indent_style and <tab> are very much related. When you indent code, you do so most often using the <tab> key. I think it’s unintuitive for kakoune to respect indent_style for many indent commands (<, >, etc.), except the most popular one: <tab>.

I think the majority of new users would expect the behaviour I describe, since that is how most other programs implement it, and it is a reasonable interpretation of the .editorconfig documentation.

Additionally, indenting with spaces is extremely popular and having to download a plugin to achieve the functionality they are familiar with could be frustrating to new users. I think it would be great to have as a default setting. I may be wrong though and am open to having my mind changed.

When you indent code, you do so most often using the <tab> key.

In most editors, sure.

The description of the Kakoune repo is “mawww’s experiment for a better code editor”, and part of that experiment is seeing how far it can get with super-minimalist internals and a lot of scripting on top. For example, one example of that minimalism is “in insert mode, keys are inserted into the buffer, but in normal mode they operate on the selection”. This is a bit fuzzy, since pressing <kbd>Esc</kbd> in insert mode does not insert a 0x1B byte into the buffer, but it’s true for regular typable characters like <kbd>A</kbd> and <kbd>}</kbd> and <kbd>Space</kbd> and <kbd>Tab</kbd>. Those are all characters one might reasonably expect to find in a source-code file, and in insert mode, they all insert themselves as-is.

That said, brutal minimalism is uncomfortable for actual humans, and Kakoune ships with a a bunch of scripts to make things more comfortable. For example, many of Kakoune’s file-type-support scripts, as well as adding syntax highlighting, teach <kbd>Enter</kbd> to copy the indent from the previous line as well as inserting a new one. There’s definitely drawbacks to that strategy (not every file-type supports it, and some of them are inconsistent), but there’s also advantages (file-formats or users with unusual requirements can be special without having to modify Kakoune’s core).

If Kakoune were all about making the most polished, easy-to-use editor, then sure, making a magic <kbd>Tab</kbd> key would absolutely be the right move. But instead, Kakoune is trying to balance comfort against simplicity and minimalism.

One thing that has changed since these conventions were established is that Kakoune now has a module system so scripts can depend on one another. I wonder if it would be reasonable to ship some tab-magic.kak in the standard library with helper commands like setup-window-expandtabs, and update all the file-type plugins to use it. That way, users can still write their own hooks if they need something really custom, or use the helper commands if they want something generic.

@mawww From https://editorconfig.org:

indent_style: set to tab or space to use hard tabs or soft tabs respectively.

My understanding is that soft vs hard tabs denotes what is inserted when the <tab> key is pressed, with soft tabs inserting spaces according to indent_size. I believe this is how it works in other programs. More info https://stackoverflow.com/a/26350798/9518712

I am currently using smarttab (great plugin!) to get the behaviour I want, but shouldn’t editors that support .editorconfig have expandtab built in? Or is that not in the .editorconfig spec?