Reorder repl init to occur after debugger init #1950
Conversation
|
LGTM, the relevant issue has to be mentioned in the commit message |
cider.el
Outdated
| (cider--check-required-nrepl-version) | ||
| (cider--check-clojure-version-supported) | ||
| (cider--check-middleware-compatibility) | ||
| (cider--debug-init-connection) | ||
| ;; cider-repl-init evals code. if enlighten mode is on, eval requires the |
There was a problem hiding this comment.
`cider-repl-init'
if `enlighten-mode' is on
|
In the interest of robustness we might also add some check in the enlighten init code to determine whether it can be enabled properly or not. That's not essential for sure, but would be nice to have. |
dpsutton
force-pushed
the
feature/reorder-jack-in
branch
2 times, most recently
from
8ce7112 to
ef47c0f
Compare
|
Don't forget about the changelog entry. |
dpsutton
force-pushed
the
feature/reorder-jack-in
branch
from
ef47c0f to
264eaa3
Compare
|
Ah so sorry. Got that updated. In regards to your thoughts about checking that enlighten mode can actually run yet, did you want that to be on the elisp side or the clojure side? |
Elisp. |
|
So I put the inhibition in and "undid" the reorder. Read the commit message and see if you agree. If so, I think we are ready to squash and merge. Also, in the related issue, I thought this was going to be much worse. I was thinking that the startup tasks were spread throughout the codebase, but that was just the two session creation points (tooling and regular). That made me think all the initialization happened at random points. I was happy to be misinformed on that point. |
|
👍 I love the new approach. No idea why this wasn't my initial suggestion, as it's clearly the natural way to solve this problem. |
…ization When initializing the repl, we ask what namespace we are in by evaling code, eg (eval "(str *ns*)"). However, enlighten mode hijacks eval messages in the middleware and uses the debugger which causes an error if the debugger is not yet initialized, ie, in `cider-repl-init`. So we inhibit this feature. The reason I am doing this let binding rather than just reordering is that reordering is brittle and doesn't convey that this order is very important. While its kinda gross that we are dynamically altering this variable several call stacks up, this is a very special case right at startup and not complicated logic during the principal use of CIDER.
dpsutton
force-pushed
the
feature/reorder-jack-in
branch
from
8d251b4 to
7ff6f50
Compare
|
Swuashed and commit message cleaned up a little. I think it's ready to merge. |
|
👍 |
When initializing the repl, we ask what namespace we are in by evaling code,
eg (eval "(str ns)"). However, enlighten mode hijacks eval messages in the
middleware and uses the debugger on them which causes an error if the debugger
is not yet initialized.
#1947
make test)M-x checkdocwarnings