[Pharo-project] New Text Completion suggestions
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. Cheers, Henry PS: AlphaBlendingCanvas suggested for 'aB'... really?
Thanks henrik Thanks thanks thanks :) Stef On Aug 22, 2012, at 8:22 PM, Henrik Sperre Johansen wrote:
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE.
Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it.
Cheers, Henry
PS: AlphaBlendingCanvas suggested for 'aB'... really?
On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE.
Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it.
maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, so everybody is happy
PS: AlphaBlendingCanvas suggested for 'aB'... really? for me, clearly yes, substring matching is exactly then important when you don't fully remember the selector name. But again, adding an option here will make both sides happy...
I think an option would only add to the confusion. Please replace the option with one decision. If some do not like it, they can shout and the designer can take the input into account. But, it's the designer that decides. Cheers, Doru On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE.
Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it.
maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, so everybody is happy
PS: AlphaBlendingCanvas suggested for 'aB'... really? for me, clearly yes, substring matching is exactly then important when you don't fully remember the selector name. But again, adding an option here will make both sides happy...
-- www.tudorgirba.com "Every thing has its own flow"
no options, this what options are for. you can decide on a default. and then change the options. we live in a multidimensional world. it's the same thing with using ENTER instead of TAB to accept completions. I and Igor for instance strongly prefer ENTER, whereas other people like you don't like that... now we can start a swiss democracy over that and decide in 100 years whether we should support ENTER or not. OR we simply add an option, both sides happy! On 2012-08-23, at 14:13, Tudor Girba <tudor@tudorgirba.com> wrote:
I think an option would only add to the confusion. Please replace the option with one decision. If some do not like it, they can shout and the designer can take the input into account. But, it's the designer that decides.
Cheers, Doru
On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE.
Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it.
maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, so everybody is happy
PS: AlphaBlendingCanvas suggested for 'aB'... really? for me, clearly yes, substring matching is exactly then important when you don't fully remember the selector name. But again, adding an option here will make both sides happy...
-- www.tudorgirba.com
"Every thing has its own flow"
On 23.08.2012 15:40, Camillo Bruni wrote:
no options, this what options are for. you can decide on a default. and then change the options. we live in a multidimensional world.
it's the same thing with using ENTER instead of TAB to accept completions. I and Igor for instance strongly prefer ENTER, whereas other people like you don't like that... now we can start a swiss democracy over that and decide in 100 years whether we should support ENTER or not. OR we simply add an option, both sides happy! To me, same argument as in the other post applies; How often do I tab after typing a character? Not very often. When coding, I tab usually only to indent before starting to type, not to align text succeeding other text on a line. How often do I use enter after typing a character? Whenever I want to split a multi-argument function call over multiple lines. How often enter is an annoyance thus depends on how often I've already used the autocomplete to finish the argument name :) (And even less if menu would close when you've manually typed in a sole suggestion)
Overall, either option at worst introduces minor disruption to normal code editing. Left and right keys are on a whole other level, imho... Cheers, Henry
I definitely do not adhere to this point of view, but I think I understand it well. Let's think of code design now. When you see non-object-oriented design, you go and refine. When you see conceptual duplication, you go for it and unify. Until you get a better abstraction that matches the paradigm and gestalt of the entire system. You apply rigor. That is why Pharo is getting better every day. When you see non-conforming UI, you invoke preference choice and add an option. This approach is likely to get the UI experience exactly towards where Pharo comes from code-wise. The IDE (and UI in general) requires rigor and design as well. I will keep saying it :). Cheers, Doru p.s. Regarding ENTER on completion, I have documented the reasons why it is a bad idea before: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/016413.ht... (Please note that the mail provides a list of hands-on arguments, and it does not invoke preference or taste) On Thu, Aug 23, 2012 at 3:40 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
no options, this what options are for. you can decide on a default. and then change the options. we live in a multidimensional world.
it's the same thing with using ENTER instead of TAB to accept completions. I and Igor for instance strongly prefer ENTER, whereas other people like you don't like that... now we can start a swiss democracy over that and decide in 100 years whether we should support ENTER or not. OR we simply add an option, both sides happy!
On 2012-08-23, at 14:13, Tudor Girba <tudor@tudorgirba.com> wrote:
I think an option would only add to the confusion. Please replace the option with one decision. If some do not like it, they can shout and the designer can take the input into account. But, it's the designer that decides.
Cheers, Doru
On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE.
Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it.
maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, so everybody is happy
PS: AlphaBlendingCanvas suggested for 'aB'... really? for me, clearly yes, substring matching is exactly then important when you don't fully remember the selector name. But again, adding an option here will make both sides happy...
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
So you're saying modifiable keyboard shortcuts are a bad design? On 2012-08-23, at 16:04, Tudor Girba <tudor@tudorgirba.com> wrote:
I definitely do not adhere to this point of view, but I think I understand it well.
Let's think of code design now. When you see non-object-oriented design, you go and refine. When you see conceptual duplication, you go for it and unify. Until you get a better abstraction that matches the paradigm and gestalt of the entire system. You apply rigor. That is why Pharo is getting better every day.
When you see non-conforming UI, you invoke preference choice and add an option. This approach is likely to get the UI experience exactly towards where Pharo comes from code-wise.
The IDE (and UI in general) requires rigor and design as well. I will keep saying it :).
Cheers, Doru
p.s. Regarding ENTER on completion, I have documented the reasons why it is a bad idea before: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/016413.ht... (Please note that the mail provides a list of hands-on arguments, and it does not invoke preference or taste)
On Thu, Aug 23, 2012 at 3:40 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
no options, this what options are for. you can decide on a default. and then change the options. we live in a multidimensional world.
it's the same thing with using ENTER instead of TAB to accept completions. I and Igor for instance strongly prefer ENTER, whereas other people like you don't like that... now we can start a swiss democracy over that and decide in 100 years whether we should support ENTER or not. OR we simply add an option, both sides happy!
On 2012-08-23, at 14:13, Tudor Girba <tudor@tudorgirba.com> wrote:
I think an option would only add to the confusion. Please replace the option with one decision. If some do not like it, they can shout and the designer can take the input into account. But, it's the designer that decides.
Cheers, Doru
On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE.
Suggestions: - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it.
maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, so everybody is happy
PS: AlphaBlendingCanvas suggested for 'aB'... really? for me, clearly yes, substring matching is exactly then important when you don't fully remember the selector name. But again, adding an option here will make both sides happy...
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
On Aug 24, 2012, at 10:05 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote:
So you're saying modifiable keyboard shortcuts are a bad design?
not necessarily but I prefer to have a good default :) so that I do not have to do it.
+1 for configurations +1 for a good default
Stef
On 24 Aug 2012, at 10:07, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On Aug 24, 2012, at 10:05 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 23, 2012, at 4:24 PM, Camillo Bruni wrote:
So you're saying modifiable keyboard shortcuts are a bad design?
not necessarily but I prefer to have a good default :) so that I do not have to do it.
+1 for configurations +1 for a good default
Yes, +agree But also, +igor Smalltalk editing is not big text shuffling, we can and should do what is best for ourselves.
On 23.08.2012 13:00, Camillo Bruni wrote: > On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: > >> Is it just me who finds the new text completion resulting from O/E merge insufferably disruptive? >> Whenever I've been editing in an existing method, and try moving back/forward using arrow keys, instead of moving the cursor, it opens a browser on the completion suggestion for whatever I'd just finished writing (if I go right), or does jack squat (if I try moving left)... >> Ironically, clicking the text editor anywhere BUT the completion dialogue leaves the window open, and starts suggesting for whatever you type at the cursors new location, while clicking ON any part of the popup-pane CLOSES it. >> moving cursor with the mouse (not that you could before), only thing that works is pressing escape, which is a natural key to reach for whenever you've finished typing a word, no? >> Not to mention, if there is only one suggestion, and that suggestion you've already typed in completely, it DOES NOT CLOSE. >> >> Suggestions: >> - Don't hijack the arrow keys (at least not left/right) for autocomplete-popup functionality. >> - Close the fracking dialogue if the only suggestion it has is _exactly what is already typed_ >> - Handle mouse-clicks on a suggestion by selecting it, clicks anywhere else in the texteditor by closing it. > maybe I have some time at ESUG to fix this. The solution is to add options for these behaviors, > so everybody is happy You mean someone might LIKE - keep getting suggested something they just typed? - that the window doesn't close when they've clearly change context by moving the cursor? - that the window doesn't respond to mouse input to it by selecting what you clicked on, but rather closing? Cheers, Henry
On 23.08.2012 14:41, Henrik Sperre Johansen wrote:
You mean someone might LIKE - keep getting suggested something they just typed? - that the window doesn't close when they've clearly change context by moving the cursor? - that the window doesn't respond to mouse input to it by selecting what you clicked on, but rather closing?
Cheers, Henry To explain my thinking: To me, the autocomplete popup is essentially a menu that opens before I might feel like using it. As such, I expect it to behave similiarly to a menu. With regards to mouse input, that means the two last gripes above. With regards to keyboard input, I never explicitly opened it, thus I expect it to not interfere with normal operation in the widget. To me, using left and right keys are normal operations in a text editor after inserting characters, while tabbing or pressing up and down less so (in other words I think it's ok those operate the popup without explicitly focusing it first).
What do you really lose by not hijacking left and right? The ability to view definition of the first entry in the list with a single key-press. IMHO, that's not too bad, I'd expect the 3-press down->up->right sequence to do that, or alternately a two-press sequence with new shortcut for explicitly switching focus, then right. Cheers, Henry
On 2012-08-23, at 15:05, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 23.08.2012 14:41, Henrik Sperre Johansen wrote:
You mean someone might LIKE - keep getting suggested something they just typed? - that the window doesn't close when they've clearly change context by moving the cursor? - that the window doesn't respond to mouse input to it by selecting what you clicked on, but rather closing?
Cheers, Henry To explain my thinking: To me, the autocomplete popup is essentially a menu that opens before I might feel like using it. As such, I expect it to behave similiarly to a menu.
yes, I strongly agree, sadly it is not implemented as a menu, and I don't have time to fix this :D
With regards to mouse input, that means the two last gripes above. With regards to keyboard input, I never explicitly opened it, thus I expect it to not interfere with normal operation in the widget. To me, using left and right keys are normal operations in a text editor after inserting characters, while tabbing or pressing up and down less so (in other words I think it's ok those operate the popup without explicitly focusing it first).
What do you really lose by not hijacking left and right? The ability to view definition of the first entry in the list with a single key-press. IMHO, that's not too bad, I'd expect the 3-press down->up->right sequence to do that, or alternately a two-press sequence with new shortcut for explicitly switching focus, then right.
I completely understand that this is a bothering feature :P but I like it and thus I want to keep it. So I'll add a default setting which will not hijack left/right, but I can enable it for myself... to be honest, I don't like the current implementation too much, but TextEditor is such a mess that I don't have the energy and time to change it in a decent way...
participants (6)
-
Camillo Bruni -
Esteban Lorenzano -
Henrik Sperre Johansen -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba