[plt-scheme] DrScheme now rewrites opening square brackets, too

On Wed, Apr 12, 2006 at 01:14:23PM -0500, Robby Findler wrote:
> At Wed, 12 Apr 2006 07:28:27 -0400, Richard Cobbe wrote:

> > Is there a way to tell DrScheme that, in this one instance, I really
> > want an open square bracket?  Something like C-q [ in Emacs, for
> > instance.  (This may actually work already; I haven't tried this out.)
> 
> There isn't anything like that yet. I'm not sure what the right
> keystroke should be. control-q doesn't work because that's quit, under
> windows.
> 
> My best thought is control-[ but, as Eli pointed out offlist, it isn't
> something you'd just try randomly if you were guessing.
> 
> Any other ideas? (also, it should be something that works for the
> closing parens too.)

Why does it need to work for the closing parens?  Won't those
automatically match the opening paren/brace/bracket?

I don't have any firm ideas about keystrokes; I'll have to play around
to see what's available.  I'm specifically not wedded to the C-q prefix;
I was just using that to give an example of what I was talking about.

> > In addition to the cases you mentioned, Robby, I tend to use square
> > brackets to group things that are not themselves applications or special
> > forms:
> > 
> >     (provide/contract [f (integer? . -> . integer?)]
> >                       [g (integer? string? . -> . char?)])
> > 
> >     (hash-table ['key value] ['key-2 value-2] ...)
> 
> I've added provide/contract, but hash-table seemed a little too generic
> at least for now, so I didn't add that one.

That's fine -- as I say, I'll often define my own macros where this use
of braces makes sense.  It's clearly not reasonable to expect DrScheme
to intuit that from the macro definitions (without more programmer
annotations, at least), so if we miss a couple of rarely-used macros
from MzLib, that's OK by me.  I figured that a C-q-like solution would
be more general, if slightly less convenient to the programmer.

(And I'm not at all convinced that the kind of programmer annotation I
mentioned above is a good thing.  Though it *might* be possible to do
that in a very light-weight way, from the programmer's perspective: cue
off the brace/paren distinction in the macro's patterns.  'Course,
that'll probably only work for macros defined in the current module.)

Richard