[Pharo-project] New Text Completion suggestions
tudor at tudorgirba.com
Thu Aug 23 16:04:46 CEST 2012
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 :).
p.s. Regarding ENTER on completion, I have documented the reasons why
it is a bad idea before:
(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 at 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 at 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.
>> On Thu, Aug 23, 2012 at 1:00 PM, Camillo Bruni <camillobruni at gmail.com> wrote:
>>> On 2012-08-22, at 20:22, Henrik Sperre Johansen <henrik.s.johansen at 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.
>>>> - 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...
>> "Every thing has its own flow"
"Every thing has its own flow"
More information about the Pharo-project