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.thomas@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.uhnak@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... (maybe was caused by switch to Rubric?)

Peter

Ok then I will add it to Rubric Franck

Date: Sat, 8 Aug 2015 03:54:02 -0700 From: sean@clipperadams.com To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] ifTrue ifFalse shortcuts

Peter Uhnák wrote

...

I would also appreciate if it was readded, as I've been using it regularly.

+1. Of course hopefully one day soon our dream of fully customizable shortcuts will be realized and we can each have the exact shortcuts we want :)

----- Cheers, Sean -- View this message in context: http://forum.world.st/ifTrue-ifFalse-shortcuts-tp4841604p4841618.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.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.uhnak@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.thomas@gmail.com <mailto:heniart.thomas@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.uhnak@gmail.com <mailto:i.uhnak@gmail.com> To: pharo-dev@lists.pharo.org <mailto: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... <https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-T...> (maybe was caused by switch to Rubric?)

Peter

I am nearly finished with converting old shortcut mapping (Editor/TextEditor cmdActions/shiftCmdAction map) to our keymapping framework. 15619 <https://pharo.fogbugz.com/default.asp?15619> cleanup TextEditors shortcut definition I need some more time, one or two vm changes and some people testing this on a mac. 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. 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm@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.uhnak@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.thomas@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.uhnak@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... (maybe was caused by switch to Rubric?)

Peter

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 <https://pharo.fogbugz.com/default.asp?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 <estebanlm@gmail.com <mailto:estebanlm@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.uhnak@gmail.com <mailto:i.uhnak@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.thomas@gmail.com <mailto:heniart.thomas@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.uhnak@gmail.com <mailto:i.uhnak@gmail.com> To: pharo-dev@lists.pharo.org <mailto: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... (maybe was caused by switch to Rubric?)

Peter

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 <nicolaihess@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 <stepharo@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 <estebanlm@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.uhnak@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.thomas@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.uhnak@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... (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."

From a software design perspective it shouldn't be easy to insert #ifTrue:ifFalse :)

Norbert

Am 03.08.2016 um 10:15 schrieb Nicolai Hess <nicolaihess@gmail.com>:

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 <stepharo@free.fr <mailto:stepharo@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 <https://pharo.fogbugz.com/default.asp?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 <estebanlm@gmail.com <mailto:estebanlm@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.uhnak@gmail.com <mailto:i.uhnak@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.thomas@gmail.com <mailto:heniart.thomas@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.uhnak@gmail.com <mailto:i.uhnak@gmail.com> To: pharo-dev@lists.pharo.org <mailto: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... <https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-T...> (maybe was caused by switch to Rubric?)

Peter

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... In general, my rule of thumb is to answer the following questions: How many people use it? - if a lot, maybe it makes sense to integrate it - if not a lot, make it a loadable extension How often do people use it? - if at least 10 times per hour (e.g., reformat code, senders, implementors, search) the shortcut should be simple - otherwise we can put it in a more complex combination to leave place to the common ones. Guille -------- Original Message --------

From a software design perspective it shouldn't be easy to insert #ifTrue:ifFalse :)

Norbert

...

Am 03.08.2016 um 10:15 schrieb Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:

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 <stepharo@free.fr <mailto:stepharo@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 <https://pharo.fogbugz.com/default.asp?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 <estebanlm@gmail.com <mailto:estebanlm@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.uhnak@gmail.com <mailto:i.uhnak@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.thomas@gmail.com <mailto:heniart.thomas@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.uhnak@gmail.com <mailto:i.uhnak@gmail.com>

To: pharo-dev@lists.pharo.org <mailto: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...

(maybe was caused by switch to Rubric?)

Peter

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:) Esteban

On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@gmail.com <mailto:guillermopolito@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

On 03 Aug 2016, at 10:52, Nicolai Hess <nicolaihess@gmail.com> wrote:

2016-08-03 10:36 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@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. Esteban

Esteban

...

On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@gmail.com <mailto:guillermopolito@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

On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <estebanlm@gmail.com> 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 <dionisiydk@gmail.com> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@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

On 03 Aug 2016, at 11:08, Nicolai Hess <nicolaihess@gmail.com> wrote:

2016-08-03 10:56 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>: On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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.

good idea, some kind of template expansion with user defined templates.

that’s a lot better than hardcoding specific expansions, yes. I still believe this is work of completion engine, though… Esteban

cheers -ben

...

Esteban

On 03 Aug 2016, at 10:30, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@gmail.com <mailto:guillermopolito@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

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

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()". -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

On Wed, Aug 3, 2016 at 8:05 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

On 03 Aug 2016, at 13:47, Cyril Ferlicot Delbecque <cyril.ferlicot@gmail.com> 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

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 <estebanlm@gmail.com> 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 <dionisiydk@gmail.com> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@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

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 <btc@openinworld.com>:

On Wed, Aug 3, 2016 at 4:36 PM, Esteban Lorenzano <estebanlm@gmail.com> 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 <dionisiydk@gmail.com> wrote:

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito@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