On Jan 3, 4:40 pm, Christopher Barker <[EMAIL PROTECTED]> wrote: > > Something like callElispFunctionByName(name-of-elisp-function) ? > > well, no. It's a start, but it really means that you have to now and > work with elisp to work with the editor component. I was thinking more > along the lines of how you wrap C++ or ObjC, so that: > > (name-of-elisp-function, parameter1, parameter2) > > becomes: > > name-of-elisp-function(parameter1, parameter2)
Yes, this is better than what I proposed. If I am not mistaken, pymacs shows that issues relating to types of arguments can be resolved satisfactorily. Let's step back a bit. In some sense, what I 'really' would like is Emacs written in Python :-) That's never going to happen, because Emacs is written in elisp and Emacs developers and users like what they have. But supposing we use pymacs, or something like it, we can get what you propose: programming Emacs with Python. That may be quite useful: we can 'pretend' that Emacs is, in fact, written in Python. Let's step back a bit farther. The reason I originally proposed creating Python wrappers for Emacs was so that python code would control Emacs, not the other way around. Indeed, the following appears at: http://webpages.charter.net/edreamleo/emacs.html "A clarification is needed about two-way communication between Python and lisp scripts: in truth, Python scripts can call the Pymacs.lisp function only if the Python script was invoked from emacs. Otherwise, calling Pymacs.lisp will hang the process making the call." In short, wrapping Emacs means the following to me (at present): 1. I want to be able to invoke & control Emacs from a python 'master' script, not the other way around. 2. I want to execute Emacs elisp functions using Python conventions, as Chris suggests. Edward
