Emacs has a very simple interface to some libxml2 functionality. It is used by gnus, and also for D-Bus support. It looks like a simple port to an XEmacs module. Attached is a candidate patch, for discussion purposes. There are no changelog entries or documentation updates in it, but those will be forthcoming when I propose this for inclusion. A few of the changes need explaining. The libxml2 headers define ATTRIBUTE_UNUSED, and their definition clashes with ours, hence the change to src/compiler.h. A few more symbols need to be exposed to modules. Also, I need to pass -I/usr/include/libxml2 in CPPFLAGS on Fedora, but CPPFLAGS wasn't being passed down to module builds. Finally, I'm not totally happy with the way I have to convert a portion of a buffer to a Lisp string, and then convert the Lisp string to an externally encoded block of memory. Is there some way of skipping that middle step, and producing a memory block in an external encoding from a portion of a Lisp buffer? I couldn't find one. Comments welcome. -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On Tue, Feb 5, 2013 at 8:46 AM, Robert Pluim <rpluim(a)gmail.com&gt; wrote: > Hi, > > I had to make the attached changes to get it to compile for me on cygwin. I understand the second hunk, but that first hunk can't possibly be right. The first argument to get_buffer_range_char is a "struct buffer *", which current_buffer is. Fcurrent_buffer, on the other hand, is a lisp function. Or was that supposed to be Fcurrent_buffer()? That still isn't right, as it returns a Lisp object that wraps a "struct buffer *". I suspect the problem is the same one as for the second hunk: current_buffer is not exposed to modules. Try adding current_buffer to src/xemacs.def.in.in instead. I'll add that to the next iteration of this patch.

> I gave it a quick test with shr in gnus, which caused a spectacular crash, > but the loading & running of libxml2 seems fine. Might the crash have been due to the problem with the first hunk of the patch?

I'd really like this to be general-purpose ...

... 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?

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.

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) loops).

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).