Steve Youngs <youngs(a)xemacs.org> wrote:
|--==> "JJ" == Jerry James <james(a)xemacs.org>
JJ> I'm seeing what Norbert is seeing. It is as though the
first RET you
JJ> type gets stuck in a pipe somewhere, then the next keypress makes the
JJ> RET take effect, as well as processing that next keypress.
That's only half the problem, it's also processing that RET as LFD
(which runs `eval-print-last-sexp' in scratch).
Aha, so it has something to do with EOL encodings! It looks like a TTY
has coding system 'undecided, at least on startup. Take a look at the
code at the top of convert_eol_convert, in file-coding.c. In
particular, look at the
if (data->actual == EOL_AUTODETECT)
part, which is taken initially. Basically, you have a race here. If
you type a C-j before a RET, then you take the branch on line 3144 of
current CVS, which sets data->actual to EOL_LF. On the other hand, if
you type a RET before a C-j, then you take the branch on line 3149 and
data->actual is set to EOL_CR. This matters because of the branch on
if (data->actual == EOL_LF || data->actual == EOL_AUTODETECT || (str->eof))
If you take the branch, data is copied unchanged with Dynarr_add_many.
If you don't, then you do RET->LFD translations in the block in lines
3183 to 3210.
This kind of autodetection may make sense for files, but it clearly
doesn't make sense for TTYs. We should set the TTY to the correct
coding system right away, instead of leaving it to blind chance whether
C-j or RET happens to get pushed first. Unfortunately, I don't actually
know how to do that at the moment....