pymacs! :-)

[Paul Winkler]

On 08 Sep 2001 19:04:26 -0400, François Pinard <pinard at iro.umontreal.ca> wrote:
(snip)
>`lisp' is not a module, it is a special object having some Python magic
>built in it.  I may explain how it works if you are curious, but one should
>be able to use it a bit blindly, or at least, I hope so. :-)

Ah, OK. I assumed it was a module. This is interesting, and much
better than what I thought you were doing.

>> I have not seen your code
>
>If you feel audacious, it is available on request. 

I think I'll wait a bit longer - I have no especially urgent need to
extend emacs.

>There is a deep difference between a symbol and a string, in Emacs, like
>in Python, but you know this. :-) Python `lisp.f7' corresponds to the LISP
>symbol `f7', Python `"f7"' corresponds to the LISP string `"f7"'.

Yes, I see why this matters now. I thought you were writing python
functions in a lisp.py module to generate strings of lisp code; I
hadn't realized you were providing much more direct access to emacs
and just translating the names appropriately.

>I'm not utterly familiar with how `[SYMBOL]' works on the Emacs side to
>represent key-bindings, but I would guess Emacs developers made a few
>stunts for it to look good.  For what I guess these stunts are, I would
>write on the Python side:
>
>    lisp.global_set_key([lisp['M-f2']], lisp.redo)
>
>or even more tricky:
>
>    lisp.global_set_key([lisp.M_f2], lisp.redo)

I think either way would be fine.


>> >   (global-set-key "\C-xw" manglers-break-on-whitespace)
>> > [to become]
>> >   lisp.global_set_key('\x18w', lisp.manglers_break_on_whitespace)
>
>> IMHO this is a heavy burden to place on the person trying to write
>> python functions.
>
>Really?  We'll have to do something about it, then.

Yes... see below.

(explanation of control and meta codes snipped)

That's all good information, but is it really common knowledge? (I'm
serious; that's not a rhetorical question.)

My point is that emacs does not require you to know any of that to
assign keybindings. You just use the same notation that's used
throughout the emacs documentation. This makes it easy to learn, easy
to read. When I look at .el files, I know what keys they're talking
about even if I don't understand much else. It stands to reason
(to me) that pymacs should not require you to use a different
notation.

>> >Maybe it could be useful to have a service function to help writing more
>> >LISP-looking strings in Python?
>
>> Yes, that's exactly what I'm suggesting.
>
>Then this routine -- let's tentatively call it `pymacs.key()' -- and the
>convention for writing its argument, should be precisely documented.

Of course.

--PW