From
https://bugs.freepascal.org/view.php?id=38843AutoIndent is done by TSynBeautifier and that has it's own settings.
The default class (none language specific beautifier) has
SynEdit.Beautifier.IndentType
Another setting? Hm. Could this be documented somewhere?
Default Beautifier properties set in Object Inspector are not saved to LFM so this has to be set in code, is that intentional?
On a more general note, that means that, so far:
- block indent of selections uses BlockIndent/BlockTabIndent
- smart indent from [Tab] at line start uses CreateTabsAndSpaces(TabWidth)
- autoindent uses the Beautifier
All of these have completely different rules and depending on which one you happen to hit, the resulting text looks completely different. Is it really supposed to be that messy?
The short bits....
1) AutoIndent can require handling of situations (conflict/see below) that BlockIndent never has to deal with. So it needs additional settings.
2) There are a lot of ways those feature can be set. Many of them came from user-requests (or from the original SynEdit). That leads to a lot of settings, unfortunately...
3) Grouping of settings / finding them all over the place => see "modularity" below.
(Also note, that some of those settings will also be influenced by "trimming trailing spaces", which are on a module of their own.
So between all of that, it's not trivial to find one good way to have all the settings accessible.
(For the OI, a special property editor with a wizard style configurator might be an idea / but who would write that?)
Why the extra setting.If you look at the options
sbitConvertToTabSpace, // convert to tabs, fill with spcaces if needed
sbitConvertToTabOnly // convert to tabs, even if shorter
You will see that the Beautifier can not follow the "BlockIndent" settings, because they do not contain info how to resolve conflicts. So additional settings are needed.
Yet see the proposal on the mantis issue, about how to at least make it follow for none conflict cases.
Given that new setting, it would be nice, if this was not crammed into a single property.
But if that is to be changed, special care needs to be taken, so the old property can still be read (IIRC possible with "DefineProperty")
Why the "invisible" default BeautifierDue to historical reasons SynEdit has a lot of add-ons pre-added. (I.e. SynEdit used to be a big block of "all or nothing" code.).
The overall goal is to make it more modular.
Many features have been extracted (and more should be), so they can be added as needed.
The problem is, they can not simply be removed from the drag-and-drop SynEdit, because any project having a SynEdit on a form would loose all the features.
So instead a new lean SynEdit that does not have them pre-added needs to be created.
However creating that now, also recreates the above problem, if it is used and more features become add-ons... (And I don't want to end with half a dozen different LeanSynEdit.)
Off topic, this is also why I try to publish as few properties as possible. Once in OI, and lfm files, it becomes hell to change them.
If they are in code only, they get deprecated with a note how to replace them.
Code is checked when you compile, users will get a note or error. LFM are not check, they crash and maybe only sometimes.
The beautifier is one of the things SynEdit should only have, if added by a user. (And then the user would configure it).
But the problem is as told, existing projects expect it (or it's behaviour) to be present.
So that behaviour needed to be kept. Therefore there is now a default Beautifier as a fallback.
IIRC its a global object shared by all edits (needs to be checked).
The default can not work in the OI (It would take quite some dirty workarounds....)., and it shouldn't even be shown (Not sure why it does, or since when / I almost overlooked that part of your comment completely).
So the idea is to add your own, if you want to configure it.
Hope I did not miss anything else.