[Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods?
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
You have hit my main gripe with the RB - it has no regard for formatting. I freely use it for things that do not require rewriting code (e.g. the up/down refactorings), and sometimes for new code that has not had time to accumulate useful comments. If the code has been around for a while, then I usually prefer to do the work manually than to see my configuration management queues scattered to the four corners of video RAM. I would greatly enjoy seeing this fixed, but given the attitude of the xp crowd toward comments, I am not optimistic. My experience porting lots of old code to Pharo has only strengthened my belief that well-placed comments are a very valuable aid. One package contained three logic errors that should have bitten me years ago, but never did. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of T. J. Richter Sent: Saturday, September 19, 2009 6:38 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods? Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact? _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
Automatic refactoring that preserve the formatting are extremely difficult to implement. In a common case, like with the rewrite engine that the refactoring browser is using internally, this is not really feasible. It is much easier to write your own formatter that formats as you like, even if writing a working formatter is not trivial either. For details listen to what the original authors of the Refactoring Browser say about code formatting: <http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681>. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Gwenael changed the RBParser and AST to preserve code formatting. He never understood why nobody did look at what he did. Now when marcus will be in the team I would really like to have a look so that the work on gwenael is not lost because he worked 4 months on that. But if someone is interested it would be good to check. Stef On Sep 20, 2009, at 9:16 AM, Lukas Renggli wrote:
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
Automatic refactoring that preserve the formatting are extremely difficult to implement. In a common case, like with the rewrite engine that the refactoring browser is using internally, this is not really feasible. It is much easier to write your own formatter that formats as you like, even if writing a working formatter is not trivial either.
For details listen to what the original authors of the Refactoring Browser say about code formatting: <http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681>.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gwenael changed the RBParser and AST to preserve code formatting. He never understood why nobody did look at what he did.
I looked at it. The code did not work for me at all (it broke everything), so I couldn't test it. IMHO this is not something that can be just fixed by changing the Refactoring Browser. The refactorings are implemented as "arbitrary" transformations/re-compositions of the AST. For a machine (e.g. the parser, the rewrite-engine, etc.), it is not clear if a space or a comment belongs to the AST node before or after. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Gwenael changed the RBParser and AST to preserve code formatting. He never understood why nobody did look at what he did.
I looked at it. The code did not work for me at all (it broke everything), so I couldn't test it.
I will check that with him because he had a working version.
IMHO this is not something that can be just fixed by changing the Refactoring Browser. The refactorings are implemented as "arbitrary" transformations/re-compositions of the AST. For a machine (e.g. the parser, the rewrite-engine, etc.), it is not clear if a space or a comment belongs to the AST node before or after.
Yes but gwenael managed that and he kept space and comments. So of course this may be not the complete solution but if we do not pay attention to increment then nothing will happen. So when marcus is at lille I will ask them to sit together. Stef
Lukas Renggli <renggli@...> writes:
Gwenael changed the RBParser and AST to preserve code formatting. He never understood why nobody did look at what he did.
I looked at it. The code did not work for me at all (it broke everything), so I couldn't test it.
IMHO this is not something that can be just fixed by changing the Refactoring Browser. The refactorings are implemented as "arbitrary" transformations/re-compositions of the AST. For a machine (e.g. the parser, the rewrite-engine, etc.), it is not clear if a space or a comment belongs to the AST node before or after.
Lukas
Hi Lukas. I'm sure for some of the more complicated refactoring tools, delineating whitespace between tokens is difficult or maybe even impossible, but I don't see why a renaming tool couldn't parse the source into an AST preserving whitespace tokens as they were, then simply performing search and replace on the relevant message send tokens, then outputting the the token sources.
Stef, As the self-appointed formatting pedant (you'll find I come by the title honestly<g>), I would be happy to test the work. Lukas is right that it is a tough problem, but the RB authors seem to see comments as a waste of time, so I never sensed any real desire on their part to keep formatting. It is a shame, because it greatly reduces the value of the RB to me, and probably others. As an example, I go so far as to comment out parts of cascades and replace the lines with modified code. The comments start with month-year, and have saved my skin more often than I care to count. I might have mentioned finding three bugs in a long-standing package of mine that I recently ported from Dolphin; without comments of the type I metion, I would probably still be looking for them. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Sunday, September 20, 2009 2:35 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods? Lukas Gwenael changed the RBParser and AST to preserve code formatting. He never understood why nobody did look at what he did. Now when marcus will be in the team I would really like to have a look so that the work on gwenael is not lost because he worked 4 months on that. But if someone is interested it would be good to check. Stef On Sep 20, 2009, at 9:16 AM, Lukas Renggli wrote:
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
Automatic refactoring that preserve the formatting are extremely difficult to implement. In a common case, like with the rewrite engine that the refactoring browser is using internally, this is not really feasible. It is much easier to write your own formatter that formats as you like, even if writing a working formatter is not trivial either.
For details listen to what the original authors of the Refactoring Browser say about code formatting: <http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681>.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
FIY, i have implemented the smalltalk source tokenizer, which capturing everything, including whitespace. And, of course, i got the parser which works on top of that, which means, that potentially i could write a code which replacing a single token by different one , like #foo to #bar, while preserving the white space formatting, comments & everything else. -- Best regards, Igor Stasenko AKA sig.
Igor Stasenko <siguctua@...> writes:
FIY, i have implemented the smalltalk source tokenizer, which capturing everything, including whitespace. And, of course, i got the parser which works on top of that, which means, that potentially i could write a code which replacing a single token by different one , like #foo to #bar, while preserving the white space formatting, comments & everything else.
This sounds like it would be very useful. Renaming things is one of the most common kinds of refactorings, and if it can be done automatically without users having to worry about it altering surrounding code unnecessarily, that would be wonderful. Out of curiosity, is there some kind of global, RegExp-based search and replace functionality in the system that can be used instead?
This sounds like it would be very useful. Renaming things is one of the most common kinds of refactorings, and if it can be done automatically without users having to worry about it altering surrounding code unnecessarily, that would be wonderful.
The nice thing of the Smalltalk Refactoring Engine is that it all builds uniformly on top of the rewrite engine. Unfortunately this makes it very hard to preserve the formatting.
Out of curiosity, is there some kind of global, RegExp-based search and replace functionality in the system that can be used instead?
I've built a set of code transformations on top of the refactoring engine (so that undo/redo works) that use regular expressions (and thus preserve the formatting). These tools allows you to transform category names, class names, protocol names, selector names and source code using regular expressions. The tools are implemented in OB-Regex and are directly integrated into OmniBrowser. You get the tools when you build an image from this load script for example: <http://code.google.com/p/pharo/wiki/ImageBuildScripts>. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mon, Sep 21, 2009 at 8:16 AM, Lukas Renggli <renggli@gmail.com> wrote:
The tools are implemented in OB-Regex and are directly integrated into OmniBrowser. You get the tools when you build an image from this load script for example: <http://code.google.com/p/pharo/wiki/ImageBuildScripts>.
They also are in all Pharo image for quite a long time. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
T. J. Richter wrote:
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
That's why I don't use the refactoring tools in Smalltalk. That's also why the vendors themselves don't use the refactoring tools in Smalltalk [1]. Even though they like to brag in other places how cool their refactoring tools are. And don't tell me how hard it is. Eclipse does it and their AST is more than an order of magnitude more complex. [1] http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681 Cheers Philippe
Thanks Butcher :) Stef On Sep 20, 2009, at 11:41 AM, Philippe Marschall wrote:
T. J. Richter wrote:
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
That's why I don't use the refactoring tools in Smalltalk. That's also why the vendors themselves don't use the refactoring tools in Smalltalk [1]. Even though they like to brag in other places how cool their refactoring tools are. And don't tell me how hard it is. Eclipse does it and their AST is more than an order of magnitude more complex.
[1] http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Philippe, I **never** would have figured you as being on the pro-comment side of this topic. No offense intended, it just surprises me :) I will stop short of commenting on the complexity of the problem; I just keep hoping that it will get fixed, and will happily test anything Stef, Gwenael, et al. think is a working version. Being able to freely use the RB when rewrites are required would be a great benefit to me. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Philippe Marschall Sent: Sunday, September 20, 2009 4:41 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods? T. J. Richter wrote:
Hi, I am using Pharo with the default browser, which is the OmniBrowser. When I right-click on a message name in the right-most panel and choose "rename refactor" from the menu, enter the new name and accept, the message sends are renamed, but the whitespace formatting in those refactored methods is not preserved. Is there any way at present to do this while keeping the formatting intact?
That's why I don't use the refactoring tools in Smalltalk. That's also why the vendors themselves don't use the refactoring tools in Smalltalk [1]. Even though they like to brag in other places how cool their refactoring tools are. And don't tell me how hard it is. Eclipse does it and their AST is more than an order of magnitude more complex. [1] http://www.cincomsmalltalk.com/blog/blogView?entry=3426663681 Cheers Philippe _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Damien Cassou -
Igor Stasenko -
Lukas Renggli -
Philippe Marschall -
Schwab,Wilhelm K -
Stéphane Ducasse -
T. J. Richter -
T.J. Richter