emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] [PATCH] Emacs Org Babel Scheme (Geiser) support


From: Bruno Félix Rezende Ribeiro
Subject: [O] [PATCH] Emacs Org Babel Scheme (Geiser) support
Date: Mon, 5 Aug 2013 20:05:18 -0300

           _________________________________________________

            [PATCH] EMACS ORG BABEL SCHEME (GEISER) SUPPORT

                      Bruno Félix Rezende Ribeiro
           _________________________________________________


This is a patch submission for the Emacs Org Babel Scheme support,
Geiser based, implementation (file ob-scheme.el).  It achieves the
following:

1. Removes the restriction on evaluated code's top-level definitions
   introduced in the major rewrite to support Geiser[1].  The previous
   evaluation procedure used to wrap the whole code in a
   `(with-output-to-string ...)' form before sending it to Geiser.  A
   more robust technique is employed in the evaluation procedure
   avoiding such arguable bugs that results from the artificial wrapping
   of code.  Now the Scheme code is not modified in any way before being
   interpreted by the REPL.  For instance it is possible to use the so
   common and necessary `(define ...)' top level statements[2].
2. A more sound and reliable communication mechanism is employed to
   process the return value, output and error yielded by the REPL and
   reported by Geiser to ob-scheme[3].  Previously ob-scheme and Geiser
   did communication over the echo area.[4] That behavior leads to
   inconsistent results when debugging code and potentially broken code
   if a minor change in Geiser's echo area output syntax were made[5].
3. Taking advantage of the new communication mechanism described in the
   previous item the evaluation error handling logic is extended to
   report REPL error messages directly into the result blocks instead of
   the ubiquitous and uninformative "An error occurred."  message.
4. Frame window configuration restitution measures are implemented to
   prevent that Geiser spawns a persistent[6] window for each new
   invoked REPL session[7][8].

This patch has been tested only with Guile's Scheme implementation.  But
inasmuch ob-scheme does not interface directly to interpreters, but
rather to Geiser, the code should be implementation agnostic[9].

The ChangeLog follows:

,----
| Babel Scheme:
|
|  * lisp/ob-scheme.el (org-babel-scheme-make-session-name): remove wrap
|    around code to be evaluated and get evaluation result directly from
|    `geiser-eval-region' respecting evaluation error messages and
|    restoring frame's window configuration after it.
|    (org-babel-scheme-get-repl): Restore frame's window configuration
|    after asking Geiser to run the REPL.
|
| These changes fix:
|
| - a major regression from the older implementation that prevents code
|   with top-level definitions from being correctly evaluated.
| - the mechanism of communication with Geiser (before did over the echo
|   area).
| - a bug of reference to a nonexistent echo area message that occurred
|   whenever debugging (edebug) `org-babel-scheme-make-session-name'.
| - the report of evaluation errors.
| - the intrusive creation of REPL windows.
`----

Thank you for your contribution to Free Software.  Best regards.

*Ps:*

- The ChangeLog entry is already included in the commit for Org
  maintainers' pleasure.
- Since the changes made sums up to more than 15 lines, so it does not
  classify as "tiny change", and the code changed is part of Org's core,
  I will probably need to sign a FSF copyright assignment.  That will be
  no burden as I pretend to contribute to GNU Emacs whenever possible.



Footnotes
_________

[1] See [{O} {PATCH} Babel support for scheme using geiser]
(https://lists.gnu.org/archive/html/emacs-orgmode/2013-01/msg00134.html).

[2] In fact, that is the main and original motivation behind this
patch.  Believe it or not the new ob-scheme implementation failed on
my first attempt to evaluate a snippet of scheme that happens to be
the result of the resolution of the first question of the famous [SICP
- Structure and Interpretation of Computer Programs]
(https://mitpress.mit.edu/sicp/sicp.html).  Odd is the fact that it is
a deliberated regression from the older implementation (cf. [1]).

[3] Now it uses the return value of a `geiser-eval-region' call which
is a loose association list containing all information needed.

[4] The echo area message was used by ob-scheme to detect an error on
evaluation and to transform valid result or output into a lisp object.

[5] It was impossible to debug the whole
`org-babel-scheme-execute-with-geiser' procedure because it relied on
the Geiser's echo area output that was generated several forms earlier
and, by the echo area's own nature/mechanism, had gone when the
programmer pressed a key to step to the next stop point in the edebug
process.  Whether that is a edebug or ob-scheme bug is arguable, but
certainly to use the echo area to inter-library communication is not a
good programming practice since the echo area is intended just as a
clue feature for human eyes.

[6] By "persistent window" I mean an auxiliary window that is not
removed in the end of the associated procedure's execution.

[7] Thus, for session-less code blocks (the default), it was making a
persistent new window each time one evaluates the respective code.

[8] Using the current implementation of Geiser --- while ensuring a
forward-compatible and clean interface --- it is not feasible to
prevent Geiser's spawns of REPL windows; our best is to prevent its
persistence.

[9] Nevertheless, if you can, please test it with other Scheme
implementation supported by Geiser --- i.e., Racket --- and report
back.


--
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  Linux-libre is just one of its kernels;
     \_/      All software should be free as in freedom;

Attachment: 0001-Babel-Scheme.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]