[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: Bug In "Edit Footnote" Function?



 Dear SysOp:

 Thanks for your msg #10042. I've tried the fix you suggest, appending func JC
(Jump_over_Cursor) to func EditFootnote EF. I also duplicated the .KBD
assignment on F11 in addition to my standard Ctrl-F3; and when I had the
presence of mind to remember, I used F11 instead of my auto-habit key. At
first I thought JC helped; but at length, after two days of intensive editing
of text that contains many many footnotes duly edited, I conclude (sadly) that
there is no change. About 60% of the time, when I edit a footnote, I close the
edit window and end up on a different footnote number. A few rules seem to
hold. First, it never happens if I make no change whatsoever to the
pre-existing footnote, but merely open it and read it. Second, if I open &
*extensively* edit (add or delete a *lot* of text in) a pre-existing footnote,
the error occurs about 99% rather than 60% of the time. Third, the frequency
of the error increases as I work down through the document, editing higher and
higher footnote numbers.  Fourth, I haven't tried WZ mode, never _use_ WZ, so
-More-
don't know the behavior there; only know WG "Draft" mode.

 My ancient habit has been to use func EF both to open & to close a footnote
window. I notice that Xy4 instructs you to close with Shift-F1, which XY4.KBD
codes as "YD,XD". But that doesn't help either. An intractable bug!

 In the meantime, this is the stopgap kludge I'm using -- I run it (from U2)
off my customary EF key, nn=NOJM,2,.,e,f,Q2 -- thus:

 {{5ef}} Stop func EF from jumping around!
 <1>>EF 
 YD XD BN jmp Q2 <>>

 Works like a charm.  (You might want to reassign S/G 100.) Note that the
above routine contains a workaround for another longstanding problem, often
complained of to Billerica, namely that JuMPs are intermittently unreliable (it
reminds me of the early days of DOS and XyWrite, when sometimes you'd land in
the wrong 64K segment). So I incorporate a loop that won't let the bloody
routine EXit unless it performs an accurate JuMP -- I found that it really
needed this, because JMP errors were very common -- indeed, this may be a clue
to the nature of the entire problem.

 Let me know when you have a legit fix. Thanks for checking this out.