2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <esteba...@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 <dionisi...@gmail.com> wrote: > > > 2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopol...@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 > > >