Re: [Bug-zile] Nested buffers

[Reuben Thomas]

On 15 February 2014 05:09, Gary V. Vaughan <address@hidden> wrote:

Well, I dunno :)  Maybe, if I understood your vision better I'd be able to say :-p

As I understand it right now, it may at least be a way to have a shell mode that recognizes output from grep or the compiler and enable different highlighting and keymaps in the relevant parts of the buffer.

The organization that I thought of is that, in the abstract, data (or, less abstractly, data types) carry their own editor with them. These editors can be embedded in a terminal which is really just a different sort of directory viewer: each command corresponds to a file in a directory (it would be nice, BTW, if one could get at and manipulate the "real" order of entries in a directory, rather than be forced to sort on metadata; this is one of two classes of extensions to POSIX file system semantics I'd like to see, the other being the ability to insert and remove bytes from a file).

Taking a step back, you could run this viewer on a normal directory, and effectively it'd be a zooming interface: focussing or zooming in to a given file, you'd get the editor for the corresponding MIME type (or however you determine data type: you might for example want a simpler viewer for read-only JPEGs and an editor for writable JPEGs).

The terminal program goes one stage further: a terminal history is just a directory of files each of which contains a command, and corresponding output, which are bound together. Basically more of a convention about paired files than anything else. Editing a command and rerunning it recalculates the output.

Does that make more sense now?

Guile is gigantic these days.

Meh. Someone filed a bug against Fontforge saying that for a simple job (load a font and output a TTF version) it has gone from requiring 500Mb in a version from mid-2012 to requiring 1.1Gb RAM in a version from this January. This is about right: I measure more like 740Mb and 1.2Gb; and a HEAD version requires 2.2Gb RAM, using libgc. However, I'm not sure it matters, and it's much hungrier than Guile.

Anyway, judging Guile by its own standards, it's supposed to be a ubiquitous GNU extension language, so it shouldn't much matter how big it is. On my machine the guile-2.0-libs package, which contains most of it, is 10.6Mb. That's less than half the size of Firefox on my phone.

 

 But I take your point.  In my defense, I'm not at all sure it would be any easier or faster to figure out how to integrate an existing Lisp implementation into zmacs along with all the Elisp functions and compatibility than to enhance the existing implementation...

But much more interesting for the future: you'd be tapping into an existing community (and giving something important to it) rather than starting another one.

--

http://rrt.sc3d.org