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 fi
1. In Pharo if you expand a keyword message like #replaceAll:with:
the cursor is set already to the first argument (so one can continue
typing) but to enter the second argument one has to move left using
arrow keys "manually".
How often you have to move left is dependent on the size of
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 ar
On Aug 23, 2012, at 9:20 AM, Torsten Bergmann wrote:
> 1. In Pharo if you expand a keyword message like #replaceAll:with:
> the cursor is set already to the first argument (so one can continue
> typing) but to enter the second argument one has to move left using
> arrow keys "manually".
>
On 2012-08-22, at 20:22, 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 ope
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 wrote:
>
> On
On 23.08.2012 13:00, Camillo Bruni wrote:
On 2012-08-22, at 20:22, 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,
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 y
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
On 2012-08-23, at 15:05, Henrik Sperre Johansen
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?
>> -
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
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
So you're saying modifiable keyboard shortcuts are a bad design?
On 2012-08-23, at 16:04, Tudor Girba 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.
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
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 s
On 2012-08-23, at 19:50, Stephan Eggermont 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
(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 o
On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko 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 (
On 24 August 2012 01:19, Eliot Miranda wrote:
>
>
> On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko 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
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 s
On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote:
> On 24 August 2012 01:19, Eliot Miranda wrote:
> >
> >
> > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko wrote:
> >>
> >> (a bit orthogonal)
> >> i don't understand why we cannot have own, consistent set which is good
> >> for us?
>
On 24 August 2012 02:25, David T. Lewis wrote:
> On Fri, Aug 24, 2012 at 01:40:54AM +0200, Igor Stasenko wrote:
>> On 24 August 2012 01:19, Eliot Miranda wrote:
>> >
>> >
>> > On Thu, Aug 23, 2012 at 3:57 PM, Igor Stasenko wrote:
>> >>
>> >> (a bit orthogonal)
>> >> i don't understand why we can
.
From: Camillo Bruni
To: Pharo-project@lists.gforge.inria.fr
Sent: Friday, 24 August 2012, 1:37
Subject: Re: [Pharo-project] New Text Completion suggestions
On 2012-08-23, at 19:50, Stephan Eggermont wrote:
> Camillo wrote:
>> So you're saying modifiable keyboard short
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.
Stef
On Aug 24, 2012, at 10:05 AM, Stéphane Ducasse
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 configuratio
Camillo the system should be like that
- user can define to use a map
vim
emacs
customizable
+ pharo
for Pharo we need to have a good default.
To me the remarks of henrik make sense:
the pop up should not st
On 24 Aug 2012, at 10:07, Esteban Lorenzano wrote:
>
> On Aug 24, 2012, at 10:05 AM, Stéphane Ducasse
> 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 goo
what Doru says makes sense... but in the other side, all the IDEs in the world
use enter for completion.
We should also welcome newcomers... so, I vote for enter or better, a
configuration.
Esteban
On Aug 24, 2012, at 10:12 AM, Stéphane Ducasse
wrote:
> Camillo the system should be like th
EstebanLM wrote
>
> what Doru says makes sense... but in the other side, all the IDEs in the
> world use enter for completion.
> We should also welcome newcomers... so, I vote for enter or better, a
> configuration.
>
+1 Good default
+1 "presets" (vi, emacs, other dialects, etc).
The first t
> what Doru says makes sense... but in the other side, all the IDEs in the
> world use enter for completion.
may be we are talking about difference change proposition/select one.
> We should also welcome newcomers... so, I vote for enter or better, a
> configuration.
30 matches
Mail list logo
