On Tue, Feb 5, 2013 at 10:42 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
I'd really like this to be general-purpose ...
Yes, I would also.
... although Emacs compatibility (unfortunately) really has to be
given priority. Just how crappy is the Emacs API from the point of
view of eventually exposing a useful generic XML API to Lisp?
Very. I'm looking into exposing a more general API right now. I'll
float another patch as soon as I figure something out.
It would be a utility function named something like
buffer_to_Lisp_Opaque or perhaps you can use a DFC_ macro (text.h or
maybe text.c) if it exists.
Well, I found this in text.h:
#define eicpy_lbuf(eistr, lisp_buf, off, charoff, len, charlen) \
NOT YET IMPLEMENTED
The DFC macros that interact with buffers all seem to write to
buffers, not read from them. I'll have to see what I can whip up that
fits into the framework.
If not, it shouldn't be too hard to generalize
DFC_LISP_STRING_TO_EXTERNAL to handle buffers (I think you just need
to deal with the gap, and the gap respects character boundaries so it
should be simple: one (conceptual) loop for the price of two (real)
Okay, I'll try to figure it out.
I'll try to take a look at the patch itself over the weekend.
BTW, in the near future I'm going to propose my libcurl and neon
modules for inclusion, along with a support module I call earl (Emacs
Augmented Resource Locators, although I'm really tempted by eerie --
EERIE is Extended Resource Identifiers for Emacsen).
Sounds great. I'm happy to review when you have something ready to show.
XEmacs-Beta mailing list