[rfk-dev] bugs

[Tim Allen]

On Sun, Oct 28, 2012 at 08:37:19AM -0700, Peter A. H. Peterson wrote:
> 1. I think one quit key is enough, say, q. We can make both Q and q
> work without explicitly listing both cases. The long list of escaping
> keys seems excessive and makes the intro screen kind of wordy. Also, I
> think that ^C can be implied.

I'm happy for there to be just one quit key mentioned in the
documentation, but I don't see why we couldn't acknowledge other obvious
attempts to quit (supporting multi-character sequences like ":q" or C-x
C-c is probably too much effort for too little payoff).

> 2. I don't like how "In Glorious Color" stays in the status line
> until you touch the first NKI. It kind of breaks the spell for me,
> because it's not status -- but there it is, masquerading as one! 

It feels like this is the sort of message that should go on the
title-screen, or on the top line beside the version and NKI count,
rather than as a status message.

> 3. I'm actually not sure how I feel about having the NKI messages in
> color -- I'm not sure it's a UI enhancement. Some colors are great for
> NKI color variety but I find a little harder to read. And I find the
> color changes to be a little distracting a la #2 above.

I like that it obviously relates the message to the NKI you just
touched, but it's inconsistent: while the NKIs have a random colour, and
are randomly bold-or-not, the messages seem to always be displayed
not-bold. On some terminals, this makes the messages display in
a markedly different colour to the associated NKI (hello, classic VGA
palette).

> 4. I'm not sure that I like the bounded playfield. It uses up
> real-estate and is a UI change that I'm not sure anyone was asking
> for. On the other hand, it does imply a certain boundedness to the zen
> plane, which I can appreciate in that it lends clarity to the
> representation...

The RFK implementation I created, the J2ME one, has a border because my
phone's screen was too small to depict a complete playfield; I needed to
scroll the playfield, therefore I needed to draw where the boundary was
to make it obvious how far robot could actually move. 

Which is to say, I have no problem at all with the idea of a frame being
drawn around the playfield.

> and implies that field won't resize given a larger window.

Turns out, this isn't actually the case: if you resize the terminal
larger than the original size, the border gets drawn around the new,
larger size, even though the NKIs are all clustered within the original
boundaries, and even though robot can't venture into the new space (he
gets stuck at the old edge).

One other minor thing I noticed while figuring out how the
bold-attribute worked in the new codebase: one of Eric's changes was to
change the way EMACS keybindings were represented in the source, from
"char literal minus 64" to defining an actual CTRL() macro. This is
great, but the old comment ("Subtracting 64 makes it a control command")
is still present.


Tim.