You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
People continue to report symptoms like issue #344. In some cases it
turned out people needed to update to the latest racket-mode. However
at least a couple users on very recent versions reported still seeing
the problem intermittently.
So:
- Simplify code paths by relying on sentinels to do cleanup when the
process is deleted or closed.
- Rename racket--repl-ensure-buffer-and-process to racket--repl-start,
and, it is an error to call it when (racket--repl-live-p) is true.
- Rather than setting racket--cmd-proc back to nil, leave it set to
the last value, and use things like `process-status` determine if it
is 'open. Provide a little helper for this: racket--cmd-open-p.
- Wait to start command connect; eliminate racket--cmd-connecting-p
state variable.
Until we believe the Racket backend has finished starting up and the
TCP server would be listening, there is really no point in starting
to attempt to connect. Ideally we could know this from a process
sentinel, but there is no appropriate event for a comint buffer
process. Instead use a comint output filter function to detect first
output, e.g. the Welcome to Racket banner. This uses run-at-time to
schedule racket--cmd-connect-attempt (should not do directly from a
filter function, IIUC). As a result, there is no longer any
racket--cmd-connect-start function. Now, we only try to connect to
the command server when we first start the REPL process. If the
command connection dies thereafter, but the REPL is still alive?
Tough beans, users will need to restart the REPL process.
Also as a result, I convinced myself that the
racket--cmd-connecting-p flag/guard is no longer necessary. Which is
good, because it is tricky to make all the code paths manage that
properly. I _think_ I finally got that right in a WIP commit. But
it's fragile. Some other change, someday, could break this again.
Better users get a "can't talk to command server" error, and need to
restart the REPL, than have heisenbugs and reports thereof.
Note: As before, racket--cmd-connect-attempt will run-at-time itself
to retry: We wait until the TCP command server could
_possibly_ be ready -- but it's not necessarily ready yet.
Although it will probably succeed on the first try, in fact
I've seen it occasionally take two attempts while testing this
on a laptop/OS that does the startup very quickly.
- racket-repl-exit: Use comint-kill-subjob when command server dead
- Add defcustom racket-command-startup.
- When nil (default): We do not try to start the REPL or the
command server automatically; instead we give the user an error
message explaining they need to (re)start racket-repl-mode.
- When a positive number, we do try to start things automatically
and we wait that number of seconds for the command server to
connect. While waiting, we remind the user they can C-g to quit
waiting.
0 commit comments