Smalltalk › Pharo › Pharo Smalltalk Developers

Re: Improving formatting [was: Big claps for Epicea (small request!)]

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Denis Kudriashov

Re: Improving formatting [was: Big claps for Epicea (small request!)]

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 <[hidden email]>:

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)!

2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <[hidden email]>:
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

Tim Mackinnon

Re: Improving formatting [was: Big claps for Epicea (small request!)]

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 <[hidden email]> wrote:

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)!

2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <[hidden email]>:
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

Nicolas Cellier

Re: Improving formatting [was: Big claps for Epicea (small request!)]

In reply to this post by Denis Kudriashov

2017-07-20 10:02 GMT+02:00 Denis Kudriashov <[hidden email]>:

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 <[hidden email]>:

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)!

2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck <[hidden email]>:
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

Stephane Ducasse-3

Re: Improving formatting [was: Big claps for Epicea (small request!)]

> 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.