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

[ EXEC SUMMARY: control-prefixing a paren now avoids drscheme's cleverness ]

At Wed, 12 Apr 2006 15:12:22 -0400, Richard Cobbe wrote:
> 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?

Just that sometimes someone might want to put in unmatched parens at
some point (for example: they might be about to put the thing into a
string or something). It just seems like we should have consistent set
of "don't be clever" keystrokes.

> 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.

I've put in 

 control-[
 control-]
 control-}
 control-)

as new keystrokes that just put the raw parens in, ignoring context.

> > > 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.

We definitely need an escape, in any case.

> (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.)

If we had that kind of information available in the editor we could
really do a *lot*. Too bad we don't (yet).

Robby