On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too. Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults. For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Best regards, Igor Stasenko.

+1 Alexandre On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

+1

Doru

On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot be done."

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion i.e. this is the behavior in XCode, which imho is a very good one. _and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection. Maybe people should give this a try and see? cheers Johan On 06 Apr 2013, at 02:18, Ben Coman <btc@openInWorld.com> wrote:

Alexandre Bergel wrote:

...

+1

Alexandre

On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

+1

Doru

On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing.

cheers -ben

How can I get fast the choices? Because when I type printO and press tab I do not get printOn: but printO | Stef

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion

i.e. this is the behavior in XCode, which imho is a very good one.

_and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection.

Maybe people should give this a try and see?

cheers Johan

<NECController-Changes.cs>

On 06 Apr 2013, at 02:18, Ben Coman <btc@openInWorld.com> wrote:

...

Alexandre Bergel wrote:

...

+1

Alexandre

On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

+1

Doru

On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing.

cheers -ben

oh, I'm here too, but that's because I have insomnia, not kids :) On Apr 6, 2013, at 8:44 AM, Johan Brichau <johan@inceptive.be> wrote:

Indeed, I also increased the popup speed in the preferences to something like 100 or 200ms.

But yes, you should wait for them to pop up. I did not address any other issues than the 'completion keystroke'.

btw, judging by the time of day, you can see who has small kids on this mailing list :-)

On 06 Apr 2013, at 08:38, stephane ducasse <stephane.ducasse@free.fr> wrote:

...

How can I get fast the choices? Because when I type

printO

and press tab I do not get

printOn: but

printO | Stef

...

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion

i.e. this is the behavior in XCode, which imho is a very good one.

_and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection.

Maybe people should give this a try and see?

cheers Johan

<NECController-Changes.cs>

On 06 Apr 2013, at 02:18, Ben Coman <btc@openInWorld.com> wrote:

...

Alexandre Bergel wrote:

...

+1

Alexandre

On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

+1

Doru

On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing.

cheers -ben

stephane ducasse wrote

would it be possible to get a couple of settings that you use?

NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Apr 6, 2013, at 11:44 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

If everybody likes it, maybe we should consider putting this configuration as default, no ?

yes but first I would like to see the difference because I do not like it :)

Ben

On Apr 6, 2013, at 8:59 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

stephane ducasse wrote

...

would it be possible to get a couple of settings that you use?

NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sounds like a good classroom assignment for a class incorporating Usability Testing :) Esteban Lorenzano wrote:

I still think useEnterToAccept has to be true I sustain the idea of lower the entry level for the newcomers, instead supporting as default the use-workflow of power users (they have a settings browser there). We took this decision last year and I think it was a good one... not that we cannot change, but I would stick with it for now.

I think the current completion functionality has some other problems that makes it sometimes uncomfortable to use...

On Apr 7, 2013, at 12:16 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:

...

On Apr 6, 2013, at 11:44 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

If everybody likes it, maybe we should consider putting this configuration as default, no ?

yes but first I would like to see the difference because I do not like it :)

...

Ben

On Apr 6, 2013, at 8:59 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

stephane ducasse wrote

...

would it be possible to get a couple of settings that you use?

NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Experienced that too ( a lot ) Ben On Apr 7, 2013, at 2:20 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

oh... I taught smalltalk for 3 years, using Pharo every lesson.

During those years, I didn't met any single student that didn't tried to press enter the first N times to get a completion. And every time the student complained, until I repeated (often several times) that they should use tab instead. And every time they make the same question "why is not like in [put your favorite IDE here]?"... still today, I do not have an answer, that's why I think is better not to provoke the question :)

cheers, Esteban

On Apr 7, 2013, at 2:03 PM, Ben Coman <btc@openInWorld.com> wrote:

...

Sounds like a good classroom assignment for a class incorporating Usability Testing :)

Esteban Lorenzano wrote:

...

I still think useEnterToAccept has to be true I sustain the idea of lower the entry level for the newcomers, instead supporting as default the use-workflow of power users (they have a settings browser there). We took this decision last year and I think it was a good one... not that we cannot change, but I would stick with it for now. I think the current completion functionality has some other problems that makes it sometimes uncomfortable to use...

On Apr 7, 2013, at 12:16 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:

...

On Apr 6, 2013, at 11:44 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

If everybody likes it, maybe we should consider putting this configuration as default, no ?

yes but first I would like to see the difference because I do not like it :)

...

Ben

On Apr 6, 2013, at 8:59 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

stephane ducasse wrote

...

would it be possible to get a couple of settings that you use?

NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Esteban A. Maringolo wrote:

2013/4/7 Benjamin <benjamin.vanryseghem.pharo@gmail.com>:

...

Experienced that too ( a lot )

Me too.

I have other comments regarding "first use experiences" of smalltalkers and non-smalltalkers. Once I contribute something, I'll make them public. :-)

Regards!

Esteban

That would be interesting.

EstebanLM wrote

And every time they make the same question "why is not like in [put your favorite IDE here]?"... still today, I do not have an answer, that's why I think is better not to provoke the question :)

I believe that they only asked that because we didn't have it, so no one realized that in Smalltalk, where you often end lines with identifiers, instead of non-alphanumerics like in C, it is way more annoying to have 'String' completed to 'StringApiSetter' than to learn to press tab instead of enter. That having been said, like Johan I'm fine using my own custom settings, so how about we combine the following defaults with Johan's changeset and see how it goes: NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: true; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

I agree. :) On Apr 7, 2013, at 8:30 PM, Johan Brichau <johan@inceptive.be> wrote:

I'm fine with the fact that Pharo decides to put that as a default (because I can change it).

But the preferences are fundamentally flawed: if I disable useEnterToAccept then I cannot even use <tab> instead. I should also disable the <tab> as the completion of common prefixes. The change I attached to my email demonstrates that this should not be the case.

On 07 Apr 2013, at 12:27, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

I still think useEnterToAccept has to be true I sustain the idea of lower the entry level for the newcomers, instead supporting as default the use-workflow of power users (they have a settings browser there). We took this decision last year and I think it was a good one... not that we cannot change, but I would stick with it for now.

I think the current completion functionality has some other problems that makes it sometimes uncomfortable to use...

On Apr 7, 2013, at 12:16 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:

...

On Apr 6, 2013, at 11:44 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

If everybody likes it, maybe we should consider putting this configuration as default, no ?

yes but first I would like to see the difference because I do not like it :)

...

Ben

On Apr 6, 2013, at 8:59 PM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

stephane ducasse wrote

...

would it be possible to get a couple of settings that you use?

NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

One is proposing all the symbols (without package names, timestamp and few others) alphabetically sorted, the other one is "learning" , so the order is depending on your last accepts. But I do not remember the names :S Ben On Apr 7, 2013, at 12:49 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

What is the difference between NECController and NOCController ? In my image the latter seems to be the default, Sean is using the former. Why ?

On 06 Apr 2013, at 20:59, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

stephane ducasse wrote

...

would it be possible to get a couple of settings that you use?

NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sven Van Caekenberghe-2 wrote

What is the difference between NECController and NOCController ? In my image the latter seems to be the default, Sean is using the former. Why ?

I'm using NOCController. The class I referenced is NECPreferences, which seems to control the settings no matter which controller you use. p.s. http://users.dcc.uchile.cl/~rrobbes/p/JASE-completion.pdf describes the difference in controllers and is a fun read ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Works very well for me with a 100ms delay 2013/4/6 Johan Brichau <johan@inceptive.be>

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion

i.e. this is the behavior in XCode, which imho is a very good one.

_and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection.

Maybe people should give this a try and see?

cheers Johan

On 06 Apr 2013, at 02:18, Ben Coman <btc@openInWorld.com> wrote:

...

Alexandre Bergel wrote:

...

+1

Alexandre

On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

+1

Doru

On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From

https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne...

...

:

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing.

cheers -ben

Sean P. DeNigris wrote

Johan Brichau-2 wrote

...

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion

Maybe people should give this a try and see? Sounds cool. I will start using it and report back. Thanks!

I like it :) I can still disable enter-to-accept, and the tab twice for full completion thing is great. After cranking up Xcode and navigating around, one thing I noticed was that the C file I was looking at ended every line with a non-alphanumeric character (e.g. $", $; $)), so enter would never accidentally complete anything when what one meant to do was get a cr. As mentioned above, this is not the case for st and I think disabling enter-to-accept makes more sense as the default. I'd rather have new users asking and us explaining that it can be turned on, than have them annoyed by e.g. typing "String" <cr> and ending up with "StringApiSetter", which I found very jarring. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Hi Johan, Thanks for acting to get everyone out of the deadlock situation :). I will give it a try as well and let you know. Cheers, Doru On Apr 6, 2013, at 8:22 AM, Johan Brichau <johan@inceptive.be> wrote:

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion

i.e. this is the behavior in XCode, which imho is a very good one.

_and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection.

Maybe people should give this a try and see?

cheers Johan

<NECController-Changes.cs>

On 06 Apr 2013, at 02:18, Ben Coman <btc@openInWorld.com> wrote:

...

Alexandre Bergel wrote:

...

+1

Alexandre

On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

...

+1

Doru

On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing.

cheers -ben

-- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

+1 Doru On Apr 18, 2013, at 5:25 AM, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

Johan Brichau-2 wrote

...

fwiw, I changed the implementation of NECController... NECController-Changes.cs (5K) <http://forum.world.st/attachment/4679910/0/NECController-Changes.cs>;

I think at minimum Johan's change should be integrated immediately and backported to 2.0. I simply can not use enterToAccept, and without it now it's currently impossible to complete with common prefix matching enabled.

Are there any objections to the last suggested set of default preferences? If not, maybe those should be included as well - but not worth holding up Johan's change, which is essential.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- www.tudorgirba.com "Be rather willing to give than demanding to get."

add a bug entry and tag it so that we simply do not forget. Stef On Apr 18, 2013, at 5:25 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Johan Brichau-2 wrote

...

fwiw, I changed the implementation of NECController... NECController-Changes.cs (5K) <http://forum.world.st/attachment/4679910/0/NECController-Changes.cs>;

I think at minimum Johan's change should be integrated immediately and backported to 2.0. I simply can not use enterToAccept, and without it now it's currently impossible to complete with common prefix matching enabled.

Are there any objections to the last suggested set of default preferences? If not, maybe those should be included as well - but not worth holding up Johan's change, which is essential.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

+1 Very annoying. 2013/4/4 Igor Stasenko <siguctua@gmail.com>

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From

https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne...

...

:

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Best regards, Igor Stasenko.

Well... I disagree with your disagreement :) We are talking about two different things: 1) the current defaults 2) some possible broken configuration about the current defaults, "enter" is the one that is choose for 99% of IDEs around the world (and yes, the 1% default is probably just Pharo 1.4). so, we took the world default and placed there because we want to be friendly with newcomers (and frankly, I'm tired of see students learning Pharo pressing enter each time they want a completion and complaining when they don't have the answer they expect) The enter as default should stay, because that's the world standard. For power users like you, there is a settings browser to disable it... and you know, there is also a way to store your settings, so you can put them there and never ever in your life realize that you have different defaults. Now, in the settings: Go to code completion configuration: 1) Disable the option "Complete common prefixes using TAB in the suggested completions". This is for provide something like the bash completion (that completes until the chars are equal and allows you to introduce a character to continue refining the completion) 2) Disable the option "Use ENTER to accept a suggested completion" and then you have exactly the same behavior as before :) (but yes, the message explaining the options could be better) you can also then press "Export Settings" (button in top-right), and all your images will share same configuration. how to doit directly in the settings? go to ~/Library/Preferences/pharo/2.0 (for Mac) (if it does not exist, just create it) then create a file settings.st, with this content: StartupLoader default executeAtomicItems: { StartupAction name: 'Settings 2.0' code: [ NECPreferences expandPrefixes: false; useEnterToAccept: false. ] runOnce: true. }. I don't think that this is perfect, and there are some things that certainly can be enhanced... but you actually can configure your settings. It is impossible to believe that everybody will share same taste for programming, what you believe is obvious is obscure for others... that's why we try to match standards when we can, and to provide settings enough for those who does not follow them :) cheers, Esteban On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 3 April 2013 22:45, Camillo Bruni <camillobruni@gmail.com> wrote:

...

theres a setting to:

- disable ENTER to accept the completion - to increase the popup delay

so I think that is invalid bug report then...

i tend to disagree. The defaults which we have now in 2.0 for autocompletion is breaking my workflow badly too.

Yes, i can go to settings and disable/reconfigure stuff but that doesn't nullifying the fact, that my workflow is broken with ambiguous and inconsistent reaction(s) to my keystrokes by UI if i keep defaults.

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

...

On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean@clipperadams.com> wrote:

...

From https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardne... :

...

The combination of enter on accept, with the current behavior to select the first completion suggestion by default = trouble. For example:

1. Type "printOn: aStream"... pretty common method start 2. Hit enter to go to the next line

You will now have "printOn: MCDataStream" WTF!! I get burned by this pretty regularly and it's annoying. I'm not sure what the fix should be... probably no default selection in the suggestion menu, but possibly only when enter on accept is enabled (t would require an extra key press to complete and when do you ever type a tab in the middle of a line?)

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Best regards, Igor Stasenko.

On Apr 4, 2013, at 10:30 AM, Johan Brichau <johan@inceptive.be> wrote:

Hi Esteban,

I tend to agree with your argument but...

...

about the current defaults, "enter" is the one that is choose for 99% of IDEs around the world (and yes, the 1% default is probably just Pharo 1.4).

All those IDEs offer both <tab> and <enter> to trigger code completion. If I enable <enter> in Pharo, the <tab> no longer works.

yes, then there is room for improvement :)

I also wonder why I don't find the <enter> behavior annoying in other IDEs. Can it be the case that Smalltalk code has more 'line ends' that just terminate with a word? In many other languages, a code line is more often terminated with a non alphanumeric character (separators, braces, etc...). I am not sure about this but I wonder...

I bet is because you were used to use tab in Pharo... it will be as smooth as in other IDEs as soon as you change the mindset :)

In any case, is it difficult to enable the both <tab> and <enter>?

yes and no... I mean. It is easy, but is hardcoded in NECController>>handleKeystrokeBefore:editor: so... you can hack around there :) Esteban

cheers, Johan

With this patch it works for me. On 4 April 2013 10:54, Johan Brichau <johan@inceptive.be> wrote:

On 04 Apr 2013, at 10:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

...

In any case, is it difficult to enable the both <tab> and <enter>?

yes and no... I mean. It is easy, but is hardcoded in

NECController>>handleKeystrokeBefore:editor:

so... you can hack around there :)

That is what I needed to know :-)

cheers Johan

-- Best regards, Igor Stasenko.

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Esteban

On Apr 4, 2013, at 1:59 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

With this patch it works for me.

On 4 April 2013 10:54, Johan Brichau <johan@inceptive.be> wrote:

...

On 04 Apr 2013, at 10:40, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

...

In any case, is it difficult to enable the both <tab> and <enter>?

yes and no... I mean. It is easy, but is hardcoded in

NECController>>handleKeystrokeBefore:editor:

so... you can hack around there :)

That is what I needed to know :-)

cheers Johan

-- Best regards, Igor Stasenko. <NECController-handleKeystrokeBeforeeditor.st>

-- Best regards, Igor Stasenko.

On 4 April 2013 17:38, Camillo Bruni <camillobruni@gmail.com> wrote:

On 2013-04-04, at 16:11, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Igor, not Esteban's workflow.. OUR WORKFLOW!

Sure sure. Now have you tried the code which i sent if it works/breaks for you? Or i should spend like 10 minutes filing the issue before figuring that it is unacceptable? https://pharo.fogbugz.com/default.asp?10228 -- Best regards, Igor Stasenko.

On Apr 4, 2013, at 7:52 PM, Camillo Bruni <camillobruni@gmail.com> wrote:

On 2013-04-04, at 18:51, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 17:38, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-04-04, at 16:11, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Igor, not Esteban's workflow.. OUR WORKFLOW!

Sure sure. Now have you tried the code which i sent if it works/breaks for you?

Or i should spend like 10 minutes filing the issue before figuring that it is unacceptable?

What the fuck do you think the rest does?

...

https://pharo.fogbugz.com/default.asp?10228

|( well the issue is the main entry point. If the code does not work you will be notified VIA the issue => manageed entity

However how you solve this issue right now is by some fuzzy undefined process nobody manages. If you think that this change is worth getting into pharo then you open an issue and attach the SLICE (no changeset, SLICES).

Then the whole machinery starts, people (INCLUDING YOU) look at the issues. Issue get rejected, modified, adapted!

What you show here is IGNORANCE on a higher level. YOU IGNORE A WHOLE DAMN DEVELOPMENT PROCESS PEOPLE USE EVERY DAY.

But I think Igor was proposing exactly that what esteban was already arguing agains? In that case an issue tracker entry makes not much sense, we first need to discuss what to do. Marcus

On 2013-04-04, at 20:10, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 04 Apr 2013, at 19:58, Marcus Denker <marcus.denker@inria.fr> wrote:

...

On Apr 4, 2013, at 7:52 PM, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-04-04, at 18:51, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 17:38, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-04-04, at 16:11, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Igor, not Esteban's workflow.. OUR WORKFLOW!

Sure sure. Now have you tried the code which i sent if it works/breaks for you?

Or i should spend like 10 minutes filing the issue before figuring that it is unacceptable?

What the fuck do you think the rest does?

...

https://pharo.fogbugz.com/default.asp?10228

|( well the issue is the main entry point. If the code does not work you will be notified VIA the issue => manageed entity

However how you solve this issue right now is by some fuzzy undefined process nobody manages. If you think that this change is worth getting into pharo then you open an issue and attach the SLICE (no changeset, SLICES).

Then the whole machinery starts, people (INCLUDING YOU) look at the issues. Issue get rejected, modified, adapted!

What you show here is IGNORANCE on a higher level. YOU IGNORE A WHOLE DAMN DEVELOPMENT PROCESS PEOPLE USE EVERY DAY.

But I think Igor was proposing exactly that what esteban was already arguing agains? In that case an issue tracker entry makes not much sense, we first need to discuss what to do.

Marcus

That is also how I understood it: he posted a quick hack asking for feedback, the next step would be to make an issue and proper slice [ which indeed he has to learn to do like everybody else ] - I must admit that I am also still struggling with the new issue tracker (mainly because of lack of time), I miss the old one that I was used to.

I am sorry for my outburst (again)... but my arguments stay since they stand unanswered since january.

On 4 April 2013 19:52, Camillo Bruni <camillobruni@gmail.com> wrote:

On 2013-04-04, at 18:51, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 17:38, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-04-04, at 16:11, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Igor, not Esteban's workflow.. OUR WORKFLOW!

Sure sure. Now have you tried the code which i sent if it works/breaks for you?

Or i should spend like 10 minutes filing the issue before figuring that it is unacceptable?

What the fuck do you think the rest does?

...

https://pharo.fogbugz.com/default.asp?10228

|( well the issue is the main entry point. If the code does not work you will be notified VIA the issue => manageed entity

However how you solve this issue right now is by some fuzzy undefined process nobody manages. If you think that this change is worth getting into pharo then you open an issue and attach the SLICE (no changeset, SLICES).

Then the whole machinery starts, people (INCLUDING YOU) look at the issues. Issue get rejected, modified, adapted!

What you show here is IGNORANCE on a higher level. YOU IGNORE A WHOLE DAMN DEVELOPMENT PROCESS PEOPLE USE EVERY DAY. And you put yourself into the brilliant exception position.

Not at all.

Believe me I am not the only one who is upset with that. (but usually the one who complains first).

So why do I complain?

- I know that you haven't filed a single issue on the new issue tracker - I know that you DO NOT like the new issue tracker - I know that you DO NOT like to use SLICES (even though everybody else does)

and.. - I am pretty convinced that you will never file an issue on the new issue tracker

Hmm.. I already did. Before you even wrote your outrageous post.

Why? I don't know, I really don't. I wish I could understand your point here, but I cannot.

You did not replied to a most important question , which goes first: does it works for you or not. Issue tracker (as its name states) helps with tracking the issue, but it does not solves it. Putting things on issue tracker doesn't means that issue will be solved. Because nothing forces you to look at issue, you can still ignore it. You can complain that it was not filed correctly, there's "field A is empty", field B is wrong and all sorts of bureaucracy.. So, if there's no action (like trying the proposed solution) while topic is hot on mailing list, i am pretty sure that there will be no any action with that issue later. The code will be just silently integrated, only to be found later that change is inappropriate and breaks things here and there.. and then we go over again, by opening one more issue, and spending our precious time on following the process, instead of solving the real problems. -- Best regards, Igor Stasenko.

Ben On Apr 5, 2013, at 8:29 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 4 April 2013 19:52, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-04-04, at 18:51, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 17:38, Camillo Bruni <camillobruni@gmail.com> wrote:

...

On 2013-04-04, at 16:11, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Igor, not Esteban's workflow.. OUR WORKFLOW!

Sure sure. Now have you tried the code which i sent if it works/breaks for you?

Or i should spend like 10 minutes filing the issue before figuring that it is unacceptable?

What the fuck do you think the rest does?

...

https://pharo.fogbugz.com/default.asp?10228

|( well the issue is the main entry point. If the code does not work you will be notified VIA the issue => manageed entity

However how you solve this issue right now is by some fuzzy undefined process nobody manages. If you think that this change is worth getting into pharo then you open an issue and attach the SLICE (no changeset, SLICES).

Then the whole machinery starts, people (INCLUDING YOU) look at the issues. Issue get rejected, modified, adapted!

What you show here is IGNORANCE on a higher level. YOU IGNORE A WHOLE DAMN DEVELOPMENT PROCESS PEOPLE USE EVERY DAY. And you put yourself into the brilliant exception position.

Not at all.

...

Believe me I am not the only one who is upset with that. (but usually the one who complains first).

So why do I complain?

- I know that you haven't filed a single issue on the new issue tracker - I know that you DO NOT like the new issue tracker - I know that you DO NOT like to use SLICES (even though everybody else does)

and.. - I am pretty convinced that you will never file an issue on the new issue tracker

Hmm.. I already did. Before you even wrote your outrageous post.

...

Why? I don't know, I really don't. I wish I could understand your point here, but I cannot.

You did not replied to a most important question , which goes first: does it works for you or not.

Issue tracker (as its name states) helps with tracking the issue, but it does not solves it.

Putting things on issue tracker doesn't means that issue will be solved. Because nothing forces you to look at issue, you can still ignore it.

That's exactly why here we have automated actions performed. (and on the other hand, nothing forces you to provide a fix, to code, to go outside of you bed …)

You can complain that it was not filed correctly, there's "field A is empty", field B is wrong and all sorts of bureaucracy..

So, if there's no action (like trying the proposed solution) while topic is hot on mailing list, i am pretty sure that there will be no any action with that issue later. The code will be just silently integrated, only to be found later that change is inappropriate and breaks things here and there.. and then we go over again, by opening one more issue, and spending our precious time on following the process, instead of solving the real problems.

And when we will try to tackle issues to fix, we will iterate over all mailing list thread to find them ? If discussion like this happened in the issue tracker - people not implied in Pharo bug fixing (aka people without an account on fogbugz) do not get massively spammed - when someone want to fix this, he/she will not have to try to remember what it's about, guess the discussion was in the mailing list, retrieve the thread, etc … If you think that your time is more precious that any one else's, then maybe you missed what a community is … People spent time setting up the issue tracker to make it fit into our usual workflow, writing documentation about how to report an issue, and it has been decided that it was the way we (the community) manage bugs. Managing them in a mailing list has already been tried, and was not successful. I hate to blame, but the way you are acting know is just saying "I will not try to fit into the community workflow, I will stick to mine, and people will have to adapt'. I am sorry, it doesn't work. Ben PS: I flag your issue resolved (since a fix has been proposed), as explained here[1], it's the first and last time. My time is not less precious than yours [1] https://pharo.fogbugz.com/default.asp?W46

-- Best regards, Igor Stasenko.

On 04 Apr 2013, at 19:02, Diego Lont <diego.lont@delware.nl> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Esteban,

Having a new Browser in Pharo 2.0 is a big change. Everyone needs to get used to it. And I agree it is probably a good thing. But … there are some things that worked better in OB that I don't want to loose. There are a lot of people annoyed by how it works now…. but I think the mailing list is about exchanging arguments not about deciding. So I do not like that you try to end the discussion by shouting: the defaults will not change. So here I will add a new argument.

Your argument about other languages is a valid point, but only holds if Smalltalk is similar as other languages. Why does this "enter" annoys me? Because in some cases it replaces my code by garbage. At least when I type a method invocation that does not exist yet, it replaces it by an existing method. And this is repeatable. So when you go back (using backspace and typing it again, because it also adds before the things I typed) and the press enter again, it does the same replacement. So there is a difference here between smalltalk and other languages. When I do test-driven development (that I do a lot), I first write my test, invoking a lot of methods that do not exist yet. I do not do this in another language, because my environment isn't good enough then.

I feel that we are confusing lots of things. This is not a discussion about the browser or the IDE, it is about completion. And not just about which key does what but also about complex interactions in specific situations. Pharo 2.0 is out, Nautilus is the default browser, a massive amount of work went into cleaning and getting a workable completion system, choices were made - you/we basically have to live with that. There are options in Settings for some tuning, and we will continue to improve, absolutely. We have to discuss and iterate. Please do not underestimate the amount of work done to get 2.0 where it is now. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

On 05 Apr 2013, at 11:20, Diego Lont <diego.lont@delware.nl> wrote:

...

I feel that we are confusing lots of things.

This is not a discussion about the browser or the IDE, it is about completion. And not just about which key does what but also about complex interactions in specific situations.

Pharo 2.0 is out, Nautilus is the default browser, a massive amount of work went into cleaning and getting a workable completion system, choices were made - you/we basically have to live with that.

There are options in Settings for some tuning, and we will continue to improve, absolutely. We have to discuss and iterate.

Please do not underestimate the amount of work done to get 2.0 where it is now.

Sven

Sven,

I agree that a lot of good work has been done to get 2.0 where it is now. I do not want to ignore that. And I think we all have to same goal: to make Pharo better. So when I think I have a point, I want an open discussion about this.

On the PharoConf I said some things to Stef, and he answered: discuss this on the mailing list. Now I try to do so on the mailinglist and I get responses like: "settings will not change" " We did a lot of work, so do not complain"

Please tell me, why do you think this is not worth discussing?

Regards, Diego

Diego, Read my mail, I said: "We have to discuss and iterate." It is just that 2.0 is released, it cannot change, 2.x will never have drastic changes. 3.0 is the next line of development. To stay on the subject: I have worked with/in 2.0 for many months, maybe almost a year. Completion went through lots of iterations, there were many discussions. It is reasonably good or at least acceptable now (at some points it was completely broken). Some people worked very hard on this and I respect that enormously (they also had to deal with everybody's opinion as well as complex code). I am very confident that we can tune this a bit more to make it 'perfect'. The main issue IMHO is not so much the actual key binding, but the way to get out of the menu if you don't want to pick a suggestion (though ESC does that). It might be that Smalltalk is special here, but I doubt it. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Oh, Spotlight is another victim of the code completion lack of accurate answers... and yes, I agree: both code completion and spotlight in consequence were working better in 1.4. Esteban On Apr 5, 2013, at 11:45 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:

Sven,

Indeed, Pharo 2.0 is really interesting.

Nautilus and stuff like that are really going in the right directions.

Now, would there be a succinct explanation on what makes the most sense for completion? The spotlight box is really getting on my nerves and I can't figure out why and it worked better on 1.4.

I am Cmd-Clicking on classes and methods as it is easier for me to now start typing in a workspace and navigate from there due to Spotlight not working well.

What is the behavior to expect from Spotlight? I may be doing things wrong by just typing words and then enter...

Phil

2013/4/5 Sven Van Caekenberghe <sven@stfx.eu>

On 04 Apr 2013, at 19:02, Diego Lont <diego.lont@delware.nl> wrote:

...

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Esteban,

Having a new Browser in Pharo 2.0 is a big change. Everyone needs to get used to it. And I agree it is probably a good thing. But … there are some things that worked better in OB that I don't want to loose. There are a lot of people annoyed by how it works now…. but I think the mailing list is about exchanging arguments not about deciding. So I do not like that you try to end the discussion by shouting: the defaults will not change. So here I will add a new argument.

Your argument about other languages is a valid point, but only holds if Smalltalk is similar as other languages. Why does this "enter" annoys me? Because in some cases it replaces my code by garbage. At least when I type a method invocation that does not exist yet, it replaces it by an existing method. And this is repeatable. So when you go back (using backspace and typing it again, because it also adds before the things I typed) and the press enter again, it does the same replacement. So there is a difference here between smalltalk and other languages. When I do test-driven development (that I do a lot), I first write my test, invoking a lot of methods that do not exist yet. I do not do this in another language, because my environment isn't good enough then.

I feel that we are confusing lots of things.

This is not a discussion about the browser or the IDE, it is about completion. And not just about which key does what but also about complex interactions in specific situations.

Pharo 2.0 is out, Nautilus is the default browser, a massive amount of work went into cleaning and getting a workable completion system, choices were made - you/we basically have to live with that.

There are options in Settings for some tuning, and we will continue to improve, absolutely. We have to discuss and iterate.

Please do not underestimate the amount of work done to get 2.0 where it is now.

Sven

-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

I personally solve that by disabling auto popup :) And it fits in what Doru said. I have to hit ctrl space to pops up completion, and here, I know that I am in completion mode, so pressing enter is not breaking my workflow. Moreover, usually when I see people using completion, it's highly a lost of time. the basic case is instead of fully typing 'asString', they type 'as', wait 3 seconds, press arrow down 20 times, and finally accept. This is for me so strange :) Maybe it's because I have been through a couple of Pharo version with auto completion disabled because it was a pain :D Ben On Apr 5, 2013, at 2:12 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:

EstebanLM wrote

...

Oh, Spotlight is another victim of the code completion lack of accurate answers... and yes, I agree: both code completion and spotlight in consequence were working better in 1.4.

With enter-on-accept disabled, I'm really enjoying the completion in 2.0. I find partial completions extremely helpful. I don't think we're that far from where we want to be. Let's just define what's missing and get it done.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Popup is automatic -> false Popup appears with this shortcut -> Shift + (here is a space that you do not see ^^) Because of the VM, ctrl+space is never received (yet ^^) Ben On Apr 5, 2013, at 2:45 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:

Ben, you have it! Just have the search-completion linked to ctrl+space!

Where is that setting ?

Thierry

Le 05/04/2013 14:38, Benjamin a écrit :

...

I personally solve that by disabling auto popup :) And it fits in what Doru said.

I have to hit ctrl space to pops up completion, and here, I know that I am in completion mode, so pressing enter is not breaking my workflow.

Moreover, usually when I see people using completion, it's highly a lost of time. the basic case is instead of fully typing 'asString', they type 'as', wait 3 seconds, press arrow down 20 times, and finally accept. This is for me so strange :)

Maybe it's because I have been through a couple of Pharo version with auto completion disabled because it was a pain :D

...

Ben

On Apr 5, 2013, at 2:12 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:

...

EstebanLM wrote

...

Oh, Spotlight is another victim of the code completion lack of accurate answers... and yes, I agree: both code completion and spotlight in consequence were working better in 1.4.

With enter-on-accept disabled, I'm really enjoying the completion in 2.0. I find partial completions extremely helpful. I don't think we're that far from where we want to be. Let's just define what's missing and get it done.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com <http://Nabble.com>.

-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

On Apr 5, 2013, at 8:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 April 2013 14:38, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

I personally solve that by disabling auto popup :) And it fits in what Doru said.

I have to hit ctrl space to pops up completion, and here, I know that I am in completion mode, so pressing enter is not breaking my workflow.

Moreover, usually when I see people using completion, it's highly a lost of time. the basic case is instead of fully typing 'asString', they type 'as', wait 3 seconds, press arrow down 20 times, and finally accept. This is for me so strange :)

Haha.. exactly. Now imagine that you were used it for a while and was quite effective with it and get used to it. And then, suddenly it stopped working, and when it came back, and you so happy that you can use it now, you found that now it inserting bullshit every time you trying to do something. Yes, in that case best option would be to disable it completely and do not annoy "highly adaptive" guys with your inability to adapt.... to bullshit

Did I say it was perfect ? On the other hand, did you review it when Esteban and I proposed a fix after having spending days fixing it ? Ben

...

Maybe it's because I have been through a couple of Pharo version with auto completion disabled because it was a pain :D

Ben

-- Best regards, Igor Stasenko.

On Apr 5, 2013, at 9:34 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 5 April 2013 21:29, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

On Apr 5, 2013, at 8:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 5 April 2013 14:38, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

I personally solve that by disabling auto popup :) And it fits in what Doru said.

I have to hit ctrl space to pops up completion, and here, I know that I am in completion mode, so pressing enter is not breaking my workflow.

Moreover, usually when I see people using completion, it's highly a lost of time. the basic case is instead of fully typing 'asString', they type 'as', wait 3 seconds, press arrow down 20 times, and finally accept. This is for me so strange :)

Haha.. exactly. Now imagine that you were used it for a while and was quite effective with it and get used to it. And then, suddenly it stopped working, and when it came back, and you so happy that you can use it now, you found that now it inserting bullshit every time you trying to do something. Yes, in that case best option would be to disable it completely and do not annoy "highly adaptive" guys with your inability to adapt.... to bullshit

Did I say it was perfect ?

On the other hand, did you review it when Esteban and I proposed a fix after having spending days fixing it ?

i don't remember, maybe i did, can you point to issue?

https://pharo.fogbugz.com/default.asp?7329& (and I will not point how convenient is it now to have an issue tracker) Ben

Ben

...

...

...

Maybe it's because I have been through a couple of Pharo version with auto completion disabled because it was a pain :D

Ben

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

Guys, should you take your fight private in the office and get us a blog post or something? 2013/4/5 Benjamin <benjamin.vanryseghem.pharo@gmail.com>

On Apr 5, 2013, at 8:12 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 5 April 2013 14:38, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:

...

I personally solve that by disabling auto popup :) And it fits in what Doru said.

I have to hit ctrl space to pops up completion, and here, I know that I am in completion mode, so pressing enter is not breaking my workflow.

Moreover, usually when I see people using completion, it's highly a lost of time. the basic case is instead of fully typing 'asString', they type 'as', wait 3 seconds, press arrow down 20 times, and finally accept. This is for me so strange :)

Haha.. exactly. Now imagine that you were used it for a while and was quite effective with it and get used to it. And then, suddenly it stopped working, and when it came back, and you so happy that you can use it now, you found that now it inserting bullshit every time you trying to do something. Yes, in that case best option would be to disable it completely and do not annoy "highly adaptive" guys with your inability to adapt.... to bullshit

Did I say it was perfect ?

On the other hand, did you review it when Esteban and I proposed a fix after having spending days fixing it ?

Ben

...

...

Maybe it's because I have been through a couple of Pharo version with auto completion disabled because it was a pain :D

Ben

-- Best regards, Igor Stasenko.

Benjamin Van Ryseghem-2 wrote

Moreover, usually when I see people using completion, it's highly a lost of time. the basic case is instead of fully typing 'asString', they type 'as', wait 3 seconds, press arrow down 20 times, and finally accept.

That's why I have enter-to-accept disabled and delay ~ 0. I just type until the completion is the first suggestion and then tab. Or, for commonly repeated things like MetaC configs, now that we have partial matches, I can type "Conf", <tab>, "ofM", <tab> instead of ConfigurationOfMySpecialProjectWithExtraDescriptiveName and save myself much time and aggravation :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Apr 4, 2013, at 7:02 PM, Diego Lont <diego.lont@delware.nl> wrote:

...

On 4 April 2013 15:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

really? please, add an issue in the tracker and submit a slice, as everybody else.

calm down, we're just discussing here. I provided code here intentionally for nay-sayers like you to try it and to check if it not breaks something else (your workflow).

Esteban,

Having a new Browser in Pharo 2.0 is a big change. Everyone needs to get used to it. And I agree it is probably a good thing. But … there are some things that worked better in OB that I don't want to loose. There are a lot of people annoyed by how it works now…. but I think the mailing list is about exchanging arguments not about deciding. So I do not like that you try to end the discussion by shouting: the defaults will not change. So here I will add a new argument.

I'm not closing the discussion. I'm just pointing that the reasons why we took that decision remains more relevant than your argument. And also I'm pointing that you have the settings to adapt to your desired behavior. Finally, I also pointing that if there is something bad or a feature not present (like the coexistence of tab and enter), there is always room to improvement :)

Your argument about other languages is a valid point, but only holds if Smalltalk is similar as other languages. Why does this "enter" annoys me? Because in some cases it replaces my code by garbage. At least when I type a method invocation that does not exist yet, it replaces it by an existing method. And this is repeatable. So when you go back (using backspace and typing it again, because it also adds before the things I typed) and the press enter again, it does the same replacement. So there is a difference here between smalltalk and other languages. When I do test-driven development (that I do a lot), I first write my test, invoking a lot of methods that do not exist yet. I do not do this in another language, because my environment isn't good enough then.

A feeble argument too. We are not talking about a language but about a language's IDE (and yes, I know that Pharo, as any other smalltalk is language+IDE, and you cannot separate them). The IDE should help the developer. The defaults should help the newcomers, and the settings should be available for power users to adapt the IDE to their preferred ways to do things. So, now... I know that completion is working bad, but the "enter" issue is not the problem. I can point several other problems: 1) the most important: the answers are not accurate, and not even close. Yes, it returns symbols starting with your entry, but they are not context aware (the old completion was doing a better job by just arranging results and presenting first the latest things you entered) 2) It offers completions in bad places (like appearing after you put colon and before letting you press space) 3) Some times it changes code intead inserting it, or inserts it in bad places. 4) There are some options users desire that are not present. So... your feedback is valuable, of course, and many many times you are right. But in this case I still thing you are just wrong, and your solution is use the settings. cheers, Esteban

On Apr 4, 2013, at 12:00 PM, Diego Lont <diego.lont@delware.nl> wrote:

So I also want the defaults changed: tab should complete my smalltalk code, not enter.

defaults will not change... you will need to change your personal settings (as described some mails before) Esteban

Goubier Thierry wrote

I'm one of the guys which change his personal settings on any new 2.0 image... To turn auto completion off.

There has been a *lot* of work on completion as 2.0 has evolved. There are also many settings. If you're turning it totally off, but use it in other systems, please tell us how you would ideally like it to work and what you feel is missing. For myself, I find the following settings to be close to perfect: NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100. The only thing I was missing (but is less important now that I disabled enter-to-accept) is promoting an exact match to the top of the list, and matches starting with the typed characters next, followed by matches that contain the substring (but not at the beginning). ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp4... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

+ 1

For instance i am still clueless, why 'enter' is default for autocompletion, and disabling it and enabling 'tab' simply doesn't works. That leaves me with the only option: keep using 'enter' for autocompletion, if i ever want to use it. We have to fix that.

I have no idea why tab does not work.