Hi,
> On Aug 7, 2016, at 5:48 PM, Ben Coman <b...@openinworld.com> wrote: > > On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba <tu...@tudorgirba.com> 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 <steph...@free.fr> 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."
