phf: mircea_popescu: i think that there's a bunch of people trying to chuck moore their way out of "modern computing" here, as such there's not native anything

phf: gabriel_laddel: i'm saying that it's only worthwhile to bring in zen if you want to ultimately do x11 support for foreign code. right now your problem is clim+xlib, you want your problem to be clim+xlib+zen+cl-opengl+glx. if the ultimate goal is drop x, then might as well try and retarget clim to framebuffer. the two (adding zen and framebuffer clim) or at 100% identical in the amount of effort

phf: i know you do clim, but running clim through zen is essentially simultaneously trying to debug two 70% speed/coverage projects. even simple handwritten xlib proggies don't work out of the box.

phf: gabriel_laddel: gnuplot, xfoil kind of output, i.e. batch graphic, or anything that requires input with a mouse

phf: also zen doesn't support most of the modern x11 extensions, that you might want for running something like firefox. in fact last time i checked it didn't support xrander, which is an old image composition extension that might as well be standard

phf: main problem with zen right now is that it does rendering, but it uses opengl (glx specifically) as the framebuffer. i've not looked at the implementation bits, but i assume that it goes beyond simple blit, so you might be able to retarget it to other opengl, but not necessarily straight to framebuffer, without implementing your own blit level rendering primitives

phf: gabriel_laddel: i was drunk when answering you last time. i like the idea of a self-contained lisp system with ux built on top of xproto/xlib/zen, because can still attach c program outputs, and stream own output to unix systems proper. i've been building my own tools to be essentially a combination of cmucl repl, that spawn xlib windows on demand. not sure if you know but x is essentially a binary network protocol (described in