2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <[email protected]>:
> 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 <[email protected]> wrote:
>
>
> 2016-08-03 10:27 GMT+02:00 Guille Polito <[email protected]>:
>
>> 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
>
>
>
