The importance of this tool as integral to the development experience in Onyx has been there since the inception.
About time it's issued.
The purpose of the stylizer is just the same as astyle, etc., for C++, (and the formatter for Crystal - but it has no configurability, only a "one world order" style) - namely: formatting the source code according to preferences.
The idiomatic way of working with an Onyx project is intended to be as follows:
Define a style-conf that is the repo's official and public style. Anyone PR'ing / merging to the project reformat the source to that, also needs to be done when diffing, if one uses an alternative private style.
Every individual coder, when checking out and working on source, can have their own style-conf as to view it the way that makes them the most productive and enjoy working the most.
The styling chosen is always based on rules, thus no esoteric formatting can ever be "kept" through the styling process. It must be completely symmetric and deterministic.
So, what should be configurable for starters?
Obviously - language syntax variations
(x, y) ~> stuff x, y vs \x, y\ stuff x, y
and, or, isnt vs &&, ||, !=, etc. (wordy vs symbolic operators)
rules could depend on if literals or vars in construct, for instance:
some-foo is 5, but, some-foo == other-thing
Whitespace
Perhaps one wants a newline before every function definition
Or only if preceding isn't a one liner function
Perhaps one wants two newlines after each type definition
Perhaps one wants spaces on the insides of literal arrays, hashes, tuples
Line-breaking
For expressions longer than n columns, where, and how to break.
Adjustments
"Columnize" certain parts of statements in certain contexts to make it visually clearer
Could be cases in a switch, ivar definitions, list-like / map-like literals, etc.
Elastic tabs doesn't have wide support, it could however be very nice for those who don't want to use monofonts to support. But. There's no codepoint specifically for this, nor a de facto agreement (like using vtab, or using a space+tab marker, etc.). So this is of no priority.
More?
This tool is important. Also for the development of Onyx itself (see #4). It makes it possible to quickly compare different variations of Onyx (even generate randomized conf and style with, for kicks and examination), and thus makes it simpler to see what's wrong / should be ditched / changed in the syntax and settle the language faster.
I therefore think this is a highly urgent part of the developement process of Onyx.
The importance of this tool as integral to the development experience in Onyx has been there since the inception.
About time it's issued.
The purpose of the stylizer is just the same as
astyle, etc., for C++, (and the formatter for Crystal - but it has no configurability, only a "one world order" style) - namely: formatting the source code according to preferences.The idiomatic way of working with an Onyx project is intended to be as follows:
The styling chosen is always based on rules, thus no esoteric formatting can ever be "kept" through the styling process. It must be completely symmetric and deterministic.
So, what should be configurable for starters?
(x, y) ~> stuff x, yvs\x, y\ stuff x, yand,or,isntvs&&,||,!=, etc. (wordy vs symbolic operators)some-foo is 5, but,some-foo == other-thingThis tool is important. Also for the development of Onyx itself (see #4). It makes it possible to quickly compare different variations of Onyx (even generate randomized conf and style with, for kicks and examination), and thus makes it simpler to see what's wrong / should be ditched / changed in the syntax and settle the language faster.
I therefore think this is a highly urgent part of the developement process of Onyx.