Open dcolascione opened 1 month ago
Hi Daniel,
I was working on dREPL this week and just pushed some changes (this probably causes a conflict with your PR, sorry about that), in particular there is new option drepl-ipython-config
which allows to add settings from Emacs.
Your suggestion is something different, of course, and it makes sense, but I would prefer a more direct implementation that doesn't load the "terminal" part of IPython. I guess the key is the class PyFileConfigLoader
defined in traitlets package.
For your reference, this is a discussion I had about configuration files vs. configuration injected by the editor: https://github.com/astoff/comint-mime/issues/24
I'm less interested in an Emacs-centric IPython than I am in a regular IPython that just happens to integrate better with Emacs than one running inside shell- or term-mode. It doesn't make sense to me to configure Emacs IPython one way and every other kind of IPython another way. Sure, you could close this gap by manually reimplementing the configuration loading (and other startup, like banner printing) logic from regular IPython, but why would you? It's chasing a moving target. Using the existing startup code from IPython works fine, and the IPython source suggests that even non-terminal editors are supposed to use the Application and associated IPython bootstrappers.
Also, regarding the above comment, it seems fine for IPython hosts to inject settings they need to operate correctly, but they should layer these settings on top of the usual IPython initialization, not replace it.
Yes, I see where you are coming from (I only really use IPython from Emacs, so my requirements are simpler).
As I see it, there are two kinds of configuration options for IPython: one is about how the interpreter itself (do you want automagic, etc.) and the other is UI-specific (keybindings, how to display graphics, etc.). The latter for sure needs "injected configuration", so that's why I did it. For the first kind, it would be nice indeed to read the usual configuration file.
Instead of creating an interactive shell class instace ourselves, go through launch_new_instance and tell it the class to use. This way, startup behavior loads the same files and init scripts that the regular program does.