CMD/CTRL-B for browsing?
Hi Guys, In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose? #Luc
On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys,
In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose?
No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere. Marcus
ok. #Luc 2016-03-01 18:10 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys,
In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose?
No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere.
Marcus
On 01 Mar 2016, at 18:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys,
In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose?
No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere.
I added an issue: https://pharo.fogbugz.com/f/cases/17731/Rubric-When-not-in-Code-Mode-the-edi... (Issue tracker status: - Open overall: 512 - Open tagged Pharo5: 319 - Closed last 7 days: 100 )
Hi, Could you describe in more details the specific case we have here? Cheers, Doru
On Mar 2, 2016, at 11:28 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys,
In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose?
No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere.
I added an issue:
https://pharo.fogbugz.com/f/cases/17731/Rubric-When-not-in-Code-Mode-the-edi...
(Issue tracker status: - Open overall: 512 - Open tagged Pharo5: 319 - Closed last 7 days: 100 )
-- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."
On 02 Mar 2016, at 13:28, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Could you describe in more details the specific case we have here?
inspect #(hello you) then click on the first item. Now I select the 'hello' on the right and try to do "senders of" --> replace by "n".
Cheers, Doru
On Mar 2, 2016, at 11:28 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys,
In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose?
No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere.
I added an issue:
https://pharo.fogbugz.com/f/cases/17731/Rubric-When-not-in-Code-Mode-the-edi...
(Issue tracker status: - Open overall: 512 - Open tagged Pharo5: 319 - Closed last 7 days: 100 )
-- www.tudorgirba.com www.feenk.com
"Next time you see your life passing by, say 'hi' and get to know her."
Hi, Hmm. I understand that what I will say is heresy, but this behavior is really not wanted :). At least by me. Let me explain. The reason why we use a different font for code is exactly to document where the code related behavior is expected. If we have code related shortcuts everywhere, two things happen: - we impose code shortcuts everywhere, even in pieces of text that should have nothing to do with code. - we either have them present in contextual menus, or we do not document their existence. Either situations are not nice. I understand that this is how things worked for 20 years, but it is a limiting behavior that does not allow us to build new tools easily. I know that people use those text editors to enter some name and then press a shortcut to browse, but now we have Spotter that can do the same thing a little better. Here is the alternative: - whenever we have a selected piece of text, and we press Shift+Enter, we get that piece of text in Spotter filled by default - then using the shortcuts, we can browse what we want This is not yet implemented, but I think it can prove to become a new reflex that will solve the problems uniformly without imposing hardcoded shortcuts everywhere. Please feel free to shoot :) Cheers, Doru
On Mar 2, 2016, at 1:40 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2016, at 13:28, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Could you describe in more details the specific case we have here?
inspect
#(hello you)
then click on the first item. Now I select the 'hello' on the right and try to do "senders of" --> replace by "n".
Cheers, Doru
On Mar 2, 2016, at 11:28 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Guys,
In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose?
No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere.
I added an issue:
https://pharo.fogbugz.com/f/cases/17731/Rubric-When-not-in-Code-Mode-the-edi...
(Issue tracker status: - Open overall: 512 - Open tagged Pharo5: 319 - Closed last 7 days: 100 )
-- www.tudorgirba.com www.feenk.com
"Next time you see your life passing by, say 'hi' and get to know her."
-- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."
I am a co-heretic with Doru. In domain-specific languages built on top of Pharo you are faced exactly with what Doru is saying. I see these issues in my work on Live Robot Programming (and stuff before that). The proposed change to Spotter would be a good solution to keep all browsing options.
On Mar 2, 2016, at 10:40, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Hmm.
I understand that what I will say is heresy, but this behavior is really not wanted :). At least by me.
Let me explain.
The reason why we use a different font for code is exactly to document where the code related behavior is expected. If we have code related shortcuts everywhere, two things happen: - we impose code shortcuts everywhere, even in pieces of text that should have nothing to do with code. - we either have them present in contextual menus, or we do not document their existence. Either situations are not nice.
I understand that this is how things worked for 20 years, but it is a limiting behavior that does not allow us to build new tools easily. I know that people use those text editors to enter some name and then press a shortcut to browse, but now we have Spotter that can do the same thing a little better.
Here is the alternative: - whenever we have a selected piece of text, and we press Shift+Enter, we get that piece of text in Spotter filled by default - then using the shortcuts, we can browse what we want
This is not yet implemented, but I think it can prove to become a new reflex that will solve the problems uniformly without imposing hardcoded shortcuts everywhere.
Please feel free to shoot :)
Cheers, Doru
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile
The 'code' related behavior is currently too fixed to smalltalk code only. I want to be able to edit Pillar, PostgreSQL, user stories etc. Shortcuts for doIt, browse, senders, implementors etc. make sense for these environments, but need a different implementation. And sometimes I'm editing text where the code shortcuts do not make sense. When inspecting a symbol, I expect code related shortcuts, because they are commonly used in meta programming. Stephan
participants (5)
-
Johan Fabry -
Luc Fabresse -
Marcus Denker -
Stephan Eggermont -
Tudor Girba