/usr/share/doc/pymacs/html/pymacs.html

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.10: http://docutils.sourceforge.net/" />
<title>Pymacs version 0.23</title>
<style type="text/css">

/*
:Author: David Goodger (goodger@python.org)
:Id: $Id: html4css1.css 7514 2012-09-14 14:27:12Z milde $
:Copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.

See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
customize this style sheet.
*/

/* used to remove borders from tables and images */
.borderless, table.borderless td, table.borderless th {
  border: 0 }

table.borderless td, table.borderless th {
  /* Override padding for "table.docutils td" with "! important".
     The right padding separates the table cells. */
  padding: 0 0.5em 0 0 ! important }

.first {
  /* Override more specific margin styles with "! important". */
  margin-top: 0 ! important }

.last, .with-subtitle {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dl.docutils dd {
  margin-bottom: 0.5em }

object[type="image/svg+xml"], object[type="application/x-shockwave-flash"] {
  overflow: hidden;
}

/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
  font-weight: bold }
*/

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title, .code .error {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

/* Uncomment (and remove this text!) to get reduced vertical space in
   compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
  margin-bottom: 0.5em }

div.compound .compound-last, div.compound .compound-middle {
  margin-top: 0.5em }
*/

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em ;
  margin-right: 2em }

div.footer, div.header {
  clear: both;
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin: 0 0 0.5em 1em ;
  border: medium outset ;
  padding: 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
  margin-top: 0.4em }

h1.title {
  text-align: center }

h2.subtitle {
  text-align: center }

hr.docutils {
  width: 75% }

img.align-left, .figure.align-left, object.align-left {
  clear: left ;
  float: left ;
  margin-right: 1em }

img.align-right, .figure.align-right, object.align-right {
  clear: right ;
  float: right ;
  margin-left: 1em }

img.align-center, .figure.align-center, object.align-center {
  display: block;
  margin-left: auto;
  margin-right: auto;
}

.align-left {
  text-align: left }

.align-center {
  clear: both ;
  text-align: center }

.align-right {
  text-align: right }

/* reset inner alignment in figures */
div.align-right {
  text-align: inherit }

/* div.align-center * { */
/*   text-align: left } */

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font: inherit }

pre.literal-block, pre.doctest-block, pre.math, pre.code {
  margin-left: 2em ;
  margin-right: 2em }

pre.code .ln { color: grey; } /* line numbers */
pre.code, code { background-color: #eeeeee }
pre.code .comment, code .comment { color: #5C6576 }
pre.code .keyword, code .keyword { color: #3B0D06; font-weight: bold }
pre.code .literal.string, code .literal.string { color: #0C5404 }
pre.code .name.builtin, code .name.builtin { color: #352B84 }
pre.code .deleted, code .deleted { background-color: #DEB0A1}
pre.code .inserted, code .inserted { background-color: #A3D289}

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

span.section-subtitle {
  /* font-size relative to parent (h1..h6 element) */
  font-size: 80% }

table.citation {
  border-left: solid 1px gray;
  margin-left: 1px }

table.docinfo {
  margin: 2em 4em }

table.docutils {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.footnote {
  border-left: solid 1px black;
  margin-left: 1px }

table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

table.docutils th.field-name, table.docinfo th.docinfo-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap ;
  padding-left: 0 }

h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
  font-size: 100% }

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="pymacs-version-0-23">
<h1 class="title">Pymacs version 0.23</h1>
<h2 class="subtitle" id="extending-emacs-with-python">Extending Emacs with Python</h2>

<blockquote>
<table class="docutils field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field"><th class="field-name">Author:</th><td class="field-body">François Pinard</td>
</tr>
<tr class="field"><th class="field-name">Email:</th><td class="field-body"><a class="reference external" href="mailto:pinard&#64;iro.umontreal.ca">pinard&#64;iro.umontreal.ca</a></td>
</tr>
<tr class="field"><th class="field-name">Copyright:</th><td class="field-body">© Progiciels Bourbeau-Pinard inc., Montréal 2003, 2008</td>
</tr>
</tbody>
</table>
</blockquote>
<div class="contents topic" id="contents">
<p class="topic-title first">Contents</p>
<ul class="auto-toc simple">
<li><a class="reference internal" href="#introduction" id="id3">1&nbsp;&nbsp;&nbsp;Introduction</a><ul class="auto-toc">
<li><a class="reference internal" href="#what-is-pymacs" id="id4">1.1&nbsp;&nbsp;&nbsp;What is Pymacs?</a></li>
<li><a class="reference internal" href="#documentation-and-examples" id="id5">1.2&nbsp;&nbsp;&nbsp;Documentation and examples</a></li>
<li><a class="reference internal" href="#other-resources" id="id6">1.3&nbsp;&nbsp;&nbsp;Other resources</a></li>
</ul>
</li>
<li><a class="reference internal" href="#installation" id="id7">2&nbsp;&nbsp;&nbsp;Installation</a><ul class="auto-toc">
<li><a class="reference internal" href="#select-emacs-and-python" id="id8">2.1&nbsp;&nbsp;&nbsp;Select Emacs and Python</a></li>
<li><a class="reference internal" href="#check-if-pymacs-would-work" id="id9">2.2&nbsp;&nbsp;&nbsp;Check if Pymacs would work</a></li>
<li><a class="reference internal" href="#install-the-pymacs-proper" id="id10">2.3&nbsp;&nbsp;&nbsp;Install the Pymacs proper</a></li>
<li><a class="reference internal" href="#prepare-your-emacs-file" id="id11">2.4&nbsp;&nbsp;&nbsp;Prepare your <tt class="file docutils literal">.emacs</tt> file</a></li>
<li><a class="reference internal" href="#porting-and-caveats" id="id12">2.5&nbsp;&nbsp;&nbsp;Porting and caveats</a></li>
</ul>
</li>
<li><a class="reference internal" href="#emacs-lisp-structures-and-python-objects" id="id13">3&nbsp;&nbsp;&nbsp;Emacs Lisp structures and Python objects</a><ul class="auto-toc">
<li><a class="reference internal" href="#conversions" id="id14">3.1&nbsp;&nbsp;&nbsp;Conversions</a></li>
<li><a class="reference internal" href="#simple-objects" id="id15">3.2&nbsp;&nbsp;&nbsp;Simple objects</a></li>
<li><a class="reference internal" href="#sequences" id="id16">3.3&nbsp;&nbsp;&nbsp;Sequences</a></li>
<li><a class="reference internal" href="#opaque-objects" id="id17">3.4&nbsp;&nbsp;&nbsp;Opaque objects</a><ul class="auto-toc">
<li><a class="reference internal" href="#emacs-lisp-handles" id="id18">3.4.1&nbsp;&nbsp;&nbsp;Emacs Lisp handles</a></li>
<li><a class="reference internal" href="#python-handles" id="id19">3.4.2&nbsp;&nbsp;&nbsp;Python handles</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#usage-on-the-emacs-lisp-side" id="id20">4&nbsp;&nbsp;&nbsp;Usage on the Emacs Lisp side</a><ul class="auto-toc">
<li><a class="reference internal" href="#pymacs-exec" id="id21">4.1&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-exec</strong></a></li>
<li><a class="reference internal" href="#pymacs-eval" id="id22">4.2&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-eval</strong></a></li>
<li><a class="reference internal" href="#pymacs-call" id="id23">4.3&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-call</strong></a></li>
<li><a class="reference internal" href="#pymacs-apply" id="id24">4.4&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-apply</strong></a></li>
<li><a class="reference internal" href="#pymacs-load" id="id25">4.5&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-load</strong></a></li>
<li><a class="reference internal" href="#expected-usage" id="id26">4.6&nbsp;&nbsp;&nbsp;Expected usage</a></li>
<li><a class="reference internal" href="#special-emacs-lisp-variables" id="id27">4.7&nbsp;&nbsp;&nbsp;Special Emacs Lisp variables</a><ul class="auto-toc">
<li><a class="reference internal" href="#pymacs-load-path" id="id28">4.7.1&nbsp;&nbsp;&nbsp;pymacs-load-path</a></li>
<li><a class="reference internal" href="#pymacs-trace-transit" id="id29">4.7.2&nbsp;&nbsp;&nbsp;pymacs-trace-transit</a></li>
<li><a class="reference internal" href="#pymacs-forget-mutability" id="id30">4.7.3&nbsp;&nbsp;&nbsp;pymacs-forget-mutability</a></li>
<li><a class="reference internal" href="#pymacs-mutable-strings" id="id31">4.7.4&nbsp;&nbsp;&nbsp;pymacs-mutable-strings</a></li>
<li><a class="reference internal" href="#timeout-variables" id="id32">4.7.5&nbsp;&nbsp;&nbsp;Timeout variables</a></li>
<li><a class="reference internal" href="#pymacs-dreadful-zombies" id="id33">4.7.6&nbsp;&nbsp;&nbsp;pymacs-dreadful-zombies</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#usage-on-the-python-side" id="id34">5&nbsp;&nbsp;&nbsp;Usage on the Python side</a><ul class="auto-toc">
<li><a class="reference internal" href="#python-setup" id="id35">5.1&nbsp;&nbsp;&nbsp;Python setup</a></li>
<li><a class="reference internal" href="#emacs-lisp-symbols" id="id36">5.2&nbsp;&nbsp;&nbsp;Emacs Lisp symbols</a></li>
<li><a class="reference internal" href="#dynamic-bindings" id="id37">5.3&nbsp;&nbsp;&nbsp;Dynamic bindings</a></li>
<li><a class="reference internal" href="#raw-emacs-lisp-expressions" id="id38">5.4&nbsp;&nbsp;&nbsp;Raw Emacs Lisp expressions</a></li>
<li><a class="reference internal" href="#user-interaction" id="id39">5.5&nbsp;&nbsp;&nbsp;User interaction</a></li>
<li><a class="reference internal" href="#key-bindings" id="id40">5.6&nbsp;&nbsp;&nbsp;Key bindings</a></li>
</ul>
</li>
<li><a class="reference internal" href="#debugging" id="id41">6&nbsp;&nbsp;&nbsp;Debugging</a><ul class="auto-toc">
<li><a class="reference internal" href="#on-the-communication-protocol" id="id42">6.1&nbsp;&nbsp;&nbsp;On the communication protocol</a></li>
<li><a class="reference internal" href="#the-pymacs-buffer" id="id43">6.2&nbsp;&nbsp;&nbsp;The <strong class="code">*Pymacs*</strong> buffer</a></li>
<li><a class="reference internal" href="#emacs-usual-debugging" id="id44">6.3&nbsp;&nbsp;&nbsp;Emacs usual debugging</a></li>
<li><a class="reference internal" href="#auto-reloading-on-save" id="id45">6.4&nbsp;&nbsp;&nbsp;Auto-reloading on save</a></li>
<li><a class="reference internal" href="#debugging-the-pymacs-helper" id="id46">6.5&nbsp;&nbsp;&nbsp;Debugging the Pymacs helper</a></li>
</ul>
</li>
<li><a class="reference internal" href="#about-and-around-pymacs" id="id47">7&nbsp;&nbsp;&nbsp;About and around Pymacs</a><ul class="auto-toc">
<li><a class="reference internal" href="#known-limitations" id="id48">7.1&nbsp;&nbsp;&nbsp;Known limitations</a></li>
<li><a class="reference internal" href="#history" id="id49">7.2&nbsp;&nbsp;&nbsp;History</a></li>
<li><a class="reference internal" href="#pymacs-and-me" id="id50">7.3&nbsp;&nbsp;&nbsp;Pymacs and me!</a></li>
<li><a class="reference internal" href="#vim-considerations" id="id51">7.4&nbsp;&nbsp;&nbsp;Vim considerations</a></li>
<li><a class="reference internal" href="#inclusion-within-emacs" id="id52">7.5&nbsp;&nbsp;&nbsp;Inclusion within Emacs</a></li>
<li><a class="reference internal" href="#speed-issues" id="id53">7.6&nbsp;&nbsp;&nbsp;Speed issues</a></li>
<li><a class="reference internal" href="#the-future-of-pymacs" id="id54">7.7&nbsp;&nbsp;&nbsp;The future of Pymacs</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="introduction">
<h1><a class="toc-backref" href="#id3">1&nbsp;&nbsp;&nbsp;Introduction</a></h1>
<div class="section" id="what-is-pymacs">
<h2><a class="toc-backref" href="#id4">1.1&nbsp;&nbsp;&nbsp;What is Pymacs?</a></h2>
<p>Pymacs is a powerful tool which, once started from Emacs, allows two-way
communication between Emacs Lisp and Python.  Pymacs aims to employ
Python as an extension language for Emacs rather than the other way
around, and this asymmetry is reflected in some design choices.  Within
Emacs Lisp code, one may load and use Python modules.  Python functions
may themselves use Emacs services, and handle Emacs Lisp objects kept in
Emacs Lisp space.</p>
<p>The goals are to write <em>naturally</em> in both languages, debug with ease,
fall back gracefully on errors, and allow full cross-recursion.</p>
<p>It is very easy to install Pymacs, as neither Emacs nor Python need to
be compiled nor relinked.  Emacs merely starts Python as a subprocess,
and Pymacs implements a communication protocol between both processes.</p>
<p>Report problems, documentation flaws, or suggestions to François Pinard:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="mailto:pinard&#64;iro.umontreal.ca">mailto:pinard&#64;iro.umontreal.ca</a></li>
</ul>
</blockquote>
</div>
<div class="section" id="documentation-and-examples">
<h2><a class="toc-backref" href="#id5">1.2&nbsp;&nbsp;&nbsp;Documentation and examples</a></h2>
<p>The main Pymacs site conveys the Pymacs documentation (you are reading
its Pymacs manual right now) and distributions:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca">http://pymacs.progiciels-bpi.ca</a></li>
</ul>
</blockquote>
<p>I expect average Pymacs users to have a deeper knowledge of Python
than Emacs Lisp.  People have widely varying approaches in writing
<tt class="file docutils literal">.emacs</tt> files, as far as Pymacs is concerned:</p>
<blockquote>
<ul class="simple">
<li>Some can go and write almost no Emacs Lisp, yet a bit is still
necessary for establishing a few loading hooks.  For many simple
needs, one can do a lot without having to learn much.</li>
<li>On the other hand, for more sophisticated usages, people cannot
really escape knowing the Emacs Lisp API to some extent, because they
should be programming-wise familiarity with what is a buffer, a point,
a mark, etc. and what are the allowed operations on those.</li>
</ul>
</blockquote>
<p>While Pymacs examples are no substitute for a careful reading of the
Pymacs manual, the contemplation and study of others' nice works may
well enligthen and deepen your understanding.  A few examples are
included within the Pymacs distribution, each as a subdirectory of the
<tt class="file docutils literal">contrib/</tt> directory, and each haviing its own <tt class="file docutils literal">README</tt>
file.  These are listed below, easiest examples first:</p>
<blockquote>
<ul class="simple">
<li>Paul Winkler's example<ul>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/Winkler.html">http://pymacs.progiciels-bpi.ca/Winkler.html</a></li>
</ul>
</li>
<li>Fernando Pérez' examples<ul>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/Perez.html">http://pymacs.progiciels-bpi.ca/Perez.html</a></li>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/contrib/Perez/">http://pymacs.progiciels-bpi.ca/contrib/Perez/</a></li>
</ul>
</li>
<li>Giovanni Giorgi's files<ul>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/Giorgi.html">http://pymacs.progiciels-bpi.ca/Giorgi.html</a></li>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/contrib/Giorgi/">http://pymacs.progiciels-bpi.ca/contrib/Giorgi/</a></li>
</ul>
</li>
<li>A reformatter for boxed comments<ul>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/rebox.html">http://pymacs.progiciels-bpi.ca/rebox.html</a></li>
<li><a class="reference external" href="http://pymacs.progiciels-bpi.ca/contrib/rebox/">http://pymacs.progiciels-bpi.ca/contrib/rebox/</a></li>
</ul>
</li>
</ul>
</blockquote>
<p>A few more substantial examples of Pymacs usage have been brought to my
attention, and are available externally (listed here in no particular
order):</p>
<blockquote>
<ul class="simple">
<li>pymdev -- A Python Emacs Development Module:<ul>
<li><a class="reference external" href="http://www.toolness.com/pymdev/">http://www.toolness.com/pymdev/</a></li>
</ul>
</li>
<li>Ropemacs -- Features like refactoring and code-assists:<ul>
<li><a class="reference external" href="http://rope.sf.net/">http://rope.sf.net/</a></li>
<li><a class="reference external" href="http://rope.sf.net/hg/rpymacs">http://rope.sf.net/hg/rpymacs</a></li>
</ul>
</li>
<li>Bicycle Repair Man -- A Refactoring Tool for Python:<ul>
<li><a class="reference external" href="http://bicyclerepair.sourceforge.net/">http://bicyclerepair.sourceforge.net/</a></li>
</ul>
</li>
<li>Emacs Freex -- A personal wiki on steroids:<ul>
<li><a class="reference external" href="http://www.princeton.edu/%7Egdetre/software/freex/docs/index.html">http://www.princeton.edu/%7Egdetre/software/freex/docs/index.html</a></li>
</ul>
</li>
</ul>
</blockquote>
<p>The QaTeX project was influenced by Pymacs, according to its author:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="http://qatex.sourceforge.net/">http://qatex.sourceforge.net/</a></li>
<li><a class="reference external" href="http://www.pytex.org/doc/index.html#eurotex2005">http://www.pytex.org/doc/index.html#eurotex2005</a></li>
</ul>
</blockquote>
</div>
<div class="section" id="other-resources">
<h2><a class="toc-backref" href="#id6">1.3&nbsp;&nbsp;&nbsp;Other resources</a></h2>
<p>You are welcome writing to or joining the following mailing list, where
there are a few people around likely to give you feedback:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="mailto:pymacs-devel&#64;googlegroups.com">mailto:pymacs-devel&#64;googlegroups.com</a></li>
</ul>
</blockquote>
<p>If you have no fear of wider crowds :-), there still is:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="mailto:python-list&#64;python.org">mailto:python-list&#64;python.org</a></li>
</ul>
</blockquote>
<p>There are other Web sites specifically about Pymacs. <a class="reference external" href="http://blog.objectsroot.com/">Giovanni Giorgi</a>
has one of them:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="http://blog.objectsroot.com/projects/pymacs/">http://blog.objectsroot.com/projects/pymacs/</a></li>
</ul>
</blockquote>
<p>There is also <cite>revised pymacs</cite>, part of the Ropemacs project:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="http://rope.sourceforge.net/ropemacs.html">http://rope.sourceforge.net/ropemacs.html</a></li>
</ul>
</blockquote>
</div>
</div>
<div class="section" id="installation">
<h1><a class="toc-backref" href="#id7">2&nbsp;&nbsp;&nbsp;Installation</a></h1>
<div class="section" id="select-emacs-and-python">
<h2><a class="toc-backref" href="#id8">2.1&nbsp;&nbsp;&nbsp;Select Emacs and Python</a></h2>
<p>The environment variable <tt class="docutils literal">PYMACS_PYTHON</tt> is usually left unset or
empty, in which case <tt class="docutils literal">python</tt> is implied.  It has the purpose of
naming the Python interpreter program to be called for starting the
Pymacs helper.  It may be set to give the full path of the executable if
the Python program exists at some location outside the program search
path.  It may also be given when the interpreter name is different,
for exemple when the Python version is part of the program name.</p>
<p>The similar environment variable <tt class="docutils literal">PYMACS_EMACS</tt> is usually left unset
or empty, in which case <tt class="docutils literal">emacs</tt> is implied.  It has the purpose of
naming the Emacs editor, yet this is only meaningful for the validation
(see next section).  For normal Pymacs usage, Emacs is launched by the
user long before Pymacs is itself started, and consequently, there
is absolutely no need to tell Pymacs which Emacs is needed.  For the
validation suite however, it may be set to give the full path of the
executable if the Emacs program exists at some location outside the
program search path.  It may also be given when the editor name is
different, for example when the Emacs version is part of the program
name, or when this is a different editor (like the value <tt class="docutils literal">xemacs</tt> to
call XEmacs).</p>
</div>
<div class="section" id="check-if-pymacs-would-work">
<h2><a class="toc-backref" href="#id9">2.2&nbsp;&nbsp;&nbsp;Check if Pymacs would work</a></h2>
<p>To know, before installing Pymacs, if it would work on your system,
try the validation suite by running <tt class="docutils literal">make check</tt>.  The suite is
fairly elementary, but nevertheless, it is able to detect some common
show stoppers.  As a convenience for those who want to quickly try
various Emacs and Python combinations, <tt class="docutils literal">make check emacs=SOME_EMACS
python=SOME_PYTHON</tt> temporarily overrides the environment variables
<tt class="docutils literal">PYMACS_EMACS</tt> and <tt class="docutils literal">PYMACS_PYTHON</tt>.  For example, <tt class="docutils literal">make check
emacs=xemacs</tt> runs the validation suite using <tt class="docutils literal">xemacs</tt> for an editor.</p>
<p>The remaining of this section may be safely be skipped, for mere Pymacs
installation.</p>
<p>I did not base the validation suite on Junit (the Python unit testing
framework is a re-implementation of it), but on Codespeak's pylib
<tt class="file docutils literal">py.test</tt>, which is much simpler, and still very powerful.  The
<strong class="code">pylib</strong> project is driven by Holge Kregel, but attracted some
Python brains, like Armin Rigo (known for Psyco, among other things --
I think his <strong class="code">lsprof</strong> has also been added to Python 2.5 under the
name <strong class="code">cProfile</strong>).  This gang addresses overdone/heavy methods in
Python, and do them better.  Even <tt class="file docutils literal">py.test</tt> is a bit more complex
that I would want, and has (or at least had) flaws on the Unicode side,
so I rewrote my own, as a simple single file.  I merely translated it
from French to English, to make it more distributable within Pymacs.</p>
<p>It has not been fruitful, trying to use Emacs stdin and stdout for
communicating expressions to evaluate and getting back results from
within the validation suite.  After some fight, I reluctantly put this
avenue aside.  Currently, the suite writes problems in files, for Emacs
to read, and Emacs writes replies in files, for the suite to check.
Busy waiting (with small sleep added in the loops) is used on both
sides.  This is all too heavy, and it slows down the suite.  Hopefully,
the suite is not run often, this is not a real problem.</p>
</div>
<div class="section" id="install-the-pymacs-proper">
<h2><a class="toc-backref" href="#id10">2.3&nbsp;&nbsp;&nbsp;Install the Pymacs proper</a></h2>
<p>Pymacs is a small package.  Putting the documentation and administrative
files aside, there is one Python file and one Emacs Lisp file to it, to
be installed in turn.  Always start with the Python file.</p>
<ul>
<li><p class="first">For the Python part</p>
<p>At the top-level of the Pymacs distribution, then execute <tt class="docutils literal">python
setup.py install</tt>.  First, the script copies a few source files while
presetting the version strings in them.  Second, it installs the
Python package through the Python standard Distutils tool.  To get
an option reminder, do <tt class="docutils literal">python setup.py install <span class="pre">--help</span></tt>.  Consult
the Distutils documentation if you need more information about this.</p>
<p>That's all to it.  To check that <tt class="file docutils literal">pymacs.py</tt> is properly
installed, start an interactive Python session and type <tt class="docutils literal">from Pymacs
import lisp</tt>: you should not receive any error.</p>
</li>
<li><p class="first">For the Emacs part</p>
<p>This is usually done by hand now.  First select some directory along
the list kept in your Emacs <strong class="code">load-path</strong>, for which you have
write access, and copy file <tt class="file docutils literal">pymacs.el</tt> in that directory.</p>
<p>If you want speed, you should ideally byte-compile this file.  To do
so, go to that directory, launch Emacs, then give the command <tt class="docutils literal"><span class="pre">M-x</span>
<span class="pre">byte-compile-file</span> RET pymacs.el RET</tt>.  If for some reason you intend
to such commands often, you could create a little script to do so.
Here is an example of such a script, assuming here that you use Emacs
and want to install in directory <tt class="file docutils literal">~/share/emacs/lisp/</tt>:</p>
<pre class="literal-block">
#!/bin/bash
cp pymacs.el ~/share/emacs/lisp/
emacs -batch -eval '(byte-compile-file &quot;~/share/emacs/lisp/pymacs.el&quot;)'
</pre>
<p>You should be done now.  To check that <tt class="file docutils literal">pymacs.el</tt> is properly
installed, return to your usual directories, start Emacs and give
it the command <tt class="docutils literal"><span class="pre">M-x</span> <span class="pre">load-library</span> RET pymacs RET</tt>: you should not
receive any error.</p>
</li>
</ul>
<p>Some features from previous Pymacs releases have been dropped:</p>
<ul class="simple">
<li>There used to be a script for installing the Emacs Lisp file.  As it
was difficult to get it right in all circumstances; the script grew
an interactive mode and lot of options.  This is just not worth the
complexity, so this script is now gone.</li>
<li>Examples were all installed automatically, but at least for some of
them, this was more pollution than help.  You may browse the contents of
the <tt class="file docutils literal">contrib/</tt> directory to learn about available examples.</li>
</ul>
</div>
<div class="section" id="prepare-your-emacs-file">
<h2><a class="toc-backref" href="#id11">2.4&nbsp;&nbsp;&nbsp;Prepare your <tt class="file docutils literal">.emacs</tt> file</a></h2>
<p>The <tt class="file docutils literal">.emacs</tt> file is not given in the distribution, you likely
have one already in your home directory.  You need to add these lines:</p>
<pre class="literal-block">
(autoload 'pymacs-apply &quot;pymacs&quot;)
(autoload 'pymacs-call &quot;pymacs&quot;)
(autoload 'pymacs-eval &quot;pymacs&quot; nil t)
(autoload 'pymacs-exec &quot;pymacs&quot; nil t)
(autoload 'pymacs-load &quot;pymacs&quot; nil t)
;;(eval-after-load &quot;pymacs&quot;
;;  '(add-to-list 'pymacs-load-path YOUR-PYMACS-DIRECTORY&quot;))
</pre>
<p>If you plan to use a special directory to hold your own Pymacs code in
Python, which should be searched prior to the usual Python import search
path, then uncomment the last two lines (by removing the semi-colons)
and replace <em class="var">YOUR-PYMACS-DIRECTORY</em> by the name of your special
directory.  If the file <tt class="file docutils literal"><span class="pre">~/.emacs</span></tt> does not exist, merely create
it with the above lines.  You are now all set to use Pymacs.</p>
<p>To check this, start a fresh Emacs session, and type <tt class="docutils literal"><span class="pre">M-x</span>
<span class="pre">pymacs-eval</span> RET</tt>.  Emacs should prompt you for a Python expression.
Try <tt class="docutils literal"><span class="pre">repr(2L**111)</span> RET</tt>.  The mini buffer should display
<cite>&quot;2596148429267413814265248164610048L&quot;</cite>. <tt class="docutils literal"><span class="pre">M-x</span> <span class="pre">pymacs-load</span> RET</tt> should
prompt you for a Python module name.  Reply <tt class="docutils literal">os RET RET</tt> (the second
<tt class="docutils literal">RET</tt> is for accepting the default prefix.  This should have the
effect of importing the Python <strong class="code">os</strong> module within Emacs.  Typing
<tt class="docutils literal"><span class="pre">M-:</span> <span class="pre">(os-getcwd)</span> RET</tt> should echo the current directory in the message
buffer, as returned by the <strong class="code">os.getcwd</strong> Python function.</p>
</div>
<div class="section" id="porting-and-caveats">
<h2><a class="toc-backref" href="#id12">2.5&nbsp;&nbsp;&nbsp;Porting and caveats</a></h2>
<p>Pymacs has been initially developed on Linux, Python 1.5.2, and Emacs
20, and currently on Python 2.5, Emacs 22.1 and XEmacs 21.5.  It is
expected to work out of the box on many flavours of Unix, MS Windows and
Mac OSX, and also on many version of Python, Emacs and XEmacs.</p>
<p>From Pymacs 0.23 and upwards, Python 2.2 or better is likely needed,
and for the Pymacs proper, I rely on testers or users for portability
issues.  However, the validation suite itself requires Python 2.4 or
better, someone might choose to contribute the back porting.</p>
<p>Pymacs uses Emacs weak hash tables.  It can run without them, but then,
complex Python objects transmitted to Emacs will tie Python memory
forever.  It should not be a practical problem in most simple cases.
Some later versions of Emacs 20 silently create ordinary tables when
asked for weak hash tables.  Older Emacses do not have hash tables.</p>
<p>The <tt class="file docutils literal">Pymacs</tt> Python package holds a single <tt class="file docutils literal">pymacs.py</tt> file
(and the mandatory <tt class="file docutils literal">__init__.py</tt>).  Programmers might elect, but
are not required, to install their own Pymacs applications either as
sub-modules or sub-packages on <tt class="file docutils literal">Pymacs</tt>.</p>
</div>
</div>
<div class="section" id="emacs-lisp-structures-and-python-objects">
<h1><a class="toc-backref" href="#id13">3&nbsp;&nbsp;&nbsp;Emacs Lisp structures and Python objects</a></h1>
<div class="section" id="conversions">
<h2><a class="toc-backref" href="#id14">3.1&nbsp;&nbsp;&nbsp;Conversions</a></h2>
<p>Whenever Emacs Lisp calls Python functions giving them arguments, these
arguments are Emacs Lisp structures that should be converted into Python
objects in some way.  Conversely, whenever Python calls Emacs Lisp
functions, the arguments are Python objects that should be received
as Emacs Lisp structures.  We need some conventions for doing such
conversions.</p>
<p>Conversions generally transmit mutable Emacs Lisp structures as mutable
objects on the Python side, in such a way that transforming the object
in Python will effectively transform the structure on the Emacs Lisp
side (strings are handled a bit specially however, see below).  The
other way around, Python objects transmitted to Emacs Lisp often loose
their mutability, so transforming the Emacs Lisp structure is not
reflected on the Python side.</p>
<p>Pymacs sticks to standard Emacs Lisp, it explicitly avoids various Emacs
Lisp extensions.  One goal for many Pymacs users is taking some distance
from Emacs Lisp, so Pymacs is not overly pushing users deeper into it.</p>
</div>
<div class="section" id="simple-objects">
<h2><a class="toc-backref" href="#id15">3.2&nbsp;&nbsp;&nbsp;Simple objects</a></h2>
<p>Emacs Lisp <strong class="code">nil</strong> and the equivalent Emacs Lisp <tt class="docutils literal">()</tt> yield Python
<strong class="code">None</strong>.  Python <strong class="code">None</strong>, Python <strong class="code">False</strong> and the Python
empty list <tt class="docutils literal">[]</tt> are returned as <strong class="code">nil</strong> in Emacs Lisp.  Notice
the assymetry, in that three different Python objects are mapped into
a single Emacs Lisp object.  So, neither <strong class="code">False</strong> nor <tt class="docutils literal">[]</tt> are
likely produced by automatic conversions from Emacs Lisp to Python.</p>
<p>Emacs Lisp <strong class="code">t</strong> yields Python <strong class="code">True</strong>.  Python <strong class="code">True</strong> is
returned as <strong class="code">t</strong> in Emacs Lisp.</p>
<p>Emacs Lisp numbers, either integer or floating, are converted in
equivalent Python numbers.  Emacs Lisp characters are really numbers
and yield Python numbers.  In the other direction, Python numbers are
converted into Emacs Lisp numbers, with the exception of long Python
integers and complex numbers.</p>
<p>Emacs Lisp strings are usually converted into equivalent Python strings.
As Python strings do not have text properties, these are not reflected.
This may be changed by setting the <strong class="code">pymacs-mutable-strings</strong>
option: if this variable is not <strong class="code">nil</strong>, Emacs Lisp strings are
then transmitted opaquely.  Python strings are always converted into
Emacs Lisp strings.  Unicode strings are produced on the Python side for
Emacs Lisp multi-byte strings, but only when they do not fit in ASCII,
otherwise Python narrow strings are produced.  Conversely, Emacs Lisp
multi-byte strings are produced for Python Unicode strings, but only
when they do not fit ASCII, otherwise Emacs Lisp uni-byte strings are
produced.  Currently, Pymacs behaviour is undefined for users wandering
outside the limits of Emacs' <strong class="code">utf-8</strong> coding system.</p>
<p>Emacs Lisp symbols yield <tt class="docutils literal">lisp[STRING]</tt> notations on the Python
side, where <em class="var">STRING</em> names the symbol.  In the other direction,
Python <tt class="docutils literal">lisp[STRING]</tt> corresponds to an Emacs Lisp symbol printed
with that <em class="var">STRING</em> which, of course, should then be a valid Emacs
Lisp symbol name.  As a convenience, <tt class="docutils literal">lisp.SYMBOL</tt> on the Python side
yields an Emacs Lisp symbol with underscores replaced with hyphens;
this convention is welcome, as Emacs Lisp programmers commonly prefer
using dashes, where Python programmers use underlines.  Of course, this
<tt class="docutils literal">lisp.SYMBOL</tt> notation is only usable when the <em class="var">SYMBOL</em> is a
valid Python identifier, while not being a Python keyword.</p>
</div>
<div class="section" id="sequences">
<h2><a class="toc-backref" href="#id16">3.3&nbsp;&nbsp;&nbsp;Sequences</a></h2>
<p>The case of strings has been discussed in the previous section.</p>
<p>Proper Emacs Lisp lists, those for which the <strong class="code">cdr</strong> of last cell
is <strong class="code">nil</strong>, are normally transmitted opaquely to Python.  If
<strong class="code">pymacs-forget-mutability</strong> is set, or if Python later asks for
these to be expanded, proper Emacs Lisp lists get converted into Python
lists, if we except the empty list, which is always converted as Python
<strong class="code">None</strong>.  In the other direction, Python lists are always converted
into proper Emacs Lisp lists.</p>
<p>Emacs Lisp vectors are normally transmitted opaquely to Python.
However, if <strong class="code">pymacs-forget-mutability</strong> is set, or if Python
later asks for these to be expanded, Emacs Lisp vectors get converted
into Python tuples.  In the other direction, Python tuples are always
converted into Emacs Lisp vectors.</p>
<p>Remember the rule: <cite>Round parentheses correspond to square brackets!</cite>.
It works for lists, vectors, tuples, seen from either Emacs Lisp or
Python.</p>
<p>The above choices were debatable.  Since Emacs Lisp proper lists
and Python lists are the bread-and-butter of algorithms modifying
structures, at least in my experience, I guess they are more naturally
mapped into one another, this spares many casts in practice.  While in
Python, the most usual idiom for growing lists is appending to their
end, the most usual idiom in Emacs Lisp to grow a list is by cons'ing
new items at its beginning:</p>
<pre class="literal-block">
(setq accumulator (cons 'new-item accumulator))
</pre>
<p>or more simply:</p>
<pre class="literal-block">
(push 'new-item accumulator)
</pre>
<p>So, in case speed is especially important and many modifications
happen in a row on the same side, while order of elements ought to
be preserved, some <tt class="docutils literal">(nreverse <span class="pre">...)</span></tt> on the Emacs Lisp side or
<tt class="docutils literal">.reverse()</tt> on the Python side side might be needed.  Surely, proper
lists in Emacs Lisp and lists in Python are the normal structure for
which length is easily modified.</p>
<p>We cannot so easily change the size of a vector, the same as it is a bit
more of a stunt to <em>modify</em> a tuple.  The shape of these objects is
fixed.  Mapping vectors to tuples, which is admittedly strange, will
only be done if the Python side requests an expanded copy, otherwise an
opaque Emacs Lisp object is seen in Python.  In the other direction,
whenever an Emacs Lisp vector is needed, one has to write
<tt class="docutils literal">tuple(python_list)</tt> while transmitting the object.  Such
transmissions are most probably to be unusual, as people are not going
to blindly transmit whole big structures back and forth between Emacs
and Python, they would rather do it once in a while only, and do only
local modifications afterwards.  The infrequent casting to <strong class="code">tuple</strong>
for getting an Emacs Lisp vector seems to suggest that we did a
reasonable compromise.</p>
<p>In Python, both tuples and lists have O(1) access, so there is no real
speed consideration there.  Emacs Lisp is different: vectors have
O(1) access while lists have O(N) access.  The rigidity of Emacs Lisp
vectors is such that people do not resort to vectors unless there
is a speed issue, so in real Emacs Lisp practice, vectors are used
rather parsimoniously.  So much, in fact, that Emacs Lisp vectors are
overloaded for what they are not meant: for example, very small vectors
are used to represent X events in key-maps, programmers only want to
test vectors for their type, or users just like bracketed syntax.  The
speed of access is hardly an issue then.</p>
</div>
<div class="section" id="opaque-objects">
<h2><a class="toc-backref" href="#id17">3.4&nbsp;&nbsp;&nbsp;Opaque objects</a></h2>
<div class="section" id="emacs-lisp-handles">
<h3><a class="toc-backref" href="#id18">3.4.1&nbsp;&nbsp;&nbsp;Emacs Lisp handles</a></h3>
<p>When a Python function is called from Emacs Lisp, the function arguments
have already been converted to Python types from Emacs Lisp types and
the function result is going to be converted back to Emacs Lisp.</p>
<p>Several Emacs Lisp objects do not have Python equivalents, like for
Emacs windows, buffers, markers, overlays, etc.  It is nevertheless
useful to pass them to Python functions, hoping that these Python
functions will <em>operate</em> on these Emacs Lisp objects.  Of course, the
Python side may not itself modify such objects, it has to call for
Emacs services to do so.  Emacs Lisp handles are a mean to ease this
communication.</p>
<p>Whenever an Emacs Lisp object may not be converted to a Python object,
an Emacs Lisp handle is created and used instead.  Whenever that Emacs
Lisp handle is returned into Emacs Lisp from a Python function, or
is used as an argument to an Emacs Lisp function from Python, the
original Emacs Lisp object behind the Emacs Lisp handle is automatically
retrieved.</p>
<p>Emacs Lisp handles are either instances of the internal <strong class="code">Lisp</strong>
class, or of one of its subclasses.  If <em class="var">OBJECT</em> is an Emacs
Lisp handle, and if the underlying Emacs Lisp object is an Emacs
Lisp sequence, then whenever <tt class="docutils literal">OBJECT[INDEX]</tt>, <tt class="docutils literal">OBJECT[INDEX] =
VALUE</tt> and <tt class="docutils literal">len(OBJECT)</tt> are meaningful, these may be used to
fetch or alter an element of the sequence directly in Emacs Lisp
space.  Also, if <em class="var">OBJECT</em> corresponds to an Emacs Lisp function,
<tt class="docutils literal">OBJECT(ARGUMENTS)</tt> may be used to apply the Emacs Lisp function over
the given arguments.  Since arguments have been evaluated the Python
way on the Python side, it would be conceptual overkill evaluating them
again the Emacs Lisp way on the Emacs Lisp side, so Pymacs manage to
quote arguments for defeating Emacs Lisp evaluation.  The same logic
applies the other way around.</p>
<p>Emacs Lisp handles have a <tt class="docutils literal">value()</tt> method, which merely returns
self.  They also have a <tt class="docutils literal">copy()</tt> method, which tries to <em>open
the box</em> if possible.  Emacs Lisp proper lists are turned into Python
lists, Emacs Lisp vectors are turned into Python tuples.  Then,
modifying the structure of the copy on the Python side has no effect on
the Emacs Lisp side.</p>
<p>For Emacs Lisp handles, <tt class="docutils literal">str()</tt> returns an Emacs Lisp representation
of the handle which should be <strong class="code">eq</strong> to the original object if
read back and evaluated in Emacs Lisp. <tt class="docutils literal">repr()</tt> returns a Python
representation of the expanded Emacs Lisp object.  If that Emacs Lisp
object has an Emacs Lisp representation which Emacs Lisp could read
back, then <tt class="docutils literal">repr()</tt> value is such that it could be read back and
evaluated in Python as well, this would result in another object which
is <strong class="code">equal</strong> to the original, but not necessarily <strong class="code">eq</strong>.</p>
</div>
<div class="section" id="python-handles">
<h3><a class="toc-backref" href="#id19">3.4.2&nbsp;&nbsp;&nbsp;Python handles</a></h3>
<p>The same as Emacs Lisp handles are useful for handling Emacs Lisp
objects on the Python side, Python handles are useful for handling
Python objects on the Emacs Lisp side.</p>
<p>Many Python objects do not have direct Emacs Lisp equivalents, including
long integers, complex numbers, modules, classes, instances and surely a
lot of others.  When such are being transmitted to the Emacs Lisp side,
Pymacs use Python handles.  These are automatically recovered into the
original Python objects whenever transmitted back to Python, either as
arguments to a Python function, as the Python function itself, or as the
return value of an Emacs Lisp function called from Python.</p>
<p>The objects represented by these Python handles may be inspected or
modified using the basic library of Python functions.  For example, in:</p>
<pre class="literal-block">
(pymacs-exec &quot;import re&quot;)
(setq matcher (pymacs-eval &quot;re.compile('PATTERN').match&quot;))
(pymacs-call matcher ARGUMENT)
</pre>
<p>the <strong class="code">setq</strong> line above could be decomposed into:</p>
<pre class="literal-block">
(setq compiled (pymacs-eval &quot;re.compile('PATTERN')&quot;)
      matcher (pymacs-call &quot;getattr&quot; compiled &quot;match&quot;))
</pre>
<p>This example shows that one may use <strong class="code">pymacs-call</strong> with
<strong class="code">getattr</strong> as the function, to get a wanted attribute for a Python
object.</p>
</div>
</div>
</div>
<div class="section" id="usage-on-the-emacs-lisp-side">
<h1><a class="toc-backref" href="#id20">4&nbsp;&nbsp;&nbsp;Usage on the Emacs Lisp side</a></h1>
<div class="section" id="pymacs-exec">
<h2><a class="toc-backref" href="#id21">4.1&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-exec</strong></a></h2>
<p>Function <tt class="docutils literal"><span class="pre">(pymacs-exec</span> TEXT)</tt> gets <em class="var">TEXT</em> executed as a Python
statement, and its value is always <strong class="code">nil</strong>.  So, this function may
only be useful because of its possible side effects on the Python side.</p>
<p>This function may also be called interactively:</p>
<pre class="literal-block">
M-x pymacs-exec RET TEXT RET
</pre>
</div>
<div class="section" id="pymacs-eval">
<h2><a class="toc-backref" href="#id22">4.2&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-eval</strong></a></h2>
<p>Function <tt class="docutils literal"><span class="pre">(pymacs-eval</span> TEXT)</tt> gets <em class="var">TEXT</em> evaluated as a Python
expression, and returns the value of that expression converted back to
Emacs Lisp.</p>
<p>This function may also be called interactively:</p>
<pre class="literal-block">
M-x pymacs-eval RET TEXT RET
</pre>
</div>
<div class="section" id="pymacs-call">
<h2><a class="toc-backref" href="#id23">4.3&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-call</strong></a></h2>
<p>Function <tt class="docutils literal"><span class="pre">(pymacs-call</span> FUNCTION <span class="pre">ARGUMENT...)</span></tt> will get Python to
apply the given <em class="var">FUNCTION</em> over zero or more <em class="var">ARGUMENT</em>.
<em class="var">FUNCTION</em> is either a string holding Python source code for a
function (like a mere name, or even an expression), or else, a Python
handle previously received from Python, and hopefully holding a callable
Python object.  Each <em class="var">ARGUMENT</em> gets separately converted to Python
before the function is called. <strong class="code">pymacs-call</strong> returns the resulting
value of the function call, converted back to Emacs Lisp.</p>
</div>
<div class="section" id="pymacs-apply">
<h2><a class="toc-backref" href="#id24">4.4&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-apply</strong></a></h2>
<p>Function <tt class="docutils literal"><span class="pre">(pymacs-apply</span> FUNCTION ARGUMENTS)</tt> will get Python to
apply the given <em class="var">FUNCTION</em> over the given <em class="var">ARGUMENTS</em>.
<em class="var">ARGUMENTS</em> is a list containing all arguments, or <strong class="code">nil</strong>
if there is none.  Besides arguments being bundled together
instead of given separately, the function acts pretty much like
<strong class="code">pymacs-call</strong>.</p>
</div>
<div class="section" id="pymacs-load">
<h2><a class="toc-backref" href="#id25">4.5&nbsp;&nbsp;&nbsp;<strong class="code">pymacs-load</strong></a></h2>
<p>Function <tt class="docutils literal"><span class="pre">(pymacs-load</span> MODULE PREFIX)</tt> imports the Python
<em class="var">module</em> into Emacs Lisp space. <em class="var">MODULE</em> is the name of the
file containing the module, without any <tt class="file docutils literal">.py</tt> or <tt class="file docutils literal">.pyc</tt>
extension.  If the directory part is omitted in <em class="var">MODULE</em>, the
module will be looked into the current Python search path.  Dot notation
may be used when the module is part of a package.  Each top-level
function in the module produces a trampoline function in Emacs Lisp
having the same name, except that underlines in Python names are
turned into dashes in Emacs Lisp, and that <em class="var">PREFIX</em> is uniformly
added before the Emacs Lisp name (as a way to avoid name clashes).
<em class="var">PREFIX</em> may be omitted, in which case it defaults to base name
of <em class="var">MODULE</em> with underlines turned into dashes, and followed by a
dash.</p>
<p>Note that <strong class="code">pymacs-load</strong> has the effect of declaring the module
variables and methods the Emacs Lisp side, but it does <em>not</em> declare
anything on the Python side.  Of course, Python imports the module
before making it available for Emacs, but there is no Pymacs ready
variable on the Python side holding that module.  If you need to import
<em class="var">MODULE</em> in a variable on the Python side, the proper incantation
is <tt class="docutils literal"><span class="pre">(pymacs-exec</span> &quot;import MODULE&quot;)</tt>.  And of course, that this latter
statement does not declare anything on the Emacs Lisp side.</p>
<p>Whenever <strong class="code">pymacs_load_hook</strong> is defined in the loaded
Python module, <strong class="code">pymacs-load</strong> calls it without arguments,
but before creating the Emacs view for that module.  So, the
<strong class="code">pymacs_load_hook</strong> function may create new definitions or even add
<strong class="code">interaction</strong> attributes to functions.</p>
<p>The return value of a successful <strong class="code">pymacs-load</strong> is the module
object.  An optional third argument, <em class="var">noerror</em>, when given and not
<strong class="code">nil</strong>, will have <strong class="code">pymacs-load</strong> to return <strong class="code">nil</strong> instead
of raising an error, if the Python module could not be found.</p>
<p>When later calling one of these trampoline functions, all provided
arguments are converted to Python and transmitted, and the function
return value is later converted back to Emacs Lisp.  It is left to
the Python side to check for argument consistency.  However, for an
interactive function, the interaction specification drives some checking
on the Emacs Lisp side.  Currently, there is no provision for collecting
keyword arguments in Emacs Lisp.</p>
<p>This function may also be called interactively:</p>
<pre class="literal-block">
M-x pymacs-load RET MODULE RET PREFIX RET
</pre>
</div>
<div class="section" id="expected-usage">
<h2><a class="toc-backref" href="#id26">4.6&nbsp;&nbsp;&nbsp;Expected usage</a></h2>
<p>We do not expect that <strong class="code">pymacs-exec</strong>, <strong class="code">pymacs-eval</strong>,
<strong class="code">pymacs-call</strong> or <strong class="code">pymacs-apply</strong> will be much used, if
ever, in most Pymacs applications.  In practice, the Emacs Lisp side
of a Pymacs application might call <strong class="code">pymacs-load</strong> a few times for
linking into the Python modules, with the indirect effect of defining
trampoline functions for these modules on the Emacs Lisp side, which can
later be called like usual Emacs Lisp functions.</p>
<p>These imported functions are usually those which are of interest for the
user, and the preferred way to call Python services with Pymacs.</p>
</div>
<div class="section" id="special-emacs-lisp-variables">
<h2><a class="toc-backref" href="#id27">4.7&nbsp;&nbsp;&nbsp;Special Emacs Lisp variables</a></h2>
<p>Users could alter the inner working of Pymacs through a few variables,
these are all documented here.  Except for <strong class="code">pymacs-load-path</strong>,
which should be set before calling any Pymacs function, the value of
these variables can be changed at any time.</p>
<div class="section" id="pymacs-load-path">
<h3><a class="toc-backref" href="#id28">4.7.1&nbsp;&nbsp;&nbsp;pymacs-load-path</a></h3>
<p>Users might want to use special directories for holding their Python
modules, when these modules are meant to be used from Emacs.  Best is to
preset <strong class="code">pymacs-load-path</strong>, <strong class="code">nil</strong> by default, to a list of
these directory names.  (Tilde expansions and such occur automatically.)</p>
<p>Here is how it works.  The first time Pymacs is needed from Emacs,
a Pymacs helper is automatically started as an Emacs subprocess, and
given as arguments all strings in the <strong class="code">pymacs-load-path</strong> list.
These arguments are added at the beginning of <strong class="code">sys.path</strong>,
or moved at the beginning if they were already on <strong class="code">sys.path</strong>.
So in practice, nothing is removed from <strong class="code">sys.path</strong>.</p>
</div>
<div class="section" id="pymacs-trace-transit">
<h3><a class="toc-backref" href="#id29">4.7.2&nbsp;&nbsp;&nbsp;pymacs-trace-transit</a></h3>
<p>The <strong class="code">*Pymacs*</strong> buffer, within Emacs, holds a trace of transactions
between Emacs and Python.  When <strong class="code">pymacs-trace-transit</strong> is
<strong class="code">nil</strong>, the buffer only holds the last bi-directional transaction
(a request and a reply).  In this case, it gets erased before each and
every transaction.  If that variable is <strong class="code">t</strong>, all transactions are
kept.  This could be useful for debugging, but the drawback is that
this buffer could grow big over time, to the point of diminishing Emacs
performance.  As a compromise, that variable may also be a cons cell
of integers <tt class="docutils literal">(KEEP . LIMIT)</tt>, in which case the buffer is reduced to
approximately <em class="var">KEEP</em> bytes whenever its size exceeds <em class="var">LIMIT</em>
bytes, by deleting an integral number of lines from its beginning.  The
default setting for <strong class="code">pymacs-trace-transit</strong> is <tt class="docutils literal">(5000 . 30000)</tt>.</p>
</div>
<div class="section" id="pymacs-forget-mutability">
<h3><a class="toc-backref" href="#id30">4.7.3&nbsp;&nbsp;&nbsp;pymacs-forget-mutability</a></h3>
<p>The default behaviour of Pymacs is to transmit Emacs Lisp objects to
Python in such a way that they are fully modifiable from the Python
side, would it mean triggering Emacs Lisp functions to act on them.
When <strong class="code">pymacs-forget-mutability</strong> is not <strong class="code">nil</strong>, the behaviour
is changed, and the flexibility is lost.  Pymacs then tries to expand
proper lists and vectors as full copies when transmitting them on the
Python side.  This variable, seen as a user setting, is best left to
<strong class="code">nil</strong>.  It may be temporarily overridden within some functions,
when deemed useful.</p>
<p>There is no corresponding variable from objects transmitted to Emacs
from Python.  Pymacs automatically expands what gets transmitted.
Mutability is preserved only as a side-effect of not having a natural
Emacs Lisp representation for the Python object.  This asymmetry is on
purpose, yet debatable.  Maybe Pymacs could have a variable telling that
mutability is important for Python objects?  That would give Pymacs
users the capability of restoring the symmetry somewhat, yet so far, in
our experience, this has never been needed.</p>
</div>
<div class="section" id="pymacs-mutable-strings">
<h3><a class="toc-backref" href="#id31">4.7.4&nbsp;&nbsp;&nbsp;pymacs-mutable-strings</a></h3>
<p>Strictly speaking, Emacs Lisp strings are mutable. Yet, it does not
come naturally to a Python programmer to modify a string <em>in-place</em>, as
Python strings are never mutable.  When <strong class="code">pymacs-mutable-strings</strong>
is <strong class="code">nil</strong>, which is the default setting, Emacs Lisp strings are
transmitted to Python as Python strings, and so, loose their mutability.
Moreover, text properties are not reflected on the Python side.  But
if that variable is not <strong class="code">nil</strong>, Emacs Lisp strings are rather
passed as Emacs Lisp handles.  This variable is ignored whenever
<strong class="code">pymacs-forget-mutability</strong> is set.</p>
</div>
<div class="section" id="timeout-variables">
<h3><a class="toc-backref" href="#id32">4.7.5&nbsp;&nbsp;&nbsp;Timeout variables</a></h3>
<p>Emacs needs to protect itself a bit, in case the Pymacs service program,
which handles the Python side of requests, would not start correctly, or
maybe later die unexpectedly.  So, whenever Emacs reads data coming from
that program, it sets a time limit, and take some action whenever that
time limit expires.  All times are expressed in seconds.</p>
<p>The <strong class="code">pymacs-timeout-at-start</strong> variable defaults to 30 seconds,
this time should only be increased if a given machine is so heavily
loaded that the Pymacs service program has not enough of 30 seconds to
start, in which case Pymacs refuses to work, with an appropriate message
in the mini buffer.</p>
<p>The two remaining timeout variables almost never need to be changed
in practice.  When Emacs is expecting a reply from Python, it might
repeatedly check the status of the Pymacs service program when that
reply is not received fast enough, just to make sure that this program
did not die.  The <strong class="code">pymacs-timeout-at-reply</strong> variable, which
defaults to 5, says how many seconds to wait without checking, while
expecting the first line of a reply.  The <strong class="code">pymacs-timeout-at-line</strong>
variable, which defaults to 2, says how many seconds to wait without
checking, while expecting a line of the reply after the first.</p>
</div>
<div class="section" id="pymacs-dreadful-zombies">
<h3><a class="toc-backref" href="#id33">4.7.6&nbsp;&nbsp;&nbsp;pymacs-dreadful-zombies</a></h3>
<p>When the Pymacs helper dies, all useful Python objects it might contain
also die with it.  However, if the death occurs unexpectedly, instead of
normally at the end of the Emacs session, there might now exist dangling
references in Emacs Lisp space towards those vanished Python objects.</p>
<p>Pymacs could not do much without a Pymacs helper, and likely, a new
one will soon be created within the same Emacs session, and brand new
Python objects may be created within that new helper.  Now, and this is
a bit technical, all references are transmitted in form of object slot
numbers.  As a consequence, the new Pymacs helper should be careful at
never allocating a new Python object using a slot number of a useful
vanished object, as this might possibly create fatal confusion.</p>
<p>There is not enough information for the new Pymacs helper to recreate
the useful objects which disappeared.  However, there is enough
machinery to recover all their slot numbers, and then, all these slots
are initialized with so-called <em>zombies</em>.  If Emacs later calls a
vanished Python object, this merely awakes its zombie, which will then
make some noise, then fall asleep again.  The noise has the form of a
diagnostic within the <tt class="docutils literal">*Messages*</tt> buffer, sometimes visible in the
mini-buffer as well when the mini-buffer is not simultaneously used for
some other purpose.</p>
<p>Zombies get more dreadful if <strong class="code">pymacs-dreadful-zombies</strong> is set to a
non-<strong class="code">nil</strong> value.  In this case, calling a vanished Python object
raises an error that will eventually interrupt the current computation.
Such a behaviour might be useful for debugging purposes, or for making
sure that no call to a vanished Python object goes unnoticed.</p>
<p>In previous Pymacs releases, zombies were always dreadful, under the
assumption that calling a vanished object is a real error.  However, it
could cause irritation in some circumstances, like when associated with
frequently triggered Emacs Lisp hook functions.  That's why that, by
default, zombies have been finally turned into more innocuous beings!</p>
</div>
</div>
</div>
<div class="section" id="usage-on-the-python-side">
<h1><a class="toc-backref" href="#id34">5&nbsp;&nbsp;&nbsp;Usage on the Python side</a></h1>
<div class="section" id="python-setup">
<h2><a class="toc-backref" href="#id35">5.1&nbsp;&nbsp;&nbsp;Python setup</a></h2>
<p>For Python modules meant to be used from Emacs and which receive nothing
but Emacs <strong class="code">nil</strong>, numbers or strings, or return nothing but Python
<strong class="code">None</strong>, numbers or strings, then Pymacs requires little or no
setup.  Otherwise, use <tt class="docutils literal">from Pymacs import lisp</tt> at the start of your
module.  If you need more Pymacs features, like the <strong class="code">Let</strong> class,
then write <tt class="docutils literal">from Pymacs import lisp, Let</tt>.</p>
<p>The Pymacs helper runs Python code to serve the Emacs side, and it is
blocked waiting until Emacs sends a request.  Until the Pymacs helper
returns a reply, Emacs is blocked in turn, yet fully listening to serve
eventual Python sub-requests, etc.  So, either Emacs or the Pymacs
helper is active at a given instant, but never both at once.</p>
<p>Unless Emacs has sent a request to the Pymacs helper and is expecting
a reply, it is just not listening to receive Python requests.  So, any
other Python thread may not asynchronously use Pymacs to get Emacs
services.  The design of the Python application should be such that the
communication is always be channelled from the main Python thread.</p>
<p>When Pymacs starts, all process signals are inhibited on the Python
side.  Yet, <strong class="code">SIGINT</strong> gets re-enabled while running user functions.
If the user elects to reactivate some other signal in her Python code,
she should do so as to not damage or severe the communication protocol.</p>
</div>
<div class="section" id="emacs-lisp-symbols">
<h2><a class="toc-backref" href="#id36">5.2&nbsp;&nbsp;&nbsp;Emacs Lisp symbols</a></h2>
<p><strong class="code">lisp</strong> is a special object which has useful built-in magic.  Its
attributes do nothing but represent Emacs Lisp symbols, created on the
fly as needed (symbols also have their built-in magic).</p>
<p>As special cases, <tt class="docutils literal">lisp.nil</tt> or <tt class="docutils literal"><span class="pre">lisp[&quot;nil&quot;]</span></tt> are the same
as <strong class="code">None</strong>, and <tt class="docutils literal">lisp.t</tt> or <tt class="docutils literal"><span class="pre">lisp[&quot;t&quot;]</span></tt> are the same as
<strong class="code">True</strong>.  Otherwise, both <tt class="docutils literal">lisp.SYMBOL</tt> and <tt class="docutils literal">lisp[STRING]</tt>
yield objects of the internal <strong class="code">Symbol</strong> type.  These are genuine
Python objects, that could be referred to by simple Python variables.
One may write <tt class="docutils literal">quote = lisp.quote</tt>, for example, and use <tt class="docutils literal">quote</tt>
afterwards to mean that Emacs Lisp symbol.  If a Python function
received an Emacs Lisp symbol as an argument, it can check with <tt class="docutils literal">==</tt>
if that argument is <tt class="docutils literal">lisp.never</tt> or <tt class="docutils literal">lisp.ask</tt>, say.  A Python
function may well choose to return some symbol, like <tt class="docutils literal">lisp.always</tt>.</p>
<p>In Python, writing <tt class="docutils literal">lisp.SYMBOL = VALUE</tt> or <tt class="docutils literal">lisp[STRING] = VALUE</tt>
does assign <em class="var">VALUE</em> to the corresponding symbol in Emacs Lisp
space.  Beware that in such cases, the <tt class="docutils literal">lisp.</tt> prefix may not be
spared.  After <tt class="docutils literal">result = lisp.result</tt>, one cannot hope that a later
<tt class="docutils literal">result = 3</tt> will have any effect in the Emacs Lisp space: this would
merely change the Python variable <tt class="docutils literal">result</tt>, which was a reference to a
<strong class="code">Symbol</strong> instance, so it is now a reference to the number 3.</p>
<p>The <strong class="code">Symbol</strong> class has <tt class="docutils literal">value()</tt> and <tt class="docutils literal">copy()</tt> methods.  One
can use either <tt class="docutils literal">lisp.SYMBOL.value()</tt> or <tt class="docutils literal">lisp.SYMBOL.copy()</tt>
to access the Emacs Lisp value of a symbol, after conversion to
some Python object, of course.  However, if <tt class="docutils literal">value()</tt> would have
given an Emacs Lisp handle, <tt class="docutils literal">lisp.SYMBOL.copy()</tt> has the effect of
<tt class="docutils literal"><span class="pre">lisp.SYMBOL.value().copy()</span></tt>, that is, it returns the value of the
symbol as opened as possible.</p>
<p>A symbol may also be used as if it was a Python function, in which case
it really names an Emacs Lisp function that should be applied over the
following function arguments.  The result of the Emacs Lisp function
becomes the value of the call, with all due conversions of course.</p>
</div>
<div class="section" id="dynamic-bindings">
<h2><a class="toc-backref" href="#id37">5.3&nbsp;&nbsp;&nbsp;Dynamic bindings</a></h2>
<p>As Emacs Lisp uses dynamic bindings, it is common that Emacs Lisp
programs use <strong class="code">let</strong> for temporarily setting new values for some
Emacs Lisp variables having global scope.  These variables recover their
previous value automatically when the <strong class="code">let</strong> gets completed, even
if an error occurs which interrupts the normal flow of execution.</p>
<p>Pymacs has a <strong class="code">Let</strong> class to represent such temporary
settings.  Suppose for example that you want to recover the value of
<tt class="docutils literal">lisp.mark()</tt> when the transient mark mode is active on the Emacs Lisp
side.  One could surely use <tt class="docutils literal">lisp.mark(True)</tt> to <em>force</em> reading the
mark in such cases, but for the sake of illustration, let's ignore that,
and temporarily deactivate transient mark mode instead.  This could be
done this way:</p>
<pre class="literal-block">
try:
    let = Let()
    let.push(transient_mark_mode=None)
    ... USER CODE ...
finally:
    let.pop()
</pre>
<p><tt class="docutils literal">let.push()</tt> accepts any number of keywords arguments.  Each keyword
name is interpreted as an Emacs Lisp symbol written the Pymacs way, with
underlines.  The value of that Emacs Lisp symbol is saved on the Python
side, and the value of the keyword becomes the new temporary value for
this Emacs Lisp symbol.  A later <tt class="docutils literal">let.pop()</tt> restores the previous
value for all symbols which were saved together at the time of the
corresponding <tt class="docutils literal">let.push()</tt>.  There may be more than one <tt class="docutils literal">let.push()</tt>
call for a single <strong class="code">Let</strong> instance, they stack within that instance.
Each <tt class="docutils literal">let.pop()</tt> will undo one and only one <tt class="docutils literal">let.push()</tt> from the
stack, in the reverse order or the pushes.</p>
<p>When the <strong class="code">Let</strong> instance disappears, either because the programmer
does <tt class="docutils literal">del let</tt> or <tt class="docutils literal">let = None</tt>, or just because the Python
<strong class="code">let</strong> variable goes out of scope, all remaining <tt class="docutils literal">let.pop()</tt> get
automatically executed, so the <strong class="code">try</strong>/<strong class="code">finally</strong> statement
may be omitted in practice.  For this omission to work flawlessly, the
programmer should be careful at not keeping extra references to the
<strong class="code">Let</strong> instance.</p>
<p>The constructor call <tt class="docutils literal">let = Let()</tt> also has an implied initial
<tt class="docutils literal">.push()</tt> over all given arguments, so the explicit <tt class="docutils literal">let.push()</tt> may
be omitted as well.  In practice, this sums up and the above code could
be reduced to a mere:</p>
<pre class="literal-block">
let = Let(transient_mark_mode=None)
... USER CODE ...
</pre>
<p>Be careful at assigning the result of the constructor to some Python
variable.  Otherwise, the instance would disappear immediately after
having been created, restoring the Emacs Lisp variable much too soon.</p>
<p>Any variable to be bound with <strong class="code">Let</strong> should have been bound in
advance on the Emacs Lisp side.  This restriction usually does no kind
of harm.  Yet, it will likely be lifted in some later version of Pymacs.</p>
<p>The <strong class="code">Let</strong> class has other methods meant for some macros which are
common in Emacs Lisp programming, in the spirit of <strong class="code">let</strong> bindings.
These method names look like <tt class="docutils literal">push_*</tt> or <tt class="docutils literal">pop_*</tt>, where Emacs Lisp
macros are <tt class="docutils literal"><span class="pre">save-*</span></tt>.  One has to use the matching <tt class="docutils literal">pop_*</tt> for
undoing the effect of a given <tt class="docutils literal">push_*</tt> rather than a mere <tt class="docutils literal">.pop()</tt>:
the Python code is clearer, this also ensures that things are undone in
the proper order.  The same <strong class="code">Let</strong> instance may use many <tt class="docutils literal">push_*</tt>
methods, their effects nest.</p>
<p><tt class="docutils literal">push_excursion()</tt> and <tt class="docutils literal">pop_excursion()</tt> save and restore
the current buffer, point and mark. <tt class="docutils literal">push_match_data()</tt> and
<tt class="docutils literal">pop_match_data()</tt> save and restore the state of the last regular
expression match. <tt class="docutils literal">push_restriction()</tt> and <tt class="docutils literal">pop_restriction()</tt> save
and restore the current narrowing limits. <tt class="docutils literal">push_selected_window()</tt> and
<tt class="docutils literal">pop_selected_window()</tt> save and restore the fact that a window holds
the cursor. <tt class="docutils literal">push_window_excursion()</tt> and <tt class="docutils literal">pop_window_excursion()</tt>
save and restore the current window configuration in the Emacs display.</p>
<p>As a convenience, <tt class="docutils literal">let.push()</tt> and all other <tt class="docutils literal">push_*</tt> methods return
the <strong class="code">Let</strong> instance.  This helps chaining various <tt class="docutils literal">push_*</tt> right
after the instance generation.  For example, one may write:</p>
<pre class="literal-block">
let = Let().push_excursion()
if True:
    ... USER CODE ...
del let
</pre>
<p>The <tt class="docutils literal">if True:</tt> (use <tt class="docutils literal">if 1:</tt> with older Python releases, some people
might prefer writing <tt class="docutils literal">if let:</tt> anyway), has the only goal of indenting
<em class="var">USER CODE</em>, so the scope of the <strong class="code">let</strong> variable is made very
explicit.  This is purely stylistic, and not at all necessary.  The last
<tt class="docutils literal">del let</tt> might be omitted in a few circumstances, for example if the
excursion lasts until the end of the Python function.</p>
</div>
<div class="section" id="raw-emacs-lisp-expressions">
<h2><a class="toc-backref" href="#id38">5.4&nbsp;&nbsp;&nbsp;Raw Emacs Lisp expressions</a></h2>
<p>Pymacs offers a device for evaluating a raw Emacs Lisp expression, or a
sequence of such, expressed as a string.  One merely uses <strong class="code">lisp</strong>
as a function, like this:</p>
<pre class="literal-block">
lisp(&quot;&quot;&quot;
...
POSSIBLY-LONG-SEQUENCE-OF-LISP-EXPRESSIONS
...
&quot;&quot;&quot;)
</pre>
<p>The Emacs Lisp value of the last or only expression in the sequence
becomes the value of the <strong class="code">lisp</strong> call, after conversion back to
Python.</p>
</div>
<div class="section" id="user-interaction">
<h2><a class="toc-backref" href="#id39">5.5&nbsp;&nbsp;&nbsp;User interaction</a></h2>
<p>Emacs functions have the concept of user interaction for completing the
specification of their arguments while being called.  This happens only
when a function is interactively called by the user, it does not happen
when a function is directly called by another.  As Python does not have
a corresponding facility, a bit of trickery was needed to retrofit that
facility on the Python side.</p>
<p>After loading a Python module but prior to creating an Emacs view
for this module, Pymacs decides whether loaded functions will be
interactively callable from Emacs, or not.  Whenever a function has
an <strong class="code">interaction</strong> attribute, this attribute holds the Emacs
interaction specification for this function.  The specification is
either another Python function or a string.  In the former case, that
other function is called without arguments and should, maybe after
having consulted the user, return a list of the actual arguments to be
used for the original function.  In the latter case, the specification
string is used verbatim as the argument to the <tt class="docutils literal">(interactive <span class="pre">...)</span></tt>
function on the Emacs side.  To get a short reminder about how this
string is interpreted on the Emacs side, try <tt class="docutils literal"><span class="pre">C-h</span> f interactive</tt>
within Emacs.  Here is an example where an empty string is used to
specify that an interactive has no arguments:</p>
<pre class="literal-block">
from Pymacs import lisp

def hello_world():
    &quot;`Hello world' from Python.&quot;
    lisp.insert(&quot;Hello from Python!&quot;)
hello_world.interaction = ''
</pre>
<!-- ` -->
<p>Versions of Python released before the integration of PEP 232 do not
allow users to add attributes to functions, so there is a fall-back
mechanism.  Let's presume that a given function does not have an
<strong class="code">interaction</strong> attribute as explained above.  If the Python module
contains an <strong class="code">interactions</strong> global variable which is a dictionary,
if that dictionary has an entry for the given function with a value
other than <strong class="code">None</strong>, that function is going to be interactive on the
Emacs side.  Here is how the preceding example should be written for an
older version of Python, or when portability is at premium:</p>
<pre class="literal-block">
from Pymacs import lisp
interactions = &#64;{&#64;}

def hello_world():
    &quot;`Hello world' from Python.&quot;
    lisp.insert(&quot;Hello from Python!&quot;)
interactions[hello_world] = ''
</pre>
<p>One might wonder why we do not merely use <tt class="docutils literal"><span class="pre">lisp.interactive(...)</span></tt>
from within Python.  There is some magic in the Emacs Lisp interpreter
itself, looking for that call <em>before</em> the function is actually entered,
this explains why <tt class="docutils literal">(interactive <span class="pre">...)</span></tt> has to appear first in an Emacs
Lisp <strong class="code">defun</strong>.  Pymacs could try to scan the already compiled
form of the Python code, seeking for <tt class="docutils literal">lisp.interactive</tt>, but as the
evaluation of <strong class="code">lisp.interactive</strong> arguments could get arbitrarily
complex, it would a real challenge un-compiling that evaluation into
Emacs Lisp.</p>
</div>
<div class="section" id="key-bindings">
<h2><a class="toc-backref" href="#id40">5.6&nbsp;&nbsp;&nbsp;Key bindings</a></h2>
<p>An interactive function may be bound to a key sequence.</p>
<p>To translate bindings like <tt class="docutils literal"><span class="pre">C-x</span> w</tt>, say, one might have to know a
bit more how Emacs Lisp processes string escapes like <tt class="docutils literal"><span class="pre">\C-x</span></tt> or
<tt class="docutils literal"><span class="pre">\M-\C-x</span></tt> in Emacs Lisp, and emulate it within Python strings, since
Python does not have such escapes.  <tt class="docutils literal"><span class="pre">\C-L</span></tt>, where L is an upper case
letter, produces a character which ordinal is the result of subtracting
0x40 from ordinal of <tt class="docutils literal">L</tt>.  <tt class="docutils literal">\M-</tt> has the ordinal one gets by adding
0x80 to the ordinal of following described character.  So people can
use self-inserting non-ASCII characters, <tt class="docutils literal">\M-</tt> is given another
representation, which is to replace the addition of 0x80 by prefixing
with `ESC', that is 0x1b.</p>
<!-- ` -->
<p>So <tt class="docutils literal"><span class="pre">\C-x</span></tt> in Emacs is 'x18' in Python.  This is easily found, using
an interactive Python session, by giving it: chr(ord('X') - ord('A') +
1).  An easier way would be using the <strong class="code">kbd</strong> function on the Emacs
Lisp side, like with lisp.kbd('C-x w') or lisp.kbd('M-&lt;f2&gt;').</p>
<p>To bind the F1 key to the <strong class="code">helper</strong> function in some
<strong class="code">module</strong>:</p>
<pre class="literal-block">
lisp.global_set_key((lisp.f1,), lisp.module_helper)
</pre>
<p><tt class="docutils literal">(item,)</tt> is a Python tuple yielding an Emacs Lisp vector.
<tt class="docutils literal">lisp.f1</tt> translates to the Emacs Lisp symbol <strong class="code">f1</strong>.  So, Python
<tt class="docutils literal">(lisp.f1,)</tt> is Emacs Lisp <tt class="docutils literal">[f1]</tt>.  Keys like <tt class="docutils literal"><span class="pre">[M-f2]</span></tt> might
require some more ingenuity, one may write either <tt class="docutils literal"><span class="pre">(lisp['M-f2'],)</span></tt> or
<tt class="docutils literal">(lisp.M_f2,)</tt> on the Python side.</p>
</div>
</div>
<div class="section" id="debugging">
<h1><a class="toc-backref" href="#id41">6&nbsp;&nbsp;&nbsp;Debugging</a></h1>
<div class="section" id="on-the-communication-protocol">
<h2><a class="toc-backref" href="#id42">6.1&nbsp;&nbsp;&nbsp;On the communication protocol</a></h2>
<p>Initially, the Pymacs communication protocol was rather simple deep
down, merely using evaluation on arrival on both sides.  All the rest
was recursion trickery over that simple idea.  But the magic was fragile
to interruption requests, so the protocol has been revisited a bit so
each message action could be recognized before evaluation is attempted.
The idea (not fully implemented yet) is to make the protocol part immune
to interruptions, but to allow evaluations themselves to be interrupted.</p>
<blockquote>
<ul class="simple">
<li>As it is more easy to generate than to parse, and also because Emacs
has a Lisp parser and Python has a Python parser, Emacs generates
Python code when preparing a message to the Pymacs helper, and Python
generates Emacs Lisp expressions when preparing a message for Emacs.</li>
<li>Messages are exchanged in strictly alternating directions (from
Python to Emacs, from Emacs to Python, etc.), the first message being
sent by the Pymacs helper just after it started, identifying the
current Pymacs version.</li>
<li>Messages in both directions have a similar envelope.  Each physical
message has a prefix, the message contents, and a newline.  The
prefix starts with either <tt class="docutils literal">&lt;</tt> or <tt class="docutils literal">&gt;</tt> to mark the directionality,
immediately followed by the decimal expression of the contents length
counted in characters, immediately followed by a single horizontal
tab.  The count excludes the prefix, but includes the newline.</li>
<li>In each direction, messages are made up of two elements: an action
keyword and a single argument (yet the argument may sometimes be
complex).  As a special case, memory cleanup messages, from Python
to Emacs, use four elements: the atom <strong class="code">free</strong>, a list of slot
numbers to free, and then the real action and argument.  This is
because the cleanup is delayed and piggy-backed over some other
message from Python to Emacs.</li>
<li>For Emacs originated messages, the action and the argument are
separated by a space.  For Python originated messages, the action and
the argument are made into a Lisp list.</li>
<li>Most actions in the following table are available in both
directions, unless noted.  The first three actions <em>start</em> a new level
of Pymacs evaluation, the remaining actions end the current level.<ul>
<li><strong class="code">eval</strong> requests the evaluation of its expression argument.</li>
<li><strong class="code">exec</strong> requests the execution of its statement argument (this may
only be received on the Python side).</li>
<li><strong class="code">expand</strong> requests the opening of an Emacs Lisp structure (this may
only be received on the Emacs side).</li>
<li><strong class="code">return</strong> represents the normal reply to a request, the argument
holds the value to be returned (<strong class="code">nil</strong> in case of <strong class="code">exec</strong>).</li>
<li><strong class="code">raise</strong> represents the error reply to a request, the argument
then holds a diagnostic string.</li>
</ul>
</li>
</ul>
</blockquote>
</div>
<div class="section" id="the-pymacs-buffer">
<h2><a class="toc-backref" href="#id43">6.2&nbsp;&nbsp;&nbsp;The <strong class="code">*Pymacs*</strong> buffer</a></h2>
<p>Emacs and Python are two separate processes (well, each may use more
than one process).  Pymacs implements a simple communication protocol
between both, and does whatever needed so the programmers do not have
to worry about details.  The main debugging tool is the communication
buffer between Emacs and Python, which is named <strong class="code">*Pymacs*</strong>.  By
default, this buffer gets erased before each transaction.  To make good
debugging use of it, first set <strong class="code">pymacs-trace-transit</strong> to either
<strong class="code">t</strong> or to some <tt class="docutils literal">(KEEP . LIMIT)</tt>.  As it is sometimes helpful to
understand the communication protocol, it is briefly explained here,
using an artificially complex example to do so.  Consider:</p>
<pre class="literal-block">
(pymacs-eval &quot;lisp('(pymacs-eval \&quot;repr(2L**111)\&quot;)')&quot;)
&quot;2596148429267413814265248164610048L&quot;
</pre>
<p>Here, Emacs asks Python to ask Emacs to ask Python for a simple bignum
computation.  Note that Emacs does not natively know how to handle big
integers, nor has an internal representation for them.  This is why I
use the <strong class="code">repr</strong> function, so Python returns a string representation
of the result, instead of the result itself.  Here is a trace for this
example.  Imagine that Emacs stands on the left and that Python stands
on the right.  The <tt class="docutils literal">&lt;</tt> character flags a message going from Python to
Emacs, while the <tt class="docutils literal">&gt;</tt> character flags a message going from Emacs to
Python.  The number gives the length of the message, including the end
of line.  (Acute readers may notice that the first number is incorrect,
as the version number gets replaced in the example while this manual is
being produced.)</p>
<pre class="literal-block">
&lt;22     (version &quot;0.23&quot;)
&gt;43     eval lisp('(pymacs-eval &quot;repr(2L**111)&quot;)')
&lt;45     (eval (progn (pymacs-eval &quot;repr(2L**111)&quot;)))
&gt;19     eval repr(2L**111)
&lt;47     (return &quot;2596148429267413814265248164610048L&quot;)
&gt;45     return &quot;2596148429267413814265248164610048L&quot;
&lt;47     (return &quot;2596148429267413814265248164610048L&quot;)
</pre>
<p>Python evaluation is done in the context of the <strong class="code">Pymacs.pymacs</strong>
module, so for example a mere <strong class="code">reply</strong> really means
<tt class="docutils literal">Pymacs.pymacs.reply</tt>.  On the Emacs Lisp side, there is no concept of
module name spaces, so we use the <tt class="docutils literal">pymacs-</tt> prefix as an attempt to
stay clean.  Users should ideally refrain from naming their Emacs Lisp
objects with a <tt class="docutils literal">pymacs-</tt> prefix.</p>
<p><strong class="code">reply</strong> and <strong class="code">pymacs-reply</strong> are special functions meant to
indicate that an expected result is finally transmitted. <strong class="code">error</strong>
and <strong class="code">pymacs-error</strong> are special functions that introduce
a string which explains an exception which recently occurred.
<strong class="code">pymacs-expand</strong> is a special function implementing the <tt class="docutils literal">copy()</tt>
methods of Emacs Lisp handles or symbols.  In all other cases, the
expression is a request for the other side, that request stacks until a
corresponding reply is received.</p>
<p>Part of the protocol manages memory, and this management generates some
extra-noise in the <strong class="code">*Pymacs*</strong> buffer.  Whenever Emacs passes a
structure to Python, an extra pointer is generated on the Emacs side to
inhibit garbage collection by Emacs.  Python garbage collector detects
when the received structure is no longer needed on the Python side, at
which time the next communication will tell Emacs to remove the extra
pointer.  It works symmetrically as well, that is, whenever Python
passes a structure to Emacs, an extra Python reference is generated to
inhibit garbage collection on the Python side.  Emacs garbage collector
detects when the received structure is no longer needed on the Emacs
side, after which Python will be told to remove the extra reference.
For efficiency, those allocation-related messages are delayed, merged
and batched together within the next communication having another
purpose.</p>
<p>Variable <strong class="code">pymacs-trace-transit</strong> may be modified for controlling
how and when the <strong class="code">*Pymacs*</strong> buffer, or parts thereof, get erased.</p>
</div>
<div class="section" id="emacs-usual-debugging">
<h2><a class="toc-backref" href="#id44">6.3&nbsp;&nbsp;&nbsp;Emacs usual debugging</a></h2>
<p>If cross-calls between Emacs Lisp and Python nest deeply, an error will
raise successive exceptions alternatively on both sides as requests
unstack, and the diagnostic gets transmitted back and forth, slightly
growing as we go.  So, errors will eventually be reported by Emacs.  I
made no kind of effort to transmit the Emacs Lisp back trace on the
Python side, as I do not see a purpose for it: all debugging is done
within Emacs windows anyway.</p>
<p>On recent Emacses, the Python back trace gets displayed in the
mini-buffer, and the Emacs Lisp back trace is simultaneously shown
in the <strong class="code">*Backtrace*</strong> window.  One useful thing is to allow to
mini-buffer to grow big, so it has more chance to fully contain the
Python back trace, the last lines of which are often especially useful.
Here, I use:</p>
<pre class="literal-block">
(setq resize-mini-windows t
      max-mini-window-height .85)
</pre>
<p>in my <tt class="file docutils literal">.emacs</tt> file, so the mini-buffer may use 85% of the screen,
and quickly shrinks when fewer lines are needed.  The mini-buffer
contents disappear at the next keystroke, but you can recover the Python
back trace by looking at the end of the <strong class="code">*Messages*</strong> buffer.  In
which case the <strong class="code">ffap</strong> package in Emacs may be yet another friend!
From the <strong class="code">*Messages*</strong> buffer, once <strong class="code">ffap</strong> activated, merely
put the cursor on the file name of a Python module from the back trace,
and <tt class="docutils literal"><span class="pre">C-x</span> <span class="pre">C-f</span> RET</tt> will quickly open that source for you.</p>
</div>
<div class="section" id="auto-reloading-on-save">
<h2><a class="toc-backref" href="#id45">6.4&nbsp;&nbsp;&nbsp;Auto-reloading on save</a></h2>
<p>I found useful to automatically <strong class="code">pymacs-load</strong> some Python files
whenever they get saved from Emacs.  This can be decided on a per-file
or per-directory basis.  To get a particular Python file to be reloaded
automatically on save, add the following lines at the end:</p>
<pre class="literal-block">
# Local Variables:
# pymacs-auto-reload: t
# End:
</pre>
<p>Here is an example of automatic reloading on a per-directory basis.
The code below assumes that Python files meant for Pymacs are kept in
<tt class="file docutils literal">~/share/emacs/python</tt>:</p>
<pre class="literal-block">
(defun fp-maybe-pymacs-reload ()
  (let ((pymacsdir (expand-file-name &quot;~/share/emacs/python/&quot;)))
    (when (and (string-equal (file-name-directory buffer-file-name)
                             pymacsdir)
               (string-match &quot;\\.py\\'&quot; buffer-file-name))
      (pymacs-load (substring buffer-file-name 0 -3)))))
(add-hook 'after-save-hook 'fp-maybe-pymacs-reload)
</pre>
</div>
<div class="section" id="debugging-the-pymacs-helper">
<h2><a class="toc-backref" href="#id46">6.5&nbsp;&nbsp;&nbsp;Debugging the Pymacs helper</a></h2>
<p>The Pymacs helper is a Python program which accepts options and arguments.
The available options, which are only meant for debugging, are:</p>
<blockquote>
<table class="docutils option-list" frame="void" rules="none">
<col class="option" />
<col class="description" />
<tbody valign="top">
<tr><td class="option-group">
<kbd><span class="option">-d <var>FILE</var></span></kbd></td>
<td>Debug the protocol to FILE</td></tr>
<tr><td class="option-group">
<kbd><span class="option">-s <var>FILE</var></span></kbd></td>
<td>Trace received signals to FILE</td></tr>
</tbody>
</table>
</blockquote>
<ul class="simple">
<li>The <tt class="docutils literal"><span class="pre">-d</span></tt> option saves a copy of the communication protocol in the
given file, as seen from the Pymacs helper.  The file should be fairly
identical to the contents of the <strong class="code">*Pymacs*</strong> buffer within Emacs.</li>
<li>The <tt class="docutils literal"><span class="pre">-s</span></tt> option monitors most signals received by the Pymacs helper
and logs them in the given file.  Each log line merely contains a signal
number, possibly followed by a star if the interruption was allowed in.
Besides logging, signals are usually ignored.</li>
</ul>
<p>The arguments list directories to be added at the beginning of the
Python module search path, and whenever Emacs launches the Pymacs
helper, the contents of the Emacs Lisp <strong class="code">pymacs-load-path</strong> variable
is turned into this argument list.</p>
<p>The Pymacs helper options may be set through the <strong class="code">PYMACS_OPTIONS</strong>
environment variable.  For example, one could execute something like:</p>
<pre class="literal-block">
export PYMACS_OPTIONS='-d /tmp/pymacs-debug -s /tmp/pymacs-signals'
</pre>
<p>in a shell (presuming <strong class="code">bash</strong> here) and start Emacs from that shell.
Then, when Emacs will launch the Pymacs helper, the above options will
be obeyed.</p>
</div>
</div>
<div class="section" id="about-and-around-pymacs">
<h1><a class="toc-backref" href="#id47">7&nbsp;&nbsp;&nbsp;About and around Pymacs</a></h1>
<div class="section" id="known-limitations">
<h2><a class="toc-backref" href="#id48">7.1&nbsp;&nbsp;&nbsp;Known limitations</a></h2>
<p>Memory may leak in some theoretical circumstances (I say theoretical,
because no one ever reported this as being an actual problem).  As
Richard Stallman once put it (2002-08):</p>
<blockquote>
<cite>I wonder, though, can this</cite> [memory management] <cite>technique fully handle
cycles that run between Lisp and Python?  Suppose Lisp object A refers
to Python object B, which refers to Lisp object A, and suppose nothing
else refers to either one of them.  Will you succeed in recognizing
these two objects as garbage?</cite></blockquote>
</div>
<div class="section" id="history">
<h2><a class="toc-backref" href="#id49">7.2&nbsp;&nbsp;&nbsp;History</a></h2>
<p>I once hungered for a Python-extensible editor, so much so that I
pondered the idea of dropping Emacs for other avenues, but found nothing
much convincing.  Moreover, looking at all Lisp extensions I'd made
for myself, and considering all those superb tools written by others,
all of which are now part of my computer life, it would have been a
huge undertaking for me to reprogram these all in Python.  So, when I
began to see that something like Pymacs was possible, I felt strongly
motivated! :-)</p>
<p>Pymacs draws on previous work of Cedric Adjih that enabled
the running of Python as a process separate from Emacs.
See <a class="reference external" href="http://www.crepuscule.com/pyemacs/">http://www.crepuscule.com/pyemacs/</a>, or write Cedric at
<a class="reference external" href="mailto:adjih-pam&#64;crepuscule.com">mailto:adjih-pam&#64;crepuscule.com</a>.  Cedric presented <strong class="code">pyemacs</strong> to me
as a proof of concept.  As I simplified that concept a bit, I dropped
the <tt class="docutils literal">e</tt> in <tt class="docutils literal">pyemacs</tt> :-). Cedric also previously wrote patches for
linking Python right into XEmacs, but abandoned the idea, as he found
out that his patches were unmaintainable over the evolution of both
Python and XEmacs.</p>
<p>As Brian McErlean independently and simultaneously wrote a tool
similar to this one, we decided to merge our projects.  In an amusing
coincidence, he even chose <strong class="code">pymacs</strong> as a name.  Brian paid
good attention to complex details that escaped my courage, so his
help and collaboration have been beneficial.  You may reach Brian at
<a class="reference external" href="mailto:brianmce&#64;crosswinds.net">mailto:brianmce&#64;crosswinds.net</a>.</p>
<p>The initial throw at Pymacs has been written on 2001-09-05, and releases
in the 0.x series followed in a rapid pace for a few months, and Pymacs
became stable.  Since then, it did not need to move much, as bugs are
not found often.  Yet, in my opinion, some missing features should be
addressed before we dare some 1.0 release.</p>
</div>
<div class="section" id="pymacs-and-me">
<h2><a class="toc-backref" href="#id50">7.3&nbsp;&nbsp;&nbsp;Pymacs and me!</a></h2>
<p>Pymacs has been fairly stable since the early versions.  I surely used
it a great deal, constantly, magically, in my daily works, to the point
of forgetting that was it there all the time.  It was fairly complete,
at least for my own needs, and did not move much anymore.</p>
<p>Some time later, someone begged me to consider Vim, and not only Emacs,
for some tools I was then writing.  Looking at Vim more closely, I
discovered that it is a worth editor, with Python nicely integrated,
enough for me to switch.  In a <a class="reference external" href="http://pinard.progiciels-bpi.ca/opinions/editors.html">Web article</a> (which many enjoyed, as
they told me), I detailed my feelings on these matters.</p>
<p>My viewpoint is that Pymacs, maybe after an initial flurry of a bit more
than a dozen releases, soon became stable in its history.  Reported
bugs or suggestions were minor, there was not enough new material to
warrant other releases.  Nevertheless, when I switched from Emacs to
Vim in my day-to-day habits, I felt that Pymacs needed a more credible
maintainer than me.  Syver Enstad, who was an enthusiastic user and
competent contributor, was kind enough to accept the duty (2003-10).
Some more bugs and suggestions flowed in since then, but Syver did not
elect to make any new release, and this did not bother me.  Syver then
became unavailable, to the point I could not contact him in years.  I
would loathe to see myself interfering with an official maintainer,
but when I decided to return to some moderate Emacs usage, and because
of the long silence, I considered resuming Pymacs maintenance as well
(2007-11).  Then, I dived into it for real (2008-01).</p>
<p>Giovanni Giorgi once (2007-03) wanted to expand on Pymacs and publish
it on his own, and later felt like maintaining it whole (late 2007-12).
I rather suggested an attempt at collaborative maintenance, and this
experiment is still going on...</p>
</div>
<div class="section" id="vim-considerations">
<h2><a class="toc-backref" href="#id51">7.4&nbsp;&nbsp;&nbsp;Vim considerations</a></h2>
<p>Emacs Lisp is deeply soldered into Emacs internals.  Vim has its own
language, which people sometimes call Vimscript, similarly tightened
into Vim.  My feeling is that Emacs Lisp allows for a more intimate
handling of edit buffers and external processes than Vimscript does, yet
this intimacy has a price in complexity, so all totalled, they may be
perceived as comparable for most practical purposes.</p>
<p>Pymacs allows customising Emacs with Python instead of Emacs Lisp, and
then runs Python as a process external to Emacs, with a communication
protocol between both processes.  Python may be built into Vim, and then
both Python and Vim use a single process.  The same as Pymacs gives
access to almost all of Emacs Lisp, Python within Vim gives access to
almost all of Vimscript, but with a much smaller overhead than Pymacs.</p>
<p>Pymacs is not Emacs Lisp, and Python in Vim is not Vimscript either,
tweaks are needed in both cases for accessing some of the underlying
scripting facilities.  Pymacs is rather elegant, Python in Vim is rather
clean.  Python itself is both elegant and clean, but one strong point of
Python for me is the legibility, which builds deeper roots on the clean
side than on the elegant side.  All in all, despite I know how debatable
it can be, I guess I now have a prejudice towards Python in Vim.</p>
<p>I figured out a simple way to have the same Python source usable both
within Pymacs or Vim.  However, Emacs is byte oriented, while Vim is
line oriented.  In a few Pymacs applications of mine, I internally
toggle between line orientation and byte orientation, keeping both for
speed most probably, while I see things would be a bit simpler (and
maybe slower) if I was pushing myself on the line-oriented side.  Each
of Emacs and Vim have their own logic and elegance, and it is probable
that we loose overall if we try to emulate one with the other.</p>
<p>The idea traversed me to convert all the few Pymacs examples so they
work both for Pymacs and Vim, and through the documentation, publicise
how people writing Python extensions could write them for both editors
at once.  Yet, while doing so, one has to stretch either towards Emacs
or Vim, and I guess I would favour Vim over Emacs when the time comes to
evaluate efficiency-related choices.</p>
<p>I also thought about writing a Pymacs module for running Python scripts
already written for Vim, by offering a compatibility layer.  The
complexity of this might be unbounded, I should study actual Python
scripts for Vim before knowing better if this is thinkable or not.</p>
</div>
<div class="section" id="inclusion-within-emacs">
<h2><a class="toc-backref" href="#id52">7.5&nbsp;&nbsp;&nbsp;Inclusion within Emacs</a></h2>
<p>Gerd Möllman, who was maintaining Emacs at the time of Pymacs birth and
development, retrofitted (2001-09) the idea of a <strong class="code">post-gc-hook</strong>
from XEmacs, as a way to facilitate memory management within Pymacs.</p>
<p>Richard Stallman once suggested (2001-10) that Pymacs be distributed
within Emacs, and while discussing the details of this, I underlined
small technical difficulties about Emacs installing the Python parts,
and the need of a convention about where to install Python files meant
for Pymacs.  As Richard felt, at the time, very overwhelmed with other
duties, no decision was taken and the integration went nowhere.</p>
<p>After Gerd resigned as an Emacs maintainer, someone from the Emacs
development team wrote again (2002-01) asking information about how
to integrate Pymacs.  It was easy for me to write a good and thorough
summary, after all these discussions with Richard.  And that's the end
of the story: I never heard of it again. :-)</p>
</div>
<div class="section" id="speed-issues">
<h2><a class="toc-backref" href="#id53">7.6&nbsp;&nbsp;&nbsp;Speed issues</a></h2>
<p>Doug Bagley's shoot out project compares the relative speed of many
popular languages, and this might interest Pymacs users.  The first URL
points to the original, the second points to a newer version oriented
towards Win32 systems, the third is more recent but Debian-oriented:</p>
<blockquote>
<ul class="simple">
<li><a class="reference external" href="http://www.bagley.org/~doug/shootout/">http://www.bagley.org/~doug/shootout/</a></li>
<li><a class="reference external" href="http://dada.perl.it/shootout/index.html">http://dada.perl.it/shootout/index.html</a></li>
<li><a class="reference external" href="http://shootout.alioth.debian.org/">http://shootout.alioth.debian.org/</a></li>
</ul>
</blockquote>
<p>I've not heard of any Python to Lisp compiler.  Lisp may be slow or fast
depending on how one uses it, and how much one uses declarations.  Some
Lisp systems have really excellent compilers, that give very fast code
when properly hinted.</p>
<p>Python itself may be slow or fast, once again depending on how one
uses it.  With the proper bend, one can develop the habit of writing
Python which shows honest speed.  And there is always Pyrex, which is
Python complemented with explicit declarations (a bit like some Lisp
implementations), and which can buy a lot of speed.</p>
<p>This is quite likely that one can have fast programs while using Python,
or a mix of Python and Pyrex (or even Psyco sometimes), that is, within
Python paradigms, without feeling any need of resorting to Lisp.</p>
<p>If Python looks like being slow while being used with Emacs, the problem
probably lies in Emacs-Python communication which Pymacs implements.
One has to learn how to do the proper compromises for having less
communications.  (In that regard, Vim and Python are really linked
together, so Python in Vim is likely faster than Pymacs for someone who
does not pay special attention to such matters.)</p>
<p>Ali Gholami Rudi also writes (2008-02):</p>
<blockquote>
<p><cite>Well, there seems to be lots of overhead when transferring large
strings.  Transferring them requires:</cite></p>
<blockquote>
<ol class="arabic simple">
<li><cite>escaping characters in the strings</cite></li>
<li><cite>putting them in</cite> <strong class="code">*Pymacs*</strong> <cite>buffer</cite></li>
<li><cite>sending the region to Python process</cite></li>
<li><cite>evaluating the Python string in Python-side (involves compiling)</cite></li>
</ol>
</blockquote>
<p><cite>In my experiments, transferring a ~5k-line file takes more than a
second on a relatively new computer (data from</cite> <strong class="code">rope-dev</strong><cite>).
Improving that probably requires a new protocol that does not
use Python eval and has an optional debug buffer.  Probably few
applications need to transfer large strings to Python but if they do,
it is quite slow.</cite></p>
</blockquote>
<p>All in all, speed may sometimes become a real issue for Pymacs.  I once
wrote within <a class="reference external" href="http://pinard.progiciels-bpi.ca/opinions/editors.html">http://pinard.progiciels-bpi.ca/opinions/editors.html</a> :</p>
<blockquote>
<cite>While Pymacs is elegant in my opinion, one cannot effectively use
Pymacs (the Python part) without knowing at least the specification
of many Lisp functions, and I found that it requires some doing for a
Pymacs developer to decouple the Emacs interaction part from the purer
algorithmic part in applications.  Moreover, if you do not consider
speed issues, they bite you.</cite></blockquote>
</div>
<div class="section" id="the-future-of-pymacs">
<h2><a class="toc-backref" href="#id54">7.7&nbsp;&nbsp;&nbsp;The future of Pymacs</a></h2>
<p>Some people suggested important internal Pymacs changes.  In my opinion,
new bigger features are better implemented in a careful way, first as
examples or contributions, and moved closer to internal integration
depending on how users use or appreciate them.  For now, Pymacs should
concentrate at doing its own humble job well, and resist bloat.</p>
<p>Before Pymacs closes to some version 1.0, some specifications should be
revisited, user suggestions pondered, porting matters documented.  The
test suite should grow up, we should collect more examples.  Pymacs
should aim seamless integration with <tt class="file docutils literal">.el</tt> files and with
transparent <strong class="code">autoload</strong> (my little tries were not so successful).
On the Python side, Pymacs <em>might</em> fake primitives like <strong class="code">getindex</strong>
and <strong class="code">putindex</strong>, better support iterators and some newer Python
features, and at least consider Python 3.0.</p>
<p>Pymacs is not much geared towards Python threads.  It is not clear yet if
it would be reasonably tractable to better support them.</p>
</div>
</div>
</div>
</body>
</html>
pymacs 0.23-1.2 / usr / share / doc / pymacs / html / pymacs.html
