Regarding reference to commercial-emacs/xjupyter

[liudvikasakelis]

I would like to suggest rephrasing the reference to commercial-emacs/xjupyter which is prominently featured at the beginning of README. Currently, it looks like it's being suggested as an alternative to EIN, as it's right after a listing of EINs various shortcomings.

commercial-emacs/xjupyter currently does not run on mainline Emacs as it relies on mode-overlay, a feature implemented only in a fork commercial-emacs/commercial-emacs and to my knowledge, not planned for merging into mainline Emacs. xjupyter also doesn't support .ipynb format.

I strongly believe that above shortcomings make xjupyter essentially unusable as EIN replacement to absolute majority of potential users, I would even call it a distraction to less technically knowledgeable. Therefore I strongly suggest at least a change of phrasing, to make its experimental nature more clear. To repeat, its usage would require the user to compile a fork of Emacs, compile xjupyter from source, to then end up without .ipynb support.

[bjodah]

I guess it's up to @millejoh to decide, personally I don't mind if @dickmao want to advertise his project, he has been maintaining EIN for several years, and I think it's reasonable that he get some advertisement space. But I do agree that it could be clarified a bit (I see that commit says "product promotion" so that is clear), it would perhaps be well served by subsection title and clarification, and perhaps moved towards the end of the README?

I see that the README says that ein has been sunset. I don't know, I find ein useful, I use it on a ~weekly basis, and it's a way for me to collaborate with non-emacs colleagues. I typically install notebook using pip install "notebook<7" "jupyter_server<2", and then access the server using the browser, before attempting to login using ein. (there is some race condition with tornado and/or the emacs websocket library that I haven't been able to find, so sometimes I get a 403 and need to redo the whole thing)...

[dickmao]

xjupyter is not the killer app that will bring the 100 or so emacs users worldwide to Commercial Emacs, but every little bit counts if we've any hope of moving mainline emacs to a more ethical development model.

[liudvikasakelis]

I can't comment on what will finally turn the tide towards Commercial Emacs.

From a Jupyter users perspective, I think the following deficiencies in xjupyter make it qualitatively inferior to EIN:

• no .ipynb support - agree that format has flaws, but also the only standard
• no (exposed) way to connect to remote Jupyter servers
• again, the separate Emacs one has to compile from source.

I appreciate the work @dickmao has done for EIN and elsewhere (I'm one of the 100 converts), but xjupyter I don't see as deserving such a spotlight. At least it's dishonest to pile on EIN's issues with undo , of all things, and not a peep on much larger omissions in xjupyter.

Perhaps this could be best addressed in xjupyter's own repository?