Improving formatting [was: Big claps for Epicea (small request!)]
On Wed, Jul 19, 2017 at 2:16 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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)!
2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi Martin,
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.
Thanks!
-- Mariano http://marianopeck.wordpress.com
-- _,,,^..^,,,_ best, Eliot
Hi Nicolas
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 ;)
I wonder where you see this problem? Formatting method in Nautilus works fine. Try checkbox "format as you read" or menu command "Format". 2017-07-19 23:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Wed, Jul 19, 2017 at 2:16 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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)!
2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi Martin,
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.
Thanks!
-- Mariano http://marianopeck.wordpress.com
-- _,,,^..^,,,_ best, Eliot
2017-07-20 10:02 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi Nicolas
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 ;)
I wonder where you see this problem? Formatting method in Nautilus works fine. Try checkbox "format as you read" or menu command "Format".
Hi Denis, you're right, for literal numbers it's been solved in Pharo at least since 3.0, or maybe even 2.0 (by usage of RB AST I guess). That's a major improvment over Squeak which is is certainly where I last encountered the problem. Still, formatting does mess line breaking/indenting/commenting in literal arrays.
2017-07-19 23:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Wed, Jul 19, 2017 at 2:16 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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)!
2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com> :
Hi Martin,
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.
Thanks!
-- Mariano http://marianopeck.wordpress.com
-- _,,,^..^,,,_ best, Eliot
Hi Denis, you're right, for literal numbers it's been solved in Pharo at least since 3.0, or maybe even 2.0 (by usage of RB AST I guess). That's a major improvment over Squeak which is is certainly where I last encountered the problem.
Still, formatting does mess line breaking/indenting/commenting in literal arrays.
Yes I would love to have a better heuristics. Now we refactored the prettyprinter so it should be easier to play and enhance it.
In its day, I recall that OTI Smalltalk was changed mid way in its life to preserve some original formatting as much as possible (and there were also tons of customisations to tune it well) - I recall much of the discussion was around vertical whitespace preservation. At the time, I remember we configured it so that the results were pretty good and I had no issues with pressing reformat very frequently. It is true that Pharo needs more work in this area as it would be nice to have a beautiful formatter. We need some folks to pile in. Tim
On 19 Jul 2017, at 22:23, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Jul 19, 2017 at 2:16 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> 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)!
2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>: Hi Martin,
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.
Thanks!
-- Mariano http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
-- _,,,^..^,,,_ best, Eliot
participants (5)
-
Denis Kudriashov -
Eliot Miranda -
Nicolas Cellier -
Stephane Ducasse -
Tim Mackinnon