Emacs bug

[Kevin B. Theobald <THEOBALD@MIT-XX.ARPA>]

I have a consistently reproducable bug somewhere in EMACS or the connections
(XX, ROLM) when I run it on a Z-29.

The text below is in <THEOBALD>BUG-SCREEN.TXT


.   pic_append_transformation \↓:(argnum)
.  en
.  sv pic_new_transforms \∪pic_transforms
.  sr pic_transforms
.  nr pic_offset_x pic_offset_x+(ll*∞pic_units_per_inch)/2000
.  nr pic_offset_y pic_offset_y+((pl-(pic_top+pic_bottom)/2)*∞pic_units_per_inch)/1000
.  nv indent
.  nv rindent
.  nv ll ll+100	γ Kludge to avoid those annoying "10m over" error messages
----------------------------------------------------------------------
.sr pic_args
.fr argnum nargs-1 4 -1
.pic_a_xfation \↓:(argnum)
.en
.sv pic_new_xfs \∪pic_xfs
.sv pic_xfs
.nr pic_ox pic_ox+(ll*∞pic_units_per_inch)/2000
.nr pic_oy pic_oy+((pl-(pic_top+pic_bottom)/2)*∞pic_units_per_inch)/1000
.nv indent


It was originally generated in 2-window mode, but that is irrelevant; the
dashed line is text, not a window divider.  Go into EMACS and read in the
file.  Go to the fifth line (with ^U^N) and out to the second word (with
^U^F^F^F).  Now delete the word (with ^U12^D).  The word "pic_offset_x"
goes away as desired.  Now hit ^Y.  Instead of the original line I see
something like

.  nr pic_ot$ eY2  pic_offset_x+(ll*∞pic_units_per_inch)/2000

(That is the most common result, but there are others.  Also, it happens
elsewhere and the result seems to depend on where I am on the screen.)

Of course, it corrects itself when I type ^L, but its still annoying,
probably ups the load on the lines (with all the ^L-ing I have to do) and
is really annoying when I use MINITS at peak hours.

Could you please take a look at this problem.

					- Kevin Theobald
-------