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.html (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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >>> >>> On 2012-08-22, at 20:22, Henrik Sperre Johansen >>> <[email protected]> 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"
