Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatibility with dap-ui-repl-mode #32

Open
jumper047 opened this issue Nov 22, 2022 · 11 comments
Open

Incompatibility with dap-ui-repl-mode #32

jumper047 opened this issue Nov 22, 2022 · 11 comments

Comments

@jumper047
Copy link

I encountered an issue with shx-mode and dap-mode REPL - on "enter" press it inters "^M" instead of sending string to interpreter. This issue also was opened in dap-mode repo - emacs-lsp/dap-mode#518

@riscy riscy changed the title Incompatibility with dap-mode REPL Incompatibility with dap-ui-repl-mode Dec 22, 2022
@riscy
Copy link
Owner

riscy commented Dec 22, 2022

This seems to be similar to #25, where another mode wants to have control of how input is sent.

(More than you want to know: the current heuristic (which unfortunately doesn't address this issue) is that shx-mode will not auto-activate unless RET is bound to comint-send-input (i.e. default behavior) but I think I should also have it check the value of comint-input-sender to ensure shx is a good neighbor.)

The reason why toggling shx off doesn't fix this is because shx tries to set comint-input-sender back to its default value, i.e. (setq-local comint-input-sender (default-value 'comint-input-sender)). But this "default" is not the same as the value set by dap-ui-repl-mode.

@jumper047
Copy link
Author

BTW maybe it's worth to add a variable like shx-ignored-modes?

@riscy
Copy link
Owner

riscy commented Dec 22, 2022

You're probably right. I've been putting that off because I'm hesitant to maintain a laundry list of incompatible modes (mostly REPLs) but maybe I should give in.

@jumper047
Copy link
Author

I suppose your heuristics is good, I thought about variable as workaround for cases like that - to ease temporarily fixing issue until proper fix will be released

@jumper047
Copy link
Author

Another thing - I think there is another non-expected behavior here, because the issue still exists even if shx mode was disabled. Should advice be deactivated on disabling mode?

@riscy
Copy link
Owner

riscy commented Dec 22, 2022

Are you testing on the develop branch? (Which I appreciate, btw.)

@jumper047
Copy link
Author

Do you mean emacs dev branch or something else? If you are talking about emacs then it's yes and no - it was dev at the moment I compiled it (last spring I suppose), and I don't upgraded it since then.

@riscy
Copy link
Owner

riscy commented Dec 23, 2022

The develop branch of shx -- but I just merged the change to shx into the mainline branch, so hopefully the non-expected behavior is resolved?

@jumper047
Copy link
Author

oops, sorry, it's rather uncommon in emacs packages world:)
still not checked the fix though, sorry - real life(, but I will check it on weekend

@riscy
Copy link
Owner

riscy commented Dec 23, 2022

No problem, I appreciate you even being available to confirm. :) If you don't get a chance, that's alright too of course.

@jumper047
Copy link
Author

some time passed
Checked the fix and can confirm that it works. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants