Smart tabs in 2024

There is an old little-used #emacs package for smart tabs. All the languages it supports:

(require 'smart-tabs-mode)
(smart-tabs-insinuate 'c 'c++ 'java 'javascript 'cperl 'python 'ruby 'nxml)
(add-hook 'c-mode-common-hook #'indent-tabs-mode)
(add-hook 'java-mode-hook #'indent-tabs-mode)
(add-hook 'js2-mode-hook #'indent-tabs-mode)
(add-hook 'cperl-mode-hook #'indent-tabs-mode)
(add-hook 'python-mode-hook #'indent-tabs-mode)
(add-hook 'ruby-mode-hook #'indent-tabs-mode)
(add-hook 'nxml-mode-hook #'indent-tabs-mode)

Not much, is it? But that's ok, this way to do it has always been somewhat doomed.

Let's say you share a codebase with people on different platforms. It's not as if you can tell a VSCode person to install the above Emacs-Lisp package.

Autoformatters like gofmt do smart tabs for you these days, and when you can't mandate an autoformatter, the standard way to prevent chaos has been a "spaces only" rule. Maybe when we get an .editorconfig rule for smart tabs (issue 323), this can change?

(Once that's finalized, then Emacs is gonna need a new way more general smart-tabs-mode! Probably based on tree-sitter.)

As far as I can figure, "spaces only" must have been the pragmatic option since the dawn of computing, but maybe the innovations of tree-sitter and editorconfig finally make tabs a real option.

Someone points out that editorconfig's indent_style = tabs rule actually makes no sense if it's not smart tabs anyway, so it shouldn't exist. Makes you think who was using that rule before…

I.e. the choices are:

• Spaces only: OK
• Smart tabs: OK
• Tabs only, used as "wide spaces" assuming they will be rendered at a specific width: no