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