New Text Completion suggestions
Locked
12
12
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? |
Re: New Text Completion suggestions
|
|
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? > |
Re: New Text Completion suggestions
|
|
In reply to this post by Henrik Sperre Johansen
On 2012-08-22, at 20:22, Henrik Sperre Johansen <[hidden email]> 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... |
Re: New Text Completion suggestions
|
|
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 <[hidden email]> wrote: > > On 2012-08-22, at 20:22, Henrik Sperre Johansen <[hidden email]> 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" |
Re: New Text Completion suggestions
|
|
In reply to this post by Camillo Bruni-3
On 23.08.2012 13:00, Camillo Bruni wrote:
> On 2012-08-22, at 20:22, Henrik Sperre Johansen <[hidden email]> 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 - 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 |
Re: New Text Completion suggestions
|
|
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 |
Re: New Text Completion suggestions
|
|
In reply to this post by Tudor Girba-2
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 <[hidden email]> 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 <[hidden email]> wrote: >> >> On 2012-08-22, at 20:22, Henrik Sperre Johansen <[hidden email]> 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" > |
Re: New Text Completion suggestions
|
|
In reply to this post by Henrik Sperre Johansen
On 2012-08-23, at 15:05, Henrik Sperre Johansen <[hidden email]> 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... |
Re: New Text Completion suggestions
|
|
In reply to this post by Camillo Bruni-3
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 |
Re: New Text Completion suggestions
|
|
In reply to this post by Camillo Bruni-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>> >>> On 2012-08-22, at 20:22, Henrik Sperre Johansen <[hidden email]> 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" |
Re: New Text Completion suggestions
|
|
So you're saying modifiable keyboard shortcuts are a bad design?
On 2012-08-23, at 16:04, Tudor Girba <[hidden email]> 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.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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>> On 2012-08-22, at 20:22, Henrik Sperre Johansen <[hidden email]> 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" > |
Re: New Text Completion suggestions
|
|
In reply to this post by Henrik Sperre Johansen
Doru 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. +1 Stephan |
Re: New Text Completion suggestions
|
|
In reply to this post by Henrik Sperre Johansen
Camillo wrote:
>So you're saying modifiable keyboard shortcuts are a bad design? Yes. That is to say, using them outside of developing a good set of key bindings (possibly for each language/keyboard). We need them to get to this consistent set. Options could be on the level of vi/wordstar/emacs style. Stephan |
Re: New Text Completion suggestions
|
|
On 2012-08-23, at 19:50, Stephan Eggermont <[hidden email]> wrote: > Camillo wrote: >> So you're saying modifiable keyboard shortcuts are a bad design? > > Yes. > > That is to say, using them outside of developing a good set of > key bindings (possibly for each language/keyboard). We need them > to get to this consistent set. Options could be on the level of > vi/wordstar/emacs style. I see 3 versions here, I add vim, BOOM flamewar :D. so no options, is no option, forget it... whenever there will be an emacs keybinding set, I will bribe people until I have a corresponding vim set :D |
Re: New Text Completion suggestions
|
|
(a bit orthogonal)
i don't understand why we cannot have own, consistent set which is good for us? vim, emacs.. why this is so important ? Those editors were not written for editing smalltalk code in mind.. they are best suited for big, hundreds lines of code, files.. while something like that in our case is an exception rather than norm. So, why some people striving for having same keys as there? Just because they get used to them? Seriously vim? A modal editor which is invented for editing files on obscure terminals, where you don't even have a cursor keys on keyboard? I pass.. Just give me a decent editor with good cursor navigation, selection and undo/redo/find/replace, that's all i need. -- Best regards, Igor Stasenko. |
Re: New Text Completion suggestions
|
|
On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <[hidden email]> wrote: (a bit orthogonal) better use sets which are already extremely familiar than invent yet another set. to those of us who use these editors (and we are legion) these sets have long become almost subconscious to use.
why this is so important ? Those editors were not written for editing they're the two most popular editors of their type. lots of people use them for other languages without IDE support. They provide convenient power features such as pattern replacement. Not often I find myself filing out Smalltalk code and editing it with vim (sadly I've never learned emacs).
while something like that in our case is an exception rather than norm. best, Eliot |
Re: New Text Completion suggestions
|
|
On 24 August 2012 01:19, Eliot Miranda <[hidden email]> wrote:
> > > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <[hidden email]> wrote: >> >> (a bit orthogonal) >> i don't understand why we cannot have own, consistent set which is good >> for us? >> vim, emacs.. > > > better use sets which are already extremely familiar than invent yet another > set. to those of us who use these editors (and we are legion) these sets > have long become almost subconscious to use. > i know that.. i also came to squeak from outside.. but as we say in Ukraine: don't enter others sanctuary with own code(set of rules). >> why this is so important ? Those editors were not written for editing >> smalltalk code in mind.. >> they are best suited for big, hundreds lines of code, files.. > > > they're the two most popular editors of their type. lots of people use them > for other languages without IDE support. They provide convenient power > features such as pattern replacement. Not often I find myself filing out > Smalltalk code and editing it with vim (sadly I've never learned emacs). > why it is so important to have it there.. But then, i don't understand, why most of editors i know never had emacs/vim key bindings as option? Are they completely stupid? Huh? So, you know, if we follow that logic.. hey we don't have a unix command line.. so maybe we should add an option: either workspace or command line? and then introduce nice terminal emulation with prompt, users and .bashrc .. ahh.. what the hell.. lets replicate whole unix environment.. imagine how many happy users will join us then! -- Best regards, Igor Stasenko. |
Re: New Text Completion suggestions
|
|
In reply to this post by Eliot Miranda-2
Igor, as usual your true object-oriented thinking helps us see a better path...
We need a customized UI interaction for Smalltalk, instead of asking for TEXT editors devised for a different setup. What's missing is a Smalltalk method shape(morph, etc...), highly customized for editing/navigating statements written in the Smalltalk syntax. ( unless you want to code the methods using the workspace.....) We can still preserve cmd-c for copy, and cmd-v for paste...IMO it's not about inventing a new set of keyboard shortcuts, but more about manipulating objects at the right level of abstraction. Saludos, Fernando On Fri, Aug 24, 2012 at 1:40 AM, Igor Stasenko <[hidden email]> wrote: > On 24 August 2012 01:19, Eliot Miranda <[hidden email]> wrote: >> >> >> On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <[hidden email]> wrote: >>> >>> (a bit orthogonal) >>> i don't understand why we cannot have own, consistent set which is good >>> for us? >>> vim, emacs.. >> >> >> better use sets which are already extremely familiar than invent yet another >> set. to those of us who use these editors (and we are legion) these sets >> have long become almost subconscious to use. >> > > i know that.. i also came to squeak from outside.. > but as we say in Ukraine: don't enter others sanctuary with own > code(set of rules). > >>> why this is so important ? Those editors were not written for editing >>> smalltalk code in mind.. >>> they are best suited for big, hundreds lines of code, files.. >> >> >> they're the two most popular editors of their type. lots of people use them >> for other languages without IDE support. They provide convenient power >> features such as pattern replacement. Not often I find myself filing out >> Smalltalk code and editing it with vim (sadly I've never learned emacs). >> > me too.. i never learned emacs. So, maybe i am completely ignorant and can't see > why it is so important to have it there.. But then, i don't > understand, why most of editors i know > never had emacs/vim key bindings as option? Are they completely stupid? Huh? > > So, you know, if we follow that logic.. hey we don't have a unix command line.. > so maybe we should add an option: either workspace or command line? > and then introduce nice terminal emulation with prompt, users and .bashrc .. > ahh.. what the hell.. lets replicate whole unix environment.. imagine > how many happy users will join us then! > > -- > Best regards, > Igor Stasenko. > |
Re: New Text Completion suggestions
|
|
In reply to this post by Igor Stasenko
On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote:
> On 24 August 2012 01:19, Eliot Miranda <[hidden email]> wrote: > > > > > > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <[hidden email]> wrote: > >> > >> (a bit orthogonal) > >> i don't understand why we cannot have own, consistent set which is good > >> for us? > >> vim, emacs.. > > > > > > better use sets which are already extremely familiar than invent yet another > > set. to those of us who use these editors (and we are legion) these sets > > have long become almost subconscious to use. > > > > i know that.. i also came to squeak from outside.. > but as we say in Ukraine: don't enter others sanctuary with own > code(set of rules). > > >> why this is so important ? Those editors were not written for editing > >> smalltalk code in mind.. > >> they are best suited for big, hundreds lines of code, files.. > > > > > > they're the two most popular editors of their type. lots of people use them > > for other languages without IDE support. They provide convenient power > > features such as pattern replacement. Not often I find myself filing out > > Smalltalk code and editing it with vim (sadly I've never learned emacs). > > > me too.. i never learned emacs. So, maybe i am completely ignorant and can't see > why it is so important to have it there.. But then, i don't > understand, why most of editors i know > never had emacs/vim key bindings as option? Are they completely stupid? Huh? Typing is like playing a musical instrument. A good typist does not look at the keyboard, and is not consciously aware of the individual keys and motions of his or her fingers. Once you learn to play a musical instrument, the mind goes beyond the mechanical motions, and your thoughts and creativity occur without conscious awareness of fingering positions. A pianist is not "better than" a banjo player, and a saxophone is not better than a guitar. This is why key bindings are important. Our brains and our fingers just work that way. If you can play a saxophone and edit in emacs, then you may not be comfortable communicating with a guitar fretboard or a vi editor. Personally, I am a mediocre guitarist and vi user, and sadly I never learned emacs or piano ;) > > So, you know, if we follow that logic.. hey we don't have a unix command line.. > so maybe we should add an option: either workspace or command line? > and then introduce nice terminal emulation with prompt, users and .bashrc .. > ahh.. what the hell.. lets replicate whole unix environment.. imagine > how many happy users will join us then! Ack! Pfft! What a horrible idea: http://wiki.squeak.org/squeak/6023 ;) Dave |
Re: New Text Completion suggestions
|
|
On 24 August 2012 02:25, David T. Lewis <[hidden email]> wrote:
> On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote: >> On 24 August 2012 01:19, Eliot Miranda <[hidden email]> wrote: >> > >> > >> > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko <[hidden email]> wrote: >> >> >> >> (a bit orthogonal) >> >> i don't understand why we cannot have own, consistent set which is good >> >> for us? >> >> vim, emacs.. >> > >> > >> > better use sets which are already extremely familiar than invent yet another >> > set. to those of us who use these editors (and we are legion) these sets >> > have long become almost subconscious to use. >> > >> >> i know that.. i also came to squeak from outside.. >> but as we say in Ukraine: don't enter others sanctuary with own >> code(set of rules). >> >> >> why this is so important ? Those editors were not written for editing >> >> smalltalk code in mind.. >> >> they are best suited for big, hundreds lines of code, files.. >> > >> > >> > they're the two most popular editors of their type. lots of people use them >> > for other languages without IDE support. They provide convenient power >> > features such as pattern replacement. Not often I find myself filing out >> > Smalltalk code and editing it with vim (sadly I've never learned emacs). >> > >> me too.. i never learned emacs. So, maybe i am completely ignorant and can't see >> why it is so important to have it there.. But then, i don't >> understand, why most of editors i know >> never had emacs/vim key bindings as option? Are they completely stupid? Huh? > > Typing is like playing a musical instrument. A good typist does not look > at the keyboard, and is not consciously aware of the individual keys and > motions of his or her fingers. Once you learn to play a musical instrument, > the mind goes beyond the mechanical motions, and your thoughts and creativity > occur without conscious awareness of fingering positions. A pianist is not > "better than" a banjo player, and a saxophone is not better than a guitar. > people asking to add piano keys to saxophone here, because they're good at playing piano. What i would really like is ask the guys who made new shortcuts for nautilus is to spend a bit of extra effort and create a printable shortcuts quick-sheet, so i can print it, stick before my eyes, and don't waste my time digging into menus trying to find what i need each time.. This would speed up learning process a lot. > This is why key bindings are important. Our brains and our fingers just work > that way. If you can play a saxophone and edit in emacs, then you may not be > comfortable communicating with a guitar fretboard or a vi editor. > > Personally, I am a mediocre guitarist and vi user, and sadly I never learned > emacs or piano ;) > >> >> So, you know, if we follow that logic.. hey we don't have a unix command line.. >> so maybe we should add an option: either workspace or command line? >> and then introduce nice terminal emulation with prompt, users and .bashrc .. >> ahh.. what the hell.. lets replicate whole unix environment.. imagine >> how many happy users will join us then! > > Ack! Pfft! What a horrible idea: > http://wiki.squeak.org/squeak/6023 > > ;) > > Dave > > -- Best regards, Igor Stasenko. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |