when Cmd-P can just display a string in the debugger
Locked
 
|
Hi
Seriously I do not get why printing in the debugger cannot just print the text without putting these ^%&*^*&()**(&%^*( double quote around. Why do we change such basic functionality and in particular we do not propose ANY alternative. If you need a pop up and do not care of manipulating text this is ok but WHY the default behavior has to be changed. I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& flow is not mine. Should I go and hack to get back the default behavior. WHY do I have to do that? Seriously. Especially since the solution was super simple: introduce a new binding living nicely close to PrintIt but no "we have to change the default one with something that may fuck your flow but who cares because my flow is better." Why do we get systematically this message? Why such changes are damaging TDD practices without any notices? May be I should use another Smalltalk at the end. Stef |
|
|
On Sun, Aug 7, 2016 at 3:39 PM, stepharo <[hidden email]> wrote:
> Hi > > Seriously I do not get why printing in the debugger cannot just print the > text without putting these ^%&*^*&()**(&%^*( double quote around. I believe the behaviour was introduced for the Workspace/Playground so that inserting the result into the text wouldn't screw up the syntax highlighting or running it again. Perhaps this behaviour was copied/inherited by the Debugger without considering it might be a different use case. ?? cheers -ben > > Why do we change such basic functionality and in particular we do not > propose ANY alternative. > > If you need a pop up and do not care of manipulating text this is ok but WHY > the default behavior has to be changed. > > I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& > flow is not mine. > > Should I go and hack to get back the default behavior. WHY do I have to do > that? > > Seriously. > > Especially since the solution was super simple: introduce a new binding > living nicely close to PrintIt > > but no "we have to change the default one with something that may fuck your > flow but who cares because my flow is better." > > Why do we get systematically this message? Why such changes are damaging TDD > practices without any notices? > > May be I should use another Smalltalk at the end. > > Stef > > |
Re: when Cmd-P can just display a string in the debugger
|
|
In reply to this post by stepharo
Hi Stef,
We had a thread on that two months ago, and it is still waiting for your answer. I made concrete proposals on which bindings can work. It would be more constructive to focus on those details (see more below). First, one thing should get clarified. The case in which someone wants to print and persist inline the result is an edge case. For example, it happens when you want to write tests to document how the code is working currently. The typical case for using print-it is to get a sneak peak of what the object is and in this case, the requirement is specifically to not change the current code (especially when you are debugging you do not want to get the code dirty). That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. But, to come back to the concrete solution, as I mentioned before, I do agree that what you mention should be a supported use case. The only question is how to do it. So, let’s focus on that please. One solution would be to have a different first level keybinding directly in the text editor, but that would not be a good idea because that space is already overloaded with too many key bindings, and this becomes a problem especially when you place an editor inside a larger tool (like a debugger) and you run out of available key bindings for other actions. So, the proposals I had was like this: Cmd+p ==> the print-it popup - Enter ==> add as a comment - Shift+Enter ==> add as plain text - Cmd+v ==> add as plain text (this would not affect the text that was copied to clipboard) Another option would be to change the meaning of the current Enter: Cmd+p ==> the print-it popup - Enter ==> add as a plain text - Shift+Enter ==> add as comment What do you think? Cheers, Doru > On Aug 7, 2016, at 9:39 AM, stepharo <[hidden email]> wrote: > > Hi > > Seriously I do not get why printing in the debugger cannot just print the text without putting these ^%&*^*&()**(&%^*( double quote around. > > Why do we change such basic functionality and in particular we do not propose ANY alternative. > > If you need a pop up and do not care of manipulating text this is ok but WHY the default behavior has to be changed. > > I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& flow is not mine. > > Should I go and hack to get back the default behavior. WHY do I have to do that? > > Seriously. > > Especially since the solution was super simple: introduce a new binding living nicely close to PrintIt > > but no "we have to change the default one with something that may fuck your flow but who cares because > > my flow is better." > > Why do we get systematically this message? Why such changes are damaging TDD practices without any notices? > > May be I should use another Smalltalk at the end. > > Stef > > -- www.tudorgirba.com www.feenk.com "Presenting is storytelling." |
Re: when Cmd-P can just display a string in the debugger
|
|
On 8/7/16 6:16 AM, Tudor Girba wrote: > Hi Stef, > > > That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. > I believe that this is a logical fallacy ... many developers are too busy actually trying to do work with these tools and don't have time or inclination to get involved in an argument :) There are a number of odd, awkward, hidden, "old way does not work anymore" things that I am running into as I have just been using Pharo5.0 for a couple of months ... I understand that when the GUI changes one must give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... I don't like the funky popup prints either --- they often obscure the underlying text and when I do something to see the underlying text I lose the printout --- occasionally it is useful as a preview but that's not the only use case .. often the result is what I want ... But I am trying to do real work and I really don't have the time to get into an embroiled argument over things so far I feel less productive (the debugger buttons are a real annoyance) but perhaps with practice and patience I will eventually see the light of putting heavily used menu items off in a corner ... BTW, I've basically given up on using browser shortcuts altogether ... I am assuming that the shortcuts will be changing yet again in 6.0 so I'm not going to try to memorize shortcuts that will be changing every 6 months :) While I am complaining --- is there a way to be able to change the width of the inspector panes in a debugger? I'm almost never able to see what I want to see in the inspector panes because they aren't wide enough and unlike every other pane in the universe, I can't grab the pane and change its width ... I'm sure you have a good argument for why it can't be moved --- but that doesn't stop me from being annoyed ... Optimized code is often uglier than the cleanly crafted beautiful code that runs too damn slow ... I could go on and on, but I'm sure you've good reasons for all of the the things that you have changed and this isn't the only GUI in the world that is annoying to use :) Remember that I am still in the phase of "give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... " Dale |
Re: when Cmd-P can just display a string in the debugger
|
|
Hi Dale,
Thanks for your thoughts. And thanks for giving these new quirks time to settle :). Actually, I am looking for what is annoying and I specifically interested in the reasons why it is annoying. Please feel free to report the bits that annoy you. Cheers, Doru > On Aug 7, 2016, at 3:57 PM, Dale Henrichs <[hidden email]> wrote: > > > > On 8/7/16 6:16 AM, Tudor Girba wrote: >> Hi Stef, >> >> >> That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. >> > I believe that this is a logical fallacy ... many developers are too busy actually trying to do work with these tools and don't have time or inclination to get involved in an argument :) > > There are a number of odd, awkward, hidden, "old way does not work anymore" things that I am running into as I have just been using Pharo5.0 for a couple of months ... I understand that when the GUI changes one must give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... > > I don't like the funky popup prints either --- they often obscure the underlying text and when I do something to see the underlying text I lose the printout --- occasionally it is useful as a preview but that's not the only use case .. often the result is what I want ... > > But I am trying to do real work and I really don't have the time to get into an embroiled argument over things so far I feel less productive (the debugger buttons are a real annoyance) but perhaps with practice and patience I will eventually see the light of putting heavily used menu items off in a corner ... > > BTW, I've basically given up on using browser shortcuts altogether ... I am assuming that the shortcuts will be changing yet again in 6.0 so I'm not going to try to memorize shortcuts that will be changing every 6 months :) > > While I am complaining --- is there a way to be able to change the width of the inspector panes in a debugger? I'm almost never able to see what I want to see in the inspector panes because they aren't wide enough and unlike every other pane in the universe, I can't grab the pane and change its width ... I'm sure you have a good argument for why it can't be moved --- but that doesn't stop me from being annoyed ... > > Optimized code is often uglier than the cleanly crafted beautiful code that runs too damn slow ... > > I could go on and on, but I'm sure you've good reasons for all of the the things that you have changed and this isn't the only GUI in the world that is annoying to use :) > > Remember that I am still in the phase of "give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... " > > Dale > > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice." |
Re: when Cmd-P can just display a string in the debugger
|
|
2016-08-07 16:10 GMT+02:00 Tudor Girba <[hidden email]>: Hi Dale, +1 Pharo is not an environment where we should live with annoyance. I would encourage people to report anything that disturbs the daily work and discuss what behavior or gui layout is expected and what could be done better. I am sure we can not find a way to satisfy all, we have different workflows and different expectations, but it is better to talk about, instead of just live with it.
|
|
|
In reply to this post by Tudor Girba-2
Often the reason of annoyance is either time consuming or simply complicated to detail.
Anyway, personally, I am not really perturbed by the button location. The print-it in the debugger is no more an annoyance when the Cmd-c bidding can simply copy the print-it. It is exactly what I wish to do most of the time. What seriously bother me, is the instability of Athens, which cannot be fixed. And the highly-suboptimal Git integration. These are what may make me move away from Pharo. Alexandre > On Aug 7, 2016, at 10:10 AM, Tudor Girba <[hidden email]> wrote: > > Hi Dale, > > Thanks for your thoughts. And thanks for giving these new quirks time to settle :). > > Actually, I am looking for what is annoying and I specifically interested in the reasons why it is annoying. Please feel free to report the bits that annoy you. > > Cheers, > Doru > > > >> On Aug 7, 2016, at 3:57 PM, Dale Henrichs <[hidden email]> wrote: >> >> >> >> On 8/7/16 6:16 AM, Tudor Girba wrote: >>> Hi Stef, >>> >>> >>> That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. >>> >> I believe that this is a logical fallacy ... many developers are too busy actually trying to do work with these tools and don't have time or inclination to get involved in an argument :) >> >> There are a number of odd, awkward, hidden, "old way does not work anymore" things that I am running into as I have just been using Pharo5.0 for a couple of months ... I understand that when the GUI changes one must give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... >> >> I don't like the funky popup prints either --- they often obscure the underlying text and when I do something to see the underlying text I lose the printout --- occasionally it is useful as a preview but that's not the only use case .. often the result is what I want ... >> >> But I am trying to do real work and I really don't have the time to get into an embroiled argument over things so far I feel less productive (the debugger buttons are a real annoyance) but perhaps with practice and patience I will eventually see the light of putting heavily used menu items off in a corner ... >> >> BTW, I've basically given up on using browser shortcuts altogether ... I am assuming that the shortcuts will be changing yet again in 6.0 so I'm not going to try to memorize shortcuts that will be changing every 6 months :) >> >> While I am complaining --- is there a way to be able to change the width of the inspector panes in a debugger? I'm almost never able to see what I want to see in the inspector panes because they aren't wide enough and unlike every other pane in the universe, I can't grab the pane and change its width ... I'm sure you have a good argument for why it can't be moved --- but that doesn't stop me from being annoyed ... >> >> Optimized code is often uglier than the cleanly crafted beautiful code that runs too damn slow ... >> >> I could go on and on, but I'm sure you've good reasons for all of the the things that you have changed and this isn't the only GUI in the world that is annoying to use :) >> >> Remember that I am still in the phase of "give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... " >> >> Dale >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Being happy is a matter of choice." > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Tudor Girba-2
On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba <[hidden email]> wrote:
> Hi Stef, > > We had a thread on that two months ago, and it is still waiting for your answer. I made concrete proposals on which bindings can work. It would be more constructive to focus on those details (see more below). > > First, one thing should get clarified. The case in which someone wants to print and persist inline the result is an edge case. For example, it happens when you want to write tests to document how the code is working currently. The typical case for using print-it is to get a sneak peak of what the object is and in this case, the requirement is specifically to not change the current code (especially when you are debugging you do not want to get the code dirty). > > That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. > > But, to come back to the concrete solution, as I mentioned before, I do agree that what you mention should be a supported use case. The only question is how to do it. So, let’s focus on that please. > > One solution would be to have a different first level keybinding directly in the text editor, but that would not be a good idea because that space is already overloaded with too many key bindings, and this becomes a problem especially when you place an editor inside a larger tool (like a debugger) and you run out of available key bindings for other actions. > > So, the proposals I had was like this: > > Cmd+p ==> the print-it popup > - Enter ==> add as a comment > - Shift+Enter ==> add as plain text > - Cmd+v ==> add as plain text (this would not affect the text that was copied to clipboard) > > Another option would be to change the meaning of the current Enter: > > Cmd+p ==> the print-it popup > - Enter ==> add as a plain text > - Shift+Enter ==> add as comment Doing a CMD key then SHIFT key is a bit of a contortion. What about... Cmd+p ==> the print-it popup, then... - Cmd+p ==> add as a plain text (fingers don't have to move, most efficient for old behaviour) - Enter ==> add as comment (existing behaviour) cheers -ben > > > What do you think? > > Cheers, > Doru > > >> On Aug 7, 2016, at 9:39 AM, stepharo <[hidden email]> wrote: >> >> Hi >> >> Seriously I do not get why printing in the debugger cannot just print the text without putting these ^%&*^*&()**(&%^*( double quote around. >> >> Why do we change such basic functionality and in particular we do not propose ANY alternative. >> >> If you need a pop up and do not care of manipulating text this is ok but WHY the default behavior has to be changed. >> >> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& flow is not mine. >> >> Should I go and hack to get back the default behavior. WHY do I have to do that? >> >> Seriously. >> >> Especially since the solution was super simple: introduce a new binding living nicely close to PrintIt >> >> but no "we have to change the default one with something that may fuck your flow but who cares because >> >> my flow is better." >> >> Why do we get systematically this message? Why such changes are damaging TDD practices without any notices? >> >> May be I should use another Smalltalk at the end. >> >> Stef >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling." > > |
Re: when Cmd-P can just display a string in the debugger
|
|
Hi,
> On Aug 7, 2016, at 5:48 PM, Ben Coman <[hidden email]> wrote: > > On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba <[hidden email]> wrote: >> Hi Stef, >> >> We had a thread on that two months ago, and it is still waiting for your answer. I made concrete proposals on which bindings can work. It would be more constructive to focus on those details (see more below). >> >> First, one thing should get clarified. The case in which someone wants to print and persist inline the result is an edge case. For example, it happens when you want to write tests to document how the code is working currently. The typical case for using print-it is to get a sneak peak of what the object is and in this case, the requirement is specifically to not change the current code (especially when you are debugging you do not want to get the code dirty). >> >> That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. >> >> But, to come back to the concrete solution, as I mentioned before, I do agree that what you mention should be a supported use case. The only question is how to do it. So, let’s focus on that please. >> >> One solution would be to have a different first level keybinding directly in the text editor, but that would not be a good idea because that space is already overloaded with too many key bindings, and this becomes a problem especially when you place an editor inside a larger tool (like a debugger) and you run out of available key bindings for other actions. >> >> So, the proposals I had was like this: >> >> Cmd+p ==> the print-it popup >> - Enter ==> add as a comment >> - Shift+Enter ==> add as plain text >> - Cmd+v ==> add as plain text (this would not affect the text that was copied to clipboard) >> >> Another option would be to change the meaning of the current Enter: >> >> Cmd+p ==> the print-it popup >> - Enter ==> add as a plain text >> - Shift+Enter ==> add as comment > > Doing a CMD key then SHIFT key is a bit of a contortion. > What about... > Cmd+p ==> the print-it popup, then... > - Cmd+p ==> add as a plain text (fingers don't have to move, most > efficient for old behaviour) > - Enter ==> add as comment (existing behaviour) I am fine with that. And I think we can still anyway add Cmd+v to “paste” in place the plain text. Does anyone see a problem with this solution? Cheers, Doru > cheers -ben > >> >> >> What do you think? >> >> Cheers, >> Doru >> >> >>> On Aug 7, 2016, at 9:39 AM, stepharo <[hidden email]> wrote: >>> >>> Hi >>> >>> Seriously I do not get why printing in the debugger cannot just print the text without putting these ^%&*^*&()**(&%^*( double quote around. >>> >>> Why do we change such basic functionality and in particular we do not propose ANY alternative. >>> >>> If you need a pop up and do not care of manipulating text this is ok but WHY the default behavior has to be changed. >>> >>> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& flow is not mine. >>> >>> Should I go and hack to get back the default behavior. WHY do I have to do that? >>> >>> Seriously. >>> >>> Especially since the solution was super simple: introduce a new binding living nicely close to PrintIt >>> >>> but no "we have to change the default one with something that may fuck your flow but who cares because >>> >>> my flow is better." >>> >>> Why do we get systematically this message? Why such changes are damaging TDD practices without any notices? >>> >>> May be I should use another Smalltalk at the end. >>> >>> Stef >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Presenting is storytelling." -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach." |
Re: when Cmd-P can just display a string in the debugger
|
|
In reply to this post by Nicolai Hess-3-2
Nicolai, It is good to encourage this, but it is a reality that it is a lot of work to do a good job of complaining and criticizing and personally I have a talk at ESUG that needs work, so I won't have the luxury of detailed criticisms much longer :) and I'm sure that this is an issue for others as well ... But if all of us make a point to "complain" when we hit an annoying issue AND have the time to complain, then eventually you guys will get the kind of feedback that you need to make better decisions, compromises and preferences... Dale On 8/7/16 7:33 AM, Nicolai Hess wrote:
|
Re: when Cmd-P can just display a string in the debugger
|
|
Hi, I think that whatever default behavior and shortcuts you decide, it would be nice to be able to configure it. So, if someone does not feel comfortable with the default, he has a simple way to change it and configure in a way that gets better along with his way of using Pharo. Don't you think? On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs <[hidden email]> wrote:
|
Re: when Cmd-P can just display a string in the debugger
|
|
+1 On 8/8/16 2:31 AM, Nicolas Passerini
wrote:
|
|
|
In reply to this post by Nicolas Passerini
+1
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |