It has been a while since I last talked about
Ezbl, my Emacs interface for the excellent
Uzbl browser.
I have moved far beyond simply being able to embed the browser in Emacs, and have added resizable windows, custom mode-line text, and most importantly, a cookie handler. The only major piece which still needs work is the keyboard input, since the only way to get text into Uzbl at this point is to paste it in with the mouse. I have some ideas on how to move forward; most involve wacky hacks with the DOM, so we'll see what turns up.
The next big push will be taking advantage of the new-ish Uzbl events system, so I don't have to do as much polling. Profiling Ezbl (with the built-in "elp" package) when loading Yahoo.com and a few Twitter pages gives the following, rather uninspiring result:
Yes, it really is spending 77 seconds of CPU time on
ezbl-sync-request, and yes, that is TERRIBLE. Luckily, I know how to move forward. I had been using a reasonably clever (but apparently horribly inefficient) system for making synchronous requests to Uzbl (for getting the value of a variable, for example). Emacs has a number of built-in ways of doing this, but I am thinking that with Uzbl's event system, I can just store the value of all the Uzbl variables within Emacs (there aren't that many) and update them on the Emacs side whenever they change. This way, I'm not having to do an expensive query to Uzbl each time I want to update the mode-line, for example.
In other news, I worked (if you can call it that, it was about 4 lines of braindead-simple code) on a patch to Emacs to add support for the
SOCK_SEQPACKET socket type. Since Uzbl uses
SOCK_SEQPACKET for its cookie sockets, having this work was essential for being able to communicate with Uzbl (without having to patch Uzbl, which I wasn't keen on doing). There are plenty of problems with the
SOCK_SEQPACKET patch to Emacs, not the least of which is that it only works for Unix domain sockets, and not actual network sockets. Bummer.
If anyone is comfortable (or at least competent, which excludes me) with SCTP, Emacs could use some expertise in adding
SOCK_SEQPACKET over
AF_INET sockets. It's a rarely-used but useful protocol, and it's a shame that there is something which exists that Emacs doesn't yet support :).
Stay tuned for more!
Yes, it really is spending 77 seconds of CPU time on 
Any chances that Ezbl will ever run on Emacs within Windows?
ReplyDeleteWell, Ezbl itself does not have much in the way of Linux-specific stuff in it, but the things it relies on do. I don't think Uzbl runs on Windows yet, so obviously that would have to change before one could even think about Windows support.
ReplyDeleteOther than that, the only things I can think of that would need any kind of porting are the xwidget support (which lets Uzbl embed in an Emacs buffer), and local socket connections. The local sockets are used only for communicating with Uzbl's cookie handler, and it looks like they are making some changes which might obviate the need for using sockets there, i.e. communicating over STDOUT. The larger part is the xwidget support, though Ezbl is doing little more than saying "embed this process in this buffer," so if some sort of embedding support came to Windows, it would be pretty simple to get Ezbl to use it.
In short, the biggest thing would be to get Uzbl running on Windows, followed by some way to embed arbitrary windows within Emacs buffers under Windows. I don't really have anything to do with either of those things, so I don't know how likely either of them are. Should they both be resolved, I would definitely be up for working on Windows support, though Linux support (along with it working at all :) is definitely my priority.