#2256 use.tabs=1 interferes with tab.indents=1 in nontrivial ways

[Shviller]

Tested in Scite 5.0.2 on Windows 10, and also Scite 3.7.2 for GTK+ 3.22.5 on Debian 9.

use.tabs=1
tab.indents=1

interact strangely: once you try to indent by hitting tab on a line that has enough leading spaces, each group of tabsize spaces will be replaced by a tab character. This is easiest to see by setting tabsize and indent.size to the same size, as it would cause tab.indents=1 to seemingly have no effect at all, because the spaces Tab inserts when indenting are instantly converted to a tab. Somewhat funnily, setting indent.size to, say, twice the tabsize, would cause a single press of the Tab key at the beginning of a line to insert two tab characters - because enough spaces are inserted to get converted to two tabs.

If this automatic conversion of spaces to tabs even with tab.indents being on is the intended behavior, then I would love a setting to turn it off while retaining the ability to type tab characters outside the indentation whitespace.

[Shviller]

The spaces to tabs conversion also occurs when you press Enter. The previous line's whitespace gets copied and then the new line's whitespace gets converted.

[Neil Hodgson]

This is deliberate:

use.tabs determines whether the indentation is made up purely from space characters or from a mix of tabs and spaces using as many tabs as possible

The goal here is for indentation to be consistent: tabs followed by less than tabsize spaces. That ensures that indentation-sensitive tools like Python are likely to see the text in the same way as it is presented.

The implementation doesn't make it easy to add the option described but a good implementation could go in.