Improving formatting [was: [Pharo-dev] Big claps for Epicea (small request!)]
On Wed, Jul 19, 2017 at 2:16 PM, Nicolas Cellier <[hidden email]> wrote:
format before diff is in the top 5 of my most hated default.
As an author, I try to write short methods and adhere to a standard format (Kent Beck like).
But I want the freedom to use derogation when the format helps comprehension.
If I did the effort of using a special formatting, the last thing that I want is a "smart" tool that undo my work.
The best time to format code is when we accept it, and only if there is a quick way to undo/bypass if we don't like it.
The formatter is dumb. Let's illustrate it with literals among other things.
I might want to write 16rBADA55, but I'm sure i never want to read 12245589, it makes no sense ;)
(hey, this is a real example you can find in VMMaker sources, not just the production of my ill brain).
I'd love to see literal nodes in the compilers be intelligent enough to know what base a literal number was in. It might be as simple as maintaining the literal characters that make up a token and printing using those, perhaps only if the token is a member of a particular set of classes.
And remember this applies to numeric literals in Array and ByteArray literals too.
And if I make an effort to format a character encoding table on several lines to have it readable
#( line1
line2 ...
lineN ).
I'm pretty sure I never want to diff a single line with about 1024 columns...
Th above approach might also handle this case well, although I wonder about comments.
So please make this an option (with a default to false)!
Thank you VERY MUCH for Epicea. I just had a crash and it was way more comfortable to recover changes.
One small request would be to allow "Pretty Print" in the diff to the changes to be applied. Many times I changed formatting etc so for when viewing changes, viewing with same formatting helps me to see the actual changes and not formatting changes.