2016-08-03 11:10 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: > > On 03 Aug 2016, at 10:52, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 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). > > > yes, it existed… and it was bad, as are bad all hardcoded shortcuts that > yes, still exists a lot in the system. > but we want to clean the system, not perpetuate it. > > for me, this is not a shortcut problem but a completion one… what we need > to do is to enhance it. But even not doing it, I would not introduce new > hardcoded shortcuts. >
And what is a hardcoded shortcut? The ones defined in PharoShortcuts? Do we have any why to define shortcuts "not hardcoded". Sure we should make this editable/configurable. But *first* we need to unify the current shortcut handling. This shortcut handling is done by the KMDispatcher and (even in Rubric) by the editors actionMaps and in various places in the code. If I can not *move* a shortcut definition/handling from the text editors action map to the KMDispatcher because that shortcut definition would be "hardcoded", I can not do anything. > > Esteban > > > > > > > > > > >> >> 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 >> >> >> > >
