ifTrue ifFalse shortcuts
Locked
12
12
Re: ifTrue ifFalse shortcuts
 
|
2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <[hidden email]>:
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).
|
|
|
In reply to this post by EstebanLM
On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <[hidden email]> wrote:
> 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:) I would guess code expansions could be many and varied between different individuals, and quickly consume available keyboard shortcuts. Perhaps a generic mechanism would be single shortcut for "code expansion" which processes the letters preceding the cursor. For example, using shortcut <ctrl-e> for code expansion and typing... itf<ctrl-e> ==> ifTrue: [ ] ifFalse: [ ] The could be an interface to define these code expansions - initially at least on a purely personal basis. > And this is not really for adding a new feature. This shortcut already (always :) ) existed With a single shortcut for code expansion, perhaps a few other existing combinations could be freed up. cheers -ben > > Esteban > > On 03 Aug 2016, at 10:30, Denis Kudriashov <[hidden email]> wrote: > > > 2016-08-03 10:27 GMT+02:00 Guille Polito <[hidden email]>: >> >> 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 > > |
|
|
In reply to this post by Nicolai Hess-3-2
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. Esteban
|
Re: ifTrue ifFalse shortcuts
|
|
In reply to this post by Ben Coman
2016-08-03 10:56 GMT+02:00 Ben Coman <[hidden email]>: On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <[hidden email]> wrote: good idea, some kind of template expansion with user defined templates. cheers -ben |
Re: ifTrue ifFalse shortcuts
|
|
In reply to this post by EstebanLM
2016-08-03 11:10 GMT+02:00 Esteban Lorenzano <[hidden email]>:
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.
|
|
|
In reply to this post by Nicolai Hess-3-2
that’s a lot better than hardcoding specific expansions, yes. I still believe this is work of completion engine, though… Esteban
|
|
|
In reply to this post by Ben Coman
On 03/08/2016 10:56, Ben Coman wrote: > I would guess code expansions could be many and varied between > different individuals, and quickly consume available keyboard > shortcuts. Perhaps a generic mechanism would be single shortcut for > "code expansion" which processes the letters preceding the cursor. > For example, using shortcut <ctrl-e> for code expansion and typing... > > itf<ctrl-e> > > ==> ifTrue: [ ] ifFalse: [ ] > > The could be an interface to define these code expansions - initially > at least on a purely personal basis. > >> And this is not really for adding a new feature. This shortcut already (always :) ) existed > > With a single shortcut for code expansion, perhaps a few other > existing combinations could be freed up. > > cheers -ben > If everyone agree, let's open an issue. There is this kind of things in JetBrains Tools but with autocompletion instead of shortcut. You have some expression that make pop the autocompletion dialog to change it on piece of code. For example in Intellij you can type "sout" and the autocompletion will propose "System.out.println()". -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France |
signature.asc (817 bytes) |
|
> On 03 Aug 2016, at 13:47, Cyril Ferlicot Delbecque <[hidden email]> wrote: > > > > On 03/08/2016 10:56, Ben Coman wrote: >> I would guess code expansions could be many and varied between >> different individuals, and quickly consume available keyboard >> shortcuts. Perhaps a generic mechanism would be single shortcut for >> "code expansion" which processes the letters preceding the cursor. >> For example, using shortcut <ctrl-e> for code expansion and typing... >> >> itf<ctrl-e> >> >> ==> ifTrue: [ ] ifFalse: [ ] >> >> The could be an interface to define these code expansions - initially >> at least on a purely personal basis. >> >>> And this is not really for adding a new feature. This shortcut already (always :) ) existed >> >> With a single shortcut for code expansion, perhaps a few other >> existing combinations could be freed up. >> >> cheers -ben >> > > This would be really cool :) > If everyone agree, let's open an issue. > > There is this kind of things in JetBrains Tools but with autocompletion > instead of shortcut. You have some expression that make pop the > autocompletion dialog to change it on piece of code. > > For example in Intellij you can type "sout" and the autocompletion will > propose "System.out.println()”. exactly… we even have the algorithm implemented for this. I insist I would enhance ocompletion instead of adding an expansion shortcut. Esteban > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > |
|
|
In reply to this post by EstebanLM
> that’s a lot better than hardcoding specific expansions, yes.
> I still believe this is work of completion engine, though… > I don't know the current status (it's summer holidays), but we had a student that was interested in working on the completion engine as his bachelor thesis next year, so templates and such maybe could be part of it too. Peter |
|
|
In reply to this post by EstebanLM
On Wed, Aug 3, 2016 at 8:05 PM, Esteban Lorenzano <[hidden email]> wrote:
> >> On 03 Aug 2016, at 13:47, Cyril Ferlicot Delbecque <[hidden email]> wrote: >> >> >> >> On 03/08/2016 10:56, Ben Coman wrote: >>> I would guess code expansions could be many and varied between >>> different individuals, and quickly consume available keyboard >>> shortcuts. Perhaps a generic mechanism would be single shortcut for >>> "code expansion" which processes the letters preceding the cursor. >>> For example, using shortcut <ctrl-e> for code expansion and typing... >>> >>> itf<ctrl-e> >>> >>> ==> ifTrue: [ ] ifFalse: [ ] >>> >>> The could be an interface to define these code expansions - initially >>> at least on a purely personal basis. >>> >>>> And this is not really for adding a new feature. This shortcut already (always :) ) existed >>> >>> With a single shortcut for code expansion, perhaps a few other >>> existing combinations could be freed up. >>> >>> cheers -ben >>> >> >> This would be really cool :) >> If everyone agree, let's open an issue. >> >> There is this kind of things in JetBrains Tools but with autocompletion >> instead of shortcut. You have some expression that make pop the >> autocompletion dialog to change it on piece of code. >> >> For example in Intellij you can type "sout" and the autocompletion will >> propose "System.out.println()”. > > exactly… we even have the algorithm implemented for this. > I insist I would enhance ocompletion instead of adding an expansion shortcut. So maybe the shortcut just provides the completion engine an extra hint. Or maybe the expansion could be invoked by a special key series like a double-colon :: (if double-colon has no other special meaning, since single colons are already associated with keyword messages). For example typing itf:: ==> ifTrue: ifFalse: cheers -ben |
|
|
In reply to this post by Guillermo Polito
Le 3/8/16 à 10:27, Guille Polito a
écrit :
I'm also against. For your information a student from Prague will start to work on that soon :) Stef
|
|
|
In reply to this post by Ben Coman
Hi ben
I think that this it the way to go: Only one key binding to rule all the expansions :) Stef > On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <[hidden email]> wrote: >> 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:) > I would guess code expansions could be many and varied between > different individuals, and quickly consume available keyboard > shortcuts. Perhaps a generic mechanism would be single shortcut for > "code expansion" which processes the letters preceding the cursor. > For example, using shortcut <ctrl-e> for code expansion and typing... > > itf<ctrl-e> > > ==> ifTrue: [ ] ifFalse: [ ] > > The could be an interface to define these code expansions - initially > at least on a purely personal basis. > >> And this is not really for adding a new feature. This shortcut already (always :) ) existed > With a single shortcut for code expansion, perhaps a few other > existing combinations could be freed up. > > cheers -ben > >> Esteban >> >> On 03 Aug 2016, at 10:30, Denis Kudriashov <[hidden email]> wrote: >> >> >> 2016-08-03 10:27 GMT+02:00 Guille Polito <[hidden email]>: >>> 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 >> >> > |
|
|
In reply to this post by Nicolai Hess-3-2
+ 1 like that we can create the one we like :) Excellent idea! Stef |
|
|
In reply to this post by Peter Uhnak
Le 3/8/16 à 14:21, Peter Uhnak a écrit : >> that’s a lot better than hardcoding specific expansions, yes. >> I still believe this is work of completion engine, though… >> > I don't know the current status (it's summer holidays), but we had a student that was interested in working on the completion engine as his bachelor thesis next year, so templates and such maybe could be part of it too. If nicolai wants to hack it now let him do. There are plenty of space for completion and to me completion and expansion are not automatically the same. Stef > > Peter > > |
|
|
In reply to this post by EstebanLM
> exactly… we even have the algorithm implemented for this.
> I insist I would enhance ocompletion instead of adding an expansion shortcut. But the rules may not be the same and we will see what lukas will do. and if someone want to hack just that now then we can use it now. Stef > > Esteban > >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 165 Avenue Bretagne >> Lille 59000 France >> > > |
|
|
In reply to this post by Ben Coman
And this is how it works in VA Smalltalk. The default shortcut to expand the abbreviations used there is Shift-Space. See this excellent video by the late James Robertson: https://www.youtube.com/watch?v=TY_rJ3G0Tn4
If the same default abbreviations were used as in VA Smalltalk, this would be even cooler. No need to relearn. Cheers, Bernhard > Am 03.08.2016 um 10:56 schrieb Ben Coman <[hidden email]>: > > On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <[hidden email]> wrote: >> 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:) > > I would guess code expansions could be many and varied between > different individuals, and quickly consume available keyboard > shortcuts. Perhaps a generic mechanism would be single shortcut for > "code expansion" which processes the letters preceding the cursor. > For example, using shortcut <ctrl-e> for code expansion and typing... > > itf<ctrl-e> > > ==> ifTrue: [ ] ifFalse: [ ] > > The could be an interface to define these code expansions - initially > at least on a purely personal basis. > >> And this is not really for adding a new feature. This shortcut already (always :) ) existed > > With a single shortcut for code expansion, perhaps a few other > existing combinations could be freed up. > > cheers -ben > >> >> Esteban >> >> On 03 Aug 2016, at 10:30, Denis Kudriashov <[hidden email]> wrote: >> >> >> 2016-08-03 10:27 GMT+02:00 Guille Polito <[hidden email]>: >>> >>> 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 >> >> > |
|
|
tx Bernhard.
Indeed this is a nice suggestion. Le 10/8/16 à 20:41, Bernhard Pieber a écrit : > And this is how it works in VA Smalltalk. The default shortcut to expand the abbreviations used there is Shift-Space. See this excellent video by the late James Robertson: https://www.youtube.com/watch?v=TY_rJ3G0Tn4 > > If the same default abbreviations were used as in VA Smalltalk, this would be even cooler. No need to relearn. > > Cheers, > Bernhard > >> Am 03.08.2016 um 10:56 schrieb Ben Coman <[hidden email]>: >> >> On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <[hidden email]> wrote: >>> 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:) >> I would guess code expansions could be many and varied between >> different individuals, and quickly consume available keyboard >> shortcuts. Perhaps a generic mechanism would be single shortcut for >> "code expansion" which processes the letters preceding the cursor. >> For example, using shortcut <ctrl-e> for code expansion and typing... >> >> itf<ctrl-e> >> >> ==> ifTrue: [ ] ifFalse: [ ] >> >> The could be an interface to define these code expansions - initially >> at least on a purely personal basis. >> >>> And this is not really for adding a new feature. This shortcut already (always :) ) existed >> With a single shortcut for code expansion, perhaps a few other >> existing combinations could be freed up. >> >> cheers -ben >> >>> Esteban >>> >>> On 03 Aug 2016, at 10:30, Denis Kudriashov <[hidden email]> wrote: >>> >>> >>> 2016-08-03 10:27 GMT+02:00 Guille Polito <[hidden email]>: >>>> 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 >>> >>> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |