[racket] Highlighting in DrRacket

DrRacket uses highlighting in a lot of unconventional ways to call
attention to different things.  Overall this is a win, I think, but
because you aren't just using out-of-the-box toolkits there are a number
of places that there is unexpected or even confusing behaviour.  I was
planning to write up one of them today when I noticed that I had *four*
that fell under the banner of "confusing non-standard highlighting
behaviour" on my list.  (My list: I'm keeping a little list of
Racket-related things I want to write about here, and writing them up as
time permits.  Perhaps you've noticed. :)

The first three of these are actual problems that have specifically
confused my (intro-level) students.  The fourth is one that aggravates
*me*.


First, the orange-on-black highlighting.  This is used to indicate code
that hasn't been tested (or, more specifically, expressions that were
parsed but weren't evaluated even once during the last Run).  For the
week or two before we really talked about testing our code, I said to
disregard it, and then when we talked about testing I was able to say
how to make it go away (and that they should do so).  The problem is,
there are two ways to write check-expects.  One is with computed answers:

  (check-expect (soph-by-creds? 35) true)
  (check-expect (soph-by-creds? 27) false)

The other is to provide the computation itself:

  (check-expect (soph-by-creds? 35) 
		(and (>= 35 28) (< 35 59)))
  (check-expect (soph-by-creds? 27)
		(and (>= 27 28) (< 27 59)))

I actually have a bunch more to say about that (I've got it on the
list), but for now I'll just note that in the above code, the expression
(< 27 59) is orange-on-black highlighted for reasons that are perfectly
clear to me but hard to explain to intro students who've only just
learned boolean truth tables and haven't seen short-circuiting.  I
*think* that saying that anything inside a check-expect shouldn't get
the orange-on-black treatment would fix this.


Second, the black-on-pink highlighting.  This is how DrRacket indicates
code that may or may not be the location of a syntax error.  I'm aware
that this aspect of the editor is an active area of research, so I won't
comment on *what* is getting pinked.  The problem here is that the pink
goes away while you're looking at it.  I can make some guesses as to why
you might have made the pink highlighting time-out, but I can attest
that it's very annoying to be having a student narrate a problem, or to
be discussing a problem with them, and have the thing I'm referring to
just unhighlight itself.  I then have to re-run everything, which is
a bit annoying, and then kill any of the big-bangs that have been run
within the definitions, which is more annoying, and then we've
completely lost our train of thought.  Which is frustrating *and*
annoying.

I'd prefer if there were a "clear error highlighting" button somewhere,
for people that want to get rid of the pink, and it doesn't disappear
based only on time passing.  (I don't have any problem with it going
away due to editing the file.)


Third, the black-on-grey highlighting.  This is what Racket does to
indicate the S-expression that your cursor is next to.  I have witnessed
dozens of students try to cut or copy as if the grey-highlighted text is
selected.  They get confused as to why those options are greyed out in
the context menu, and it's not just an "oh, forgot *again*" reaction,
they literally do one of those back-me-out things where they click
someplace else to clear all the highlighting, then (as they see it)
re-highlight the area in question, never understanding why it didn't
work before but works now.

A fix to this may well be to consider a grey-highlighted expression to
be selected, and provide its contents to the system clipboard if someone
presses ^X or ^C or selects "cut" or "copy" from the context menu.  It
feels a little weird to a computer veteran to suggest that, but I can't
really see any downside, honestly.  (And quite a few upsides.)


Finally, the pink-on-blue highlighting that marks a true selection.
In every other program on multiple OSes that I have tried this on, if I
double-click and then drag or triple-click and then drag, it does
highlight the word or line/paragraph (respectively) at first, but then
the drag extends the selection.  In DrRacket, it just locks in at the
originally-selected ident or line.  It'd be nifty if double-click-drag
caused select-whole-words behaviour and triple-click-drag caused
select-whole-lines, but I'd settle for the drag just extending the
selection on an individual-character basis (just like a regular
click-drag).  Or is there some downside to this?

-- 
-=-Don Blaheta-=-dblaheta at monm.edu-=-=-<http://www.monmsci.net/~dblaheta/>-=-
If you tied buttered toast to the back of a cat and dropped
it from a height, what would happen?