upstream merge #9
Conversation
Previously, if the inferior process buffer is not being shown in any window, one would have to manually bring it up after evaluating an expression in order to see the results. With this change, the inferior process buffer will always be displayed after evaluating an expression so that one can alway see the results without having to bring up the inferior process buffer.
Always display inferior process buffer after evaluation
Update docs
I am very sorry... I just typed a typo...
Fixed typo
This closes #24.
Add GPL3 license
defining our adjust-window-size-function
|
Seems like quite a bit of things have diverged since I made my small fork, and that merging won't be trivial. I'm definitely not against trying to better align with a new upstream version, but I'm not sure I will have time to follow this closely any day soon. If you could help try to resolve some of the merge-conflicts, I could probably more easily review this PR and see if I think the changes makes sense for this project too :) |
|
Indeed this seems like a quite difficult merge to make. I may try to help with a couple of merges, but i don't think have the required knowledge in this code base / elisp for this task. But yeah, this would be a great effort so we can continue merging with the upstream getting new features / bugfixes :) |
Update key bindings
|
GitHub says there’s conflicts which needs to be resolved. Are you looking into that? 🙂 |
Allow to send multi-line string
Fixes to run under Emacs 27.1
Fix regression when sending multi-line string
|
I really appreciate the endurance here. This is the PR which comes back from the dead and just refuses to die 😄 
That said, like I've already mentioned, there are merge conflicts and I cannot merge this PR without those getting resolved. Can you take a look? |
Add tests for multiline statements, run tests in github workflow
|
@josteink I don't quite understand what you expect from me here. I sent PRs to the upstream project, they were merged there without conflict. Anything that happens in a fork from upstream is not something I can be aware of (and I wasn't until you pinged me here), nor is it something I should be concerned with simply because it exists. It looks like this PR automatically tracks the master branch from upstream, so of course it's a moving target, and upstream changes can become conflicts here. Maybe that was a mistake? |
would be nice to have some of those bugfixes merged into this fork.
@josteink can you check if there is anything useful?