Hi, Yes. Both of those commands are in use: - Cmd+t = suggestions - Cmd+f = search
I think these types of inserts should not have simple bindings because we are asking for trouble. cheers, Doru > On Aug 3, 2016, at 10:15 AM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > Any objections on using > cmd+t / cmd+f for insert ifTrue/ifFalse > (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). > > 2015-08-12 18:52 GMT+02:00 stepharo <steph...@free.fr>: > > > Le 11/8/15 10:25, Nicolai Hess a écrit : >> I am nearly finished with converting old shortcut mapping (Editor/TextEditor >> cmdActions/shiftCmdAction map) >> to our keymapping framework. >> >> 15619 >> cleanup TextEditors shortcut definition > > Thank a lot! > > Yesterday with guillermo and christophe we spent one full afternoon reading > all the recursive dependencies introduced > when we just want to have monticello in the bootstrap (to be able to load > code). > We filled up two black boards and I should say that I was a nice down to see > the complexity but we will fix it :). > > Yesterday Esteban sat with igor and started to integrate the OSWindow > integration work of igor (yes igor you should do pull requests :). > So there are some problems with the mac vm and this will have to be fixed > (probably next week). > After I hope that we will get clean events from SDL >> >> I need some more time, one or two vm changes and some people testing this on >> a mac. > > Tell us we will :) > >> >> I know, this is a bit late because we replace our text components with >> rubric, but if this >> is finished and working for "old" PluggableTextMorphs, I will do the same >> for rubric. > Thanks thanks thanks. > I often frustrated when I see myself doing things more than twice but this is > a pattern. I decided long time ago that > if this is necessary to do intermediate actions to lower the stress on the > future actions, I'm ready to throw awy what > I did to get the ultimate goal reached. > > >> >> >> >> 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: >> 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:) >> >> Esteban >> >> >> >>> On 08 Aug 2015, at 12:45, Peter Uhnák <i.uh...@gmail.com> wrote: >>> >>> I would also appreciate if it was readded, as I've been using it regularly. >>> >>> Peter >>> >>> On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart <heniart.tho...@gmail.com> >>> wrote: >>> I think it could be nice to keep this shortcut :) >>> >>> >>> On 08/08/2015 12:12, Franck Warlouzet wrote: >>>> Hi, >>>> >>>> Yes it was not on purpose. It is not implemented in Rubric, but I can do >>>> it if there is a need of it (which seems to be the case). >>>> >>>> Franck >>>> >>>> Date: Sat, 8 Aug 2015 12:09:22 +0200 >>>> From: i.uh...@gmail.com >>>> To: pharo-dev@lists.pharo.org >>>> Subject: [Pharo-dev] ifTrue ifFalse shortcuts >>>> >>>> Hi, >>>> >>>> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? >>>> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-T-cmd-F-ifTrue-ifFalse-shortcuts-anymore >>>> (maybe was caused by switch to Rubric?) >>>> >>>> Peter >>> >>> >> >> > > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."
