>> I've seen behaviour that convinces me there is a bug in the kernel
>> in use on my bwtwo-console machine.  (Specifically, in the
>> RASTERCONSOLE code for shifting part of a line left.)

> I have verified the behaviour on two IPC boxes (bwtwo with
> RASTERCONSOLE).  Both are running 1.6 ROMs though AFAIK, this should
> *not* affect the problem (?)

Not if you're using RASTERCONSOLE.  The bwtwo is too dumb for the
problem to be due to the ROMs leaving it mis-set-up.

> Note, however, that I have also noticed the behaviour when *SHIFTING
> RIGHT* as well as left!

It's probably some common piece of code.

> So, for example, type "asdfghjkl" on the command line.  [...]
> However, if you use ARROW_LEFT to move cursor to the middle of the
> text and then try to delete, the character is deleted *but* the
> characters to the right of the cursor get "smeared" as they are
> shifted to the left to reflect the missing character.

This may or may not happen, depending on your shell.  My shell does the
deletion by reprinting all the characters after the deletion (it does
this primarily to be as close to terminal-type-independent as
possible).  Only if it does a delete-character operation
(insert-character too, apparently) will you get smearing.

> Note that it appears that you have to have a few characters to the
> right of the repositioned cursor for this to be noticed

Your shell is probably doing some optimizing and realizing it takes
fewer characters printed to just retype what's to the right of it,
then.  (This is a fairly standard optimization.)

> Note that in any of these cases, ^R reveals that the correct
> characters are present on the line -- just the glyphs are distorted!

Yes, it's strictly a display problem.

>> The description you've given so far is consistent with the behaviour
>> I've seen.

This is still true.

>> Now, whether there is also a similar bug in some ROM versions, I
>> don't know; I've seen no behaviour that makes me think so.  [...]

> From the OFW prompt, there doesn't (?) appear to be a way to move the
> cursor to the left *in* the command line

Emacs-style works for me (^B, ^F, ^E, ^A, etc).

I've had a brief look at the rasterconsole code.  It seems that the
problem is that rasops_copycols assumes character cells are
byte-aligned and multiples of 8 bits wide.  This fails for many fonts
on the bwtwo.  (I suspect much of the rest of the file has similar
problems.)  However, I don't see why this would cause the observed
misbehavior...I'll look at it in more detail sometime.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B