When I'm using ein to run a python jupyter notebook, the major-mode variable is just "ein:notebook-multilang-mode" which makes it ambiguous what the current language is. I have elisp that only activates when major-mode is python-mode so it doesn't currently work for Python inside ein notebooks. Just checking for "ein:notebook-multilang-mode" doesn't seem right because that could also be Julia or some other language.

What should I be checking instead?


Unfortunately, it seems like things don't quite work the way you would like them to.

ein:notebook-multilang-mode is simply a major mode. That means a lot of things, but here it basically defines fontification (i.e. "syntax highlighting"). You can see that from the source code, available via help (C-h f ein:notebook-multilang-mode). The docstring for my version of ein (likely outdated) also happens to state,

A mode for fontifying multiple languages.

What this means is that each cell will receive different highlighting based on the language. This is different from each cell providing a different environment according to the language.

The challenge is that Emacs generally works on a per buffer basis. That's the most common and natural unit to work with from an implementation standpoint. The modes which dictate the behaviors for Python, R, or Markdown need a way to know when and how to apply the rules (such as indentation, identifying keywords, interaction with an interpreter, etc.) that make, say, R mode different from Python mode.

It's natural to envision an ein cell also being aware of the corresponding language mode. (This is what I understand your question to be about.) However, from an implementation perspective, it's not clear how that would be accomplished. It's an interesting problem. You have to answer questions like, "How will binding X work if the behavior might need to differ on line 14 versus line 355?" For example, if you have both R and Python cells, a binding might reach out to an interpreter. How would a given cell know which interpreter to contact? Are instances between Python cells associated?

All of this could be accomplished; it just doesn't seem like ein has done so1. There are packages such as MmmMode and Mu Ma Mo whose goals are multiple modes operating at the sub-buffer level. Maybe one of those could be used to implement such functionality.

I'd be remiss, however, if I didn't mention Org babel. It provides the ability to do literate programming, with multiple, concurrent languages and the ability to specify which interpreter (i.e. "kernel") to use for each block (i.e, "cell"), as well as export to HTML, PDF, Latex, etc. Each source block can be expanded to a separate buffer whose mode is automatically set to the appropriate language. You can also "tangle" (extract) the code blocks into a single .py or .r file. And so on. I understand if you're bound to Jupyter Notebooks, though.

1 Maybe you could implement it. That would be a cool contribution!

  • Somewhere ein knows and must have stored in a variable or accessible via a function how to fontify the current cell though. That's all I really need, my code does not actually depend on any other functionality from the mode being present. – Joseph Garvin Feb 17 '20 at 20:38
  • Does org Babel have the same concept of keeping a running interpreter with your data loaded in the background and where evaluating code inside cells runs it in that interpreter? Or keep an incrementing count each time you run a cell that it keeps next to the cell so you can tell what stuff you evaluated recently and what you didn't? Can I evaluate plot commands and have them show up as inline images? The notebook is doing a lot so I'm wary of something that only looks equivalent of the surface. – Joseph Garvin Feb 17 '20 at 20:40
  • To your first reply, I agree. It seems likely there is something like that. I don't really know the ein library. I would query the available functions/variables with C-h f and C-h v. Maybe you'll get lucky and find something clearly named. Otherwise, in the source code, ein-cell.el might yield 'taters. You could always ask the developers directly, too. – Lorem Ipsum Feb 18 '20 at 14:56
  • To your second, yes, dunno, but probably, and yes. A decent example (now several years old) is from @John Kitchin. If you decide to try it, I've found the docs reasonably clear. Hopefully, that will be your experience. youtube.com/watch?v=fgizHHd7nOo&t=453s – Lorem Ipsum Feb 18 '20 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.