Richard Russell wrote: ↑
Fri Jul 10, 2020 10:17 pm
How repeatable is the issue of the 8queens program thinking the escape key has been pressed when it hasn't? Does it happen every time you run that program, irrespective of what you did beforehand? Is it only that one program that seems to do it, or do others? Is there any pattern to it at all?
Oddly enough, it seems always to detect escape at line 460, having printed, or started to print, solution 23. Oh no, hang on, solution 27 one time at least. But always the same line:
Code: Select all
460 IF Y%=8 THEN PRINTTAB(58,29)" "
and nothing to do with a history of pasting, or whether it's the first program run or others have been run previously.
Programs hanoi and speed and snake and 15puzzle run fine. chess seems to be running OK too.
(Edit: I just checked an older version from 28 June, and that doesn't have this problem. The versions from 7th and 10th of July do have it.)
There must be a solution, I feel. I see the ncurses library has a parameter ESCDELAY which defaults to 1 second - surely too large a default for our purposes but it shows that the same kind of logic is needed.
Specifies the total time, in milliseconds, for which ncurses will await a character sequence, e.g., a function key. The default value, 1000 milliseconds, is enough for most uses. However, it is made a variable to accommodate unusual applications.
I run emacs in a console window, and always have, and of course emacs needs to read both the escape key as a discrete input and also escape sequences. I don't know how it does it. vi will also need to do it (if it's the kind of vi which allows cursor movement using the cursor keys.) I do see that the vi mode inside emacs uses a timeout - it is of course written in lisp, but here's the comment block (emphasis mine):
Code: Select all
;; So we try to recognize those events that correspond to the escape key and
;; turn them into `escape' events (same as used under GUIs). The heuristic we
;; use to distinguish the two cases is [b]based, as usual, on a timeout[/b], and on
;; the fact that the special ESC=>escape mapping only takes place if the whole
;; last key-sequence so far is just [?\e], i.e. either we're still in
;; read-key-sequence, or the last read-key-sequence only read [?\e], which
;; should ideally never happen because it should have been mapped to [escape].