GNU bug report logs -
#44818
Say "Consider switching so-long mode on" when detecting long line files
Previous Next
Reported by: Devon Sean McCullough <Devon2020 <at> jovi.net>
Date: Mon, 23 Nov 2020 12:40:02 UTC
Severity: minor
Merged with 44809
Found in version 27.0.91
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #43 received at 44818 <at> debbugs.gnu.org (full text, mbox):
Happy Thanksgiving, hackers in the USA!
Will "so long" catch spammed shells?
What if four or more consecutive ^G quits were to select a
"safe" full frame window or dialog offering a few choices,
e.g., ignore the quits and restore the saved window state,
kill the buffer, select another buffer, read the tutorial,
add overlays to appease redisplay or (eek) quit Emacs?
Would a ^G quit discard unprocessed input? Is it possible
to time out when unprocessed input languishes for > 50 ms,
in a situation where ^G quit is either ignored or fails to
put the user back in the driver's seat?
Perhaps there's no way to detect when the editor is wedged
and the user has lost control. One clue might be when the
user types ^G quit many times, but was it a sound check of
the beeper's audio output, or a frustrated user attempting
to regain control of a rogue editor?
Peace
--Devon
P.S. Some jobs involve a noticeable delay — not ok for redisplay!
(find-file-noselect "src/xdisp.c") ; 480.5 ms to read the file
(find-file "src/xdisp.c") ; 1.4 ms to display the buffer
Dead, comatose or entranced? Best show some sign of life!
E.g., tramp is slower than most remote file interfaces but
users are used it. Its progress reports should be updated
every second, either a timer or the traditional ETA.
This bug report was last modified 2 years and 302 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.