Hello,

Thanks for the reply.

Yes, for me this behavior happens since ever. I can open an issue, but I will not be able to pinpoint the VCS commit where this behavior was introduced...

One thing I don't understand is why reformat is needed in some refactor cases? I have never seen this behavior in any other IDE I have used. For example, why extract method should reformat the entire method? Shouldn't it replace the code extracted with the new message send? Sure, the new message sent replacing the old code might be formatted according to the default formatting configuration, but why does the refactoring process need to touch the rest of the method code? Also, the old code needs only to be pasted in the new method with some changes, does it need to be reformated?

Regards,

Vitor

On Wed, May 20, 2020 at 6:52 AM jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> wrote:

Am 20.05.20 um 10:45 schrieb Guillermo Polito:

Hi,

El 20 may 2020, a las 1:54, Ben Coman <btc@openinworld.com> escribi��:

That seems to violate the Principal Of Least Surprise.

Yes, I happen to also not like that behaviour :(

me too. Although I am not on Pharo ;-)

Whether or not it ends up getting changed, I think its��worthwhile entering that directly in the issue tracker.

It would assist if you could bisect to isolate which commit introduced the behaviour.

Opening an issue is a good start.

I also wonder, I think refactorings work like this since the beginning?

At least for the last 15 years.

But if it was introduced at some point, it should be nice to know if it can be easily reverted.

Also, refactorings DO need to rebuild the source code after refactoring, so maybe there are some cases where maintaining the old formatting is difficult?

Yeah, that's why I think it would be great if the RB engine could be extended with a(n optional) hook to call some "local/personal" formatter instead of reformatting immediately. This way we could at least make sure that the reformatting happens according to our taste and in line with whatever we use to format our code. Preserving the old formatting is likely to not be a good idea at least for some refactorings lie extract method, in addition to possibly being difficult.

The plus of such a plugin/hook approach is that this could probably be maintainable cross-platform. Every dialect could plug their formatter without changing RBs internals. I don't know if there still exists some "common code base" of RB at all, so maybe this is just stupid blah blah anyways...

Joachim

cheers -ben

On Wed, 20 May 2020 at 01:34, Vitor Medina Cruz <vitormcruz@gmail.com> wrote:

Hello,

When I run a refactoring, Rename Method, for example, the refactoring is reformatting the code affected. Is it possible to configure Pharo to refactor without reformatting code? Depending on the refactoring, the reformat is so intrusive that make it more worth to make the refactoring by hand.

Regards,

Vitor
-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:jtuchel@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1