From: David E. <dm...@dm...> - 2016-01-25 07:24:29
|
On Sun, Jan 24 2016, Magnus Henoch <mag...@gm...> wrote: > [...] > > Thanks for fixing this! I've merged and pushed your patch. It > should show up in MELPA soon. Thanks for the original code! > Hm, that looks like it might work... It doesn't immediately. xml.el doesn't look to be structured to easily support the kind of interface that would seem useful here. The first thing that all of the parsing routines do is copy the region to be parsed to a temporary buffer, which the parser is then free to modify. As a result, when the parsing is complete, we don't really have any clue how much of the original buffer should be removed (or perhaps more usefully, how far in the original buffer we should move point such that it is past the term being returned). Setting `xml-sub-parser' to `t' would allow the use of the parser in the case where there is more than a single term in the buffer. Of course, this would require some re-structuring of the loop that handles the terms that arrive from the server (because a single call to `xml-parse-region' will then return multiple terms and we have to loop through processing them). How an incomplete term is handled in this case might well be problematic - if the first term in the buffer is complete but a subsequent term is not (still waiting on data from the network, for example), error recovery will be "interesting". > I haven't really looked into improving the Emacs xml library, since in > any case I would want jabber.el to work with earlier versions, but > that's a bit of a fallacy: if I'd done something about this a few > years ago, I'd probably feel comfortable requiring a modern xml.el > now. If we were to extend the interface provided by xml.el slightly, we could presumably detect the availability of the updated interface in jabber.el and use newly provided functionality when it is available. > I started looking at something similar: Emacs 24.1 added support > for linking with libxml2, but this is not currently usable for > jabber.el for two reasons: it drops namespaces, and it returns > `nil' both for parse errors and for incomplete stanzas - in the > former case, we need to signal an error, but in the latter case, > we just wait for more data. I started working on the interface in > this branch: > > https://github.com/legoscia/emacs/commits/xml-return-errors > > but I didn't manage to finish it. The error behaviour seems generally problematic for any code trying to use such an interface, so perhaps it could be changed. > Alas, lack of free time hampers my progress on these things (I > also want to finish my optimisations of roster redrawing, which > seems to be the major performance bottleneck with rosters with a > few hundred items.) Understood. > If anyone would like to test the xml-sub-parser change, just to make > sure there's no weird edge-case where it breaks, I'd be very happy to > have it. The simple approach that I initially suggested is definitely insufficient - more extensive changes would be required, see above. > I just split that part of the code out into a separate function, > jabber-xml-parse-next-stanza, so that it's easy to change in > isolation, and added two simple test cases for it. I'm not sure > when I'll have time to pick this up again, so feel free to grab it > :) I will continue to look at it when I have time. |