Small auto-complete glitch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Small auto-complete glitch

Chris Uppal-3
Something mildly inconvenient that I've just noticed.  I don't see a way around
it, so I won't raise a bug report, unless someone can think of a way.

In a workspace I have a bunch of expressions that I evaluate:

    p := ListPresenter ....
    v := p view

The I type:

    Sma

and expect to get a list of Smalltalk* stuff, instead I get nothing.  That's
because there isn't a . (dot) at the end of the previous do-it expression.  /I/
know that expression isn't related, but the parser -- understandably -- doesn't
agree.

Oh well...

    -- chris

P.S.  Hmm... maybe the auto-complete scanner could be told not to look back
past the beginning of any expression that starts in column 0 (in a workspace).
Is that doable ?


Reply | Threaded
Open this post in threaded view
|

Re: Small auto-complete glitch

Christopher J. Demers
"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...

> Something mildly inconvenient that I've just noticed.  I don't see a way
> around
> it, so I won't raise a bug report, unless someone can think of a way.
>
> In a workspace I have a bunch of expressions that I evaluate:
>
>    p := ListPresenter ....
>    v := p view
>
> The I type:
>
>    Sma
>
> and expect to get a list of Smalltalk* stuff, instead I get nothing.
> That's
> because there isn't a . (dot) at the end of the previous do-it expression.
> /I/
> know that expression isn't related, but the parser -- understandably --  
> doesn't
> agree.
...

I experienced the same issue, and found it annoying.  I just figured that I
would have to get used to separating all my workspace expressions with a
period.  If this situation could be handled more elegantly I would be happy
as well.  I am just not sure if the styler could easily handle it.

Chris


Reply | Threaded
Open this post in threaded view
|

Re: Small auto-complete glitch

Blair McGlashan
"Christopher J. Demers" <[hidden email]> wrote in
message news:[hidden email]...

> "Chris Uppal" <[hidden email]> wrote in message
> news:[hidden email]...
>> Something mildly inconvenient that I've just noticed.  I don't see a way
>> around
>> it, so I won't raise a bug report, unless someone can think of a way.
>>
>> In a workspace I have a bunch of expressions that I evaluate:
>>
>>    p := ListPresenter ....
>>    v := p view
>>
>> The I type:
>>
>>    Sma
>>
>> and expect to get a list of Smalltalk* stuff, instead I get nothing.
>> That's
>> because there isn't a . (dot) at the end of the previous do-it
>> expression. /I/
>> know that expression isn't related, but the parser -- understandably --  
>> doesn't
>> agree.
> ...
>
> I experienced the same issue, and found it annoying.  I just figured that
> I would have to get used to separating all my workspace expressions with a
> period.  If this situation could be handled more elegantly I would be
> happy as well.  I am just not sure if the styler could easily handle it.
>

Correct. The period is needed to distinguish between an identifier at the
start of a statement and a sequence of unary message sends. You're workspace
code needs to be syntactically valid for the auto-completion - and styling
for that matter - to work correctly.

I did think about assuming that a newline in a workspace terminated the
statement, but decided that was just too much of a bodge to be bearable.

Regards

Blair