Happy New Year to all. Let's make it great one. This is intended as reply to Robin Dunn's excellent post: "Your mission, should you choose to accept it. The essence of Robin's 'mission impossible' is:
"So here is your challenge and your mission impossible, should you choose to accept it: Create a code editor that will pry emacs and its 25-year-old nearly dead technology out from under my fingers." As a thought experiment, I would like to ask, suppose we waved a magic wand and produced a complete (whatever that means) Python (swig?) wrapper for Emacs: the *real* Emacs. Would that be what Robin wants? If not, why not? In particular, what is the "25-year-old nearly dead technology" to which Robin refers. Is it elisp? Is it the c implementation? Something else? In other words, suppose we could access all of Emacs *itself* from Python. Would that be sufficient? Here is where I am coming from. I spent over a year putting an emacs minibuffer in Leo. This was time well spent, and not just because it gave Leo new features. The biggest win was being able to think in terms of Emacs-like commands. I have lost track of the times that being able design at the level of do-this, do-that, do-another-thing has clarified my thinking. So I am a huge fan of Emacs's design. Furthermore, Emacs is a *platform*, similar to Java, wxWidgets, tkinter, etc. But this platform is optimized for editing! It's hugely popular, it's very fast, and just about everything that anyone has ever wanted exists as an Emacs mode. So maybe the idea of giving Emacs a set of python wrappers is more than just a thought experiment? It would be a new playground for me: I could add Leo stuff to Emacs and stop trying to do what Emacs already does so well. But don't these remarks apply more or less to every developer on pyxides? What do you think, Amigos? Edward
