Auto-Correct wow! Muliple corrections in the future?

Andy/Blair
>Oh, and glad you like the Auto-Correct. This is a feature I hope to grow in
>future releases.

I put this quote (from Blair) in a new message so its less hidden... as Auto
Correct is one of those extra little things that brings Smalltalk up to
date, I love it! I like your implementation - it makes the environment fun
and productive.  (Which is really good for Smalltalk - its lamented on its
basic strengths for too long - although VW does have something on save as I
recall).

Auto Correct makes me do the right things (just as refactoring makes me
simplify, auto correct temp vars makes me give things better names instead
of chaining things together. I recall someone writing - why are programmers
so stingy with variable names when then can really aid with
understandability). So future improvements are very exciting!

I've been thinking a bit about how to get auto-correct to correct multiple
variable names in one go... is this an easy one to get going (I don't mind
having a go)? I find when using TDD that I often assign a lot of things and
then have to correct them one by one - a one shot correct would be very
handy. If you have any tips I don't mind have a go.

By the way - your source code parser implementation is very good! I've been
having a play, and writing Intelli-J like corrections is actualy quite easy.
I particularly was impressed to see that message node keywords know where in
the source code they are and whether they intersect with a current range...
wow! Lots of room to write cool tools!  Recently Chris U. and I were talking
about an auto-bracketing feature... he inspired to dig a bit deeper and I
have autobracketing working and plan on sharing this after you release the
next patch... its only a few lines of code and really makes we work better.

So thanks for this feature.

Tim

"TimM" <[hidden email]> wrote in message
news:dmse36$sj2$[hidden email]...
> Andy/Blair
>>Oh, and glad you like the Auto-Correct. This is a feature I hope to grow
>>in future releases.
> ....[snip]...
> I've been thinking a bit about how to get auto-correct to correct multiple
> variable names in one go... is this an easy one to get going (I don't mind
> having a go)? I find when using TDD that I often assign a lot of things
> and then have to correct them one by one - a one shot correct would be
> very handy. If you have any tips I don't mind have a go.

If you're talking about correcting all undefined variables to be temps, then
I think that would be easy. Just enumerate the compilation errors and act on
the appropriate ones (quite similar to the logic that builds the
auto-correct menu I suppose). If you wanted to be able to it selectively, an
intermediate choice dialog would be easiest (or perhaps hold down shift for
that). Implementing multiple selections in the workspace would be not so
easy - I've been thinking about doing this using Scintilla's indicator
feature, but not got round to it.

>
> By the way - your source code parser implementation is very good! I've
> been having a play, and writing Intelli-J like corrections is actualy
> quite easy. I particularly was impressed to see that message node keywords
> know where in the source code they are and whether they intersect with a
> current range... wow! Lots of room to write cool tools!

You can thank Don Roberts and John Brant for that. Our parser is an
extension of the RB parser.

>...Recently Chris U. and I were talking about an auto-bracketing feature...
>he inspired to dig a bit deeper and I have autobracketing working and plan
>on sharing this after you release the next patch... its only a few lines of
>code and really makes we work better.

Be interested to see it.

Regards

Blair

> If you're talking about correcting all undefined variables to be temps,
> then I think that would be easy. Just enumerate the compilation errors and
> act on the appropriate ones (quite similar to the logic that builds the
> auto-correct menu I suppose).

Again - you were right, "piece of p..." springs to mind. The only thing I
noticed that was a bit unexpected was that compilation errors don't make it
easier for you to identify them - there is just a type code? E.g. 71 in the
error message table is undeclared variable - but thats a bit of thin
object???  for now I added a loose method - isUndeclaredVariable (maybe for
edge case objects like this it makes sense).

By the way - I tried to pick a license for Intelli-D that would let you guys
rip off any interesting stuff and put it in your base image.

> You can thank Don Roberts and John Brant for that. Our parser is an
> extension of the RB parser.

Don/John - not sure if you will ever you read this but - Big Thanks!  That
parser is awesome (particulary the added touches of parameters knowing if
they intersect a range...).

Tim

"TimM" <[hidden email]> wrote in message
news:dnildk$kgg$[hidden email]...
Well there is a SmalltalkParseErrorCodes pool that allows you to identify
the errors without using magic numbers. CErrUndeclared is the one you want.
I don't think I'd necessarily want to add a load of methods just to do a
value switch on every error code, it being such an unusual need, but a
judicious few could be added, particularly where multiple such codes are
involved.

>
> By the way - I tried to pick a license for Intelli-D that would let you
> guys rip off any interesting stuff and put it in your base image.
>

Thanks. There are a number of things in there we were intending to do in D6
(for example the syntax-directed bracketing which a number of people had
asked for in the past, and some other things you yourself probably suggested
during the beta) but they just didn't make the cut. Frustrating with the
infrastructure being there to support it, but we had to ship it eventually.
Some such features will doubtless appear in patches when Andy or I get bored
with something more mundane.

>...

Regards

Blairs