Quote from: martin_frAutoIndent is done by TSynBeautifier and that has it's own settings.Another setting? Hm. Could this be documented somewhere?
The default class (none language specific beautifier) has
SynEdit.Beautifier.IndentType
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?
Why the extra setting.Right. The thing that bugs me is that the action "indent the following line up to character N" is fundamentally different from "indent the current line up to character N" (I can see why SmartIndent is different). In terms of the redesign, should that be a function of the TextBuffer "insert padding according to the current rules" that both features call to?
If you look at the optionsYou 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.
sbitConvertToTabSpace, // convert to tabs, fill with spcaces if needed sbitConvertToTabOnly // convert to tabs, even if shorter
Yet see the proposal on the mantis issue, about how to at least make it follow for none conflict cases.
Many features have been extracted (and more should be), so they can be added as needed.True, having to keep the same interface of the component means that someone will try to use them.
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.Markups are one of these new properties, right? Took me a while to figure out how to make the SpecialChars a different color, since the comment on the flag that says the're grayed out is not true anymore.
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.
So that behaviour needed to be kept. Therefore there is now a default Beautifier as a fallback.
Just adding, the implementation of the default beautifier, suggests it was meant to be avail in OI, and maybe save to lfm... Need to dig deeper...The thing is, I for one hadn't even noticed that it is even possible to assign a different Beautifier. It presents very similar to properties like Font in the OI...
And it is not global, it is one per each SynEdit.
Do you have plans to at some point cut compatibility and use the new modular system to assemble a SynEdit that doesn't have to deal with compatibility requirements? Not as a "LeanSynEdit", more like a proper rebuild of a "baseline" feature set on the new architecture.
That could be useful as a general text editor and have a "simpler" external interface that controls the individual plugin parts, even if it doesn't expose all of them.
Right. The thing that bugs me is that the action "indent the following line up to character N" is fundamentally different from "indent the current line up to character N" (I can see why SmartIndent is different).
In terms of the redesign, should that be a function of the TextBuffer "insert padding according to the current rules" that both features call to?That would not solve the issue. There still remain cases that will need spaces, when normal indent is tab only.
Markups are one of these new properties, right?Yes as well as the shared textbuffer, and the TextViews (some of them contain functionality that should not be in textviews, like the CharWidths stuff)
I for one hadn't even noticed that it is even possible to assign a different Beautifier.That is a problem....
come to think of it, maybe that is why it doesn't save correctlyNot checked 100%, but I believe it is because it is an inlined component. And SynEdit as owner does not return it, when asked by the streaming system.
First of all, "plans" is currently something that can be reaching far into the future. With all the other stuff on my list....We'll call them goals then. "Wenn man mal Zeit hat" :)
It does not need to go to the TextBuffer, see my proposal of adding more enum to the option.Interestingly, I was thinking about just that configuration and came to the opposite conclusion... to me, indentation (not align) is a property of the text itself, not the input method. Like for example Python code is always supposed to have 4 spaces, regardless of what it is written with.
It is even more complex. If 2 SynEdits share a text buffer, the 2 SynEdit can have different config. So indent would (and should) act different depending which SynEdit you type in.
For example, if the editor had a keycombo to toggle trimming spaces, then that could very well be per editor (and not per textbuffer). That way a user could temp disable it in one of the editors.That, on the other hand, clearly is part of the input method, yes.
Couldn't think of a good word for it before, now I got it: align.That makes so much more sense and is actually sort-of self-documenting!
Smart indent and beautifier are not so much indent functions. They are align functions.
That might just have been me being blind.QuoteI for one hadn't even noticed that it is even possible to assign a different Beautifier.That is a problem....
Well SynEdit is not to instruct the user (who edits the text) what to do. The user is to instruct SynEdit.It is even more complex. If 2 SynEdits share a text buffer, the 2 SynEdit can have different config. So indent would (and should) act different depending which SynEdit you type in.Interestingly, I was thinking about just that configuration and came to the opposite conclusion... to me, indentation (not align) is a property of the text itself, not the input method. Like for example Python code is always supposed to have 4 spaces, regardless of what it is written with.
see my proposal of adding more enum to the option.
I am reluctant to rename them though. It is a breaking change for no functional benefit.Couldn't think of a good word for it before, now I got it: align.That makes so much more sense and is actually sort-of self-documenting!
Smart indent and beautifier are not so much indent functions. They are align functions.
The new option you proposed would "align as if it was indented", but would still have to pad with spaces when some columns are not reachable by full tabs.Or under-align.
That might just have been me being blind.QuoteI for one hadn't even noticed that it is even possible to assign a different Beautifier.That is a problem....
The OI shows a dropdown, properties are green, just like for all other linked component properties. It's just a bit unexpected, AFAIK no other component provides its own instance, they just have default behaviour if the property is nil.
Update: actually, that's a lie. TAChart Series's Source property does the same. I also never really noticed that. :o