2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:

I will just re-post my first answer:��

if reintroduce them means reintroduce them hardcoded as before, then I��m complete against it and I WILL NOT integrate such solution.��
I��m sorry for being so strong here, but previous implementation was lame and we need to get rid of them.��

Now, I understand people are used to use those bindings and also some others (no idea which ones because I never used them�� for me ocompletion is good enough�� but those are tastes). So I would be very happy to integrate a generic way to define keybindings and outputs (which is already there, with keymapping, but I mean an editor or something), and I would be very happy to integrate a default configuration (which of course, will include #ifTrue:/##ifFalse:)

we already have

PharoShortcuts>>#displayIfFalseShortcut
�� ^ $f alt

this is defined and therefore in the same kind "hardcoded" as any other shortcut
doItShortcut
�� ^ $d meta
inspectItShortcut
�� ^ $i meta

In PharoShortcuts

the action (RubSmalltalkEditor>>displayIfFalse: aKeyboardEvent) is just not (yet) bound to this shortcut.

I don't see how this is an argument against this shortcut definition. All other shortcuts are defined like that.

And this is not really for adding a new feature. This shortcut already (always :) ) existed in the old PluggableTextMorph based editor, it was just lost (and not on purpose I think) like other things when

we moved to rubric (as you can see, the code for this action is already there in rubric).

��

Esteban

On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@gmail.com>:
I'm also against.

- They take a place in the shortcuts that prevents others to use it
- If lazy people really needs this, the code completion should be enhanced. This is a code completion concern...

+1