On 13 May 2001, Hrvoje Niksic gibbered: Good, it's not my bizarre roll-yer-own Linux install that's breaking it then. (That's rare. ;) ) Great, that's gone into the term-exec-hook in the site-start here, and my users are happy (and impressed by the speed of the response :) ) Ah. I dunno, it makes a kind of sense; the line ending conversion is in a different dimension to the charset conversion (LF / CRLF / CR, versus ISO-foo / KOI8-R / US-ASCII / who-knows-what)... -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD

On 13 May 2001, Hrvoje Niksic stipulated: Oh, great. :( Sort of like Streams? That would be very nice; it would obsolete big chunks of mailcrypt, jka-compr, uncompress... even term-mode's `term-emulate-terminal', come to think of it. In fact, probably by the time you've got that generic, `input filter' and `output filter' are better terms for this stackable thing than `coding system'. This is sort of a generalization both of coding systems and of the existing asynchronous subprocess filters; almost certainly both of these could be reimplemented in terms of the filter stack. (And maybe, even, my pet dream could come true, and enough of redisplay could be migrated into here to make the lack of Lisp-runnability within the C redisplay code a moot point...) Hmm. One question, actually. The Golden Rules of Redisplay (no GC, no Lisp); are they there because having Lisp touch the *_set variables while redisplay is running could be nasty? If so, why doesn't redisplay take a copy of these variables and work from that copy? (In fact, unless Lisp code *unsets* the *_set variables, I can't see how this could cause any problem... obviously I'm misunderstanding the reason for the Golden Rules.) I really would like a Lisp-mutable redisplay; the unmutability from Lisp of redisplay is one of my three great grouches about XEmacs. (The other grouches are: - the inflexibility of specifiers; you should be able to attach arbitrary Lisp predicates to them; maybe you can, but the docs for them are unclear enough that it's hard to tell... examples would be good ;) I should write some... - the way that XEmacs's C-side data hiding has spawned a million different set- and get- constructs and irritatingly over-opaque data structures. Things like e.g. keymaps should appear to the Lisp layer as directly Lisp-manipulable objects, so that `read' and `print' can work on them. It seems to me that symbol-value-magic symbols have allowed this for a long time, but obviously not, or it'd be implemented... I've got half- completed patches that exploit common-lisp style #x() syntax to do this, so you can set and update many opaque objects from the lisp reader, with the letter indicating the type of formerly opaque object, as in Common Lisp... if you want, I can clean them up (and they'll require a good bit of cleanup; the patches were initially a proof-of-concept, and clean they are not) and submit them. -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD

Hrvoje Niksic wrote: this is half-implemented already in my latest mule ws. i created a "chain" coding system that lets you chain more than one coding system together, and use it to implement mswindows-unicode currently [mswindows-multibyte -> mswindows-multibyte-to-unicode], although eventually this needs to be switched. mswindows-multibyte-to-unicode is thus the first ever coding system that translates between something other than byte->char or char->byte [it's byte->byte]. i need to add some coding system methods to indicate what's at each end of the coding systems, so that incompatible kinds don't get chained together. file-coding is also substantially rewritten so that there are coding-system methods -- i.e. nice abstraction instead of nasty switch statements. not quite done though. in yet another workspace of mine [rotting away, sadly], i completely rewrote the way that errors are trapped internally, so that it's now actually possible to safely run lisp inside of redisplay. in some lifetime i might get around to finishing this workspace up and merging it. [it also implements a separate stderr stream for processes.] -- ben I'm sometimes slow in getting around to reading my mail, so if you want to reach me faster, call 520-661-6661. See http://www.666.com/ben/chronic-pain/ for the hell I've been through.

On 13 May 2001, Hrvoje Niksic stipulated: ... if just to tell Emacs what coding system you've finally *got*. Hmm. Suggestion; the input and output of the filters are typed (perhaps by being a cons cell whose car is a type and whose cdr is a `character'; obviously this is wildly inefficient and wouldn't work for stateful coding systems, but you get the idea) and you can only stack filters where the output type of one filter equals the input type of the one next in the sequence. The name of the output type of the last filter is what XEmacs currently calls the coding system's name. Or is a coding system more than `the output of a transformative program in some language, of a named type'? I'm a generalist past sanity, I know. (But then, exactly that generalizing viewpoint gave us Lisp to start with, and Emacs; there is some merit in it. :) ) That's a reason for discouraging large amounts of Lisp, not for banning it completely. (It's also a reason to speed up parts of the Lisp interpreter, like the funcall path; but I note that things have been happening on that front :) I'm aiming to attack the other nasty Emacs monster, the GC; I hate GCPRO with a passion and I hate the nonincremental GC almost as much, especially on small machines...) Er, why not wrap any invoked Lisp in a condition-case? (Or do you mean flat-out syntactic errors?) I'd rather abolish them completely if possible. Redisplay is complex code, yes, but why should that grant it the right to ban Lisp? (Emacs's power is due to the pervasiveness of Lispability throughout its core, after all... IMHO, the ideal Emacs core would be a really, really fast Lisp engine, glue code to external libraries, and nothing else. Well, not quite. The *ideal* Emacs core would have pluggable languages, but that's a *total* pipe-dream :) maybe by 2010...) That sounds like a good first step ;P The caching, of course, changes what it is sane to do. It seems sensible to make specifiers subject to the rule that the specifiers, and any functions invoked from them, must not modify global state (agh, but that wrecks `gensym'); and also that they should not rely upon global state without care (but of course they can sometimes for user customization; relying on oft-changing variables can be nasty though). This is a right tangle :( I don't. I was just being purist, and I haven't found a nice syntax for keymaps yet; they were just an example. The only objects I got fully happy with were, uh, hash tables, which used a read syntax very similar to yours (and CLs). (I started working on char tables too, but rapidly found that they had a read syntax, just a totally undocumented one.) But the read syntaxes don't have to be *nice*; they just have to be consistent. I happen to think that `read' and `print' are very useful, and the presence of things like `desktop.el' writing out big chunks of Emacs state as Lisp and just `load'ing it back in again tends to support me there :) My keymap syntax was a rather horrible one; you could specify an entire keymap at once via a #k(keyword-args) syntax, where the keyword arguments could be :parents, :default-binding, :prompt, or :contents, where :contents took an alist mapping from a key to a def as in `define-key'. I defined printing a keymap to print out only this C-level keymap, with keymap names representing the keymaps used for key sequences (automatically generated and assigned to them if necessary; yes, this meant `print' could modify objects, and I hated it). I could alternatively have had it print out the entire stack of keymaps, but that would have meant that sub-keymaps would lose their identity. (Perhaps I should have made it configurable.) Now it's true that the input side of this could all have been done with a little `make-entire-keymap' wrapper, but I couldn't have got them printed that way; at least, not by `print'. And it would have been less regular, and regularity is the essence of Lisp. (And it was a fun hack.) Agreed; this is why I never did anything to let you read in *bits* of keymaps. I never expected calling `read' on a million keymaps to be fast --- or sane --- anyway. I'd like to *find* them again. I just spent three hours looking for them after you asked and they seem to have vanished. Oh well, all the more reason for me to rewrite them better. (I was mostly doing this as a way to get to know the Emacs C core in a fairly general way, so the code was, er, ugly in places. I can do better than that now.) (setq message-mode-map #k(:contents ((M-m . mml-mode-map) (tab . message-tab) (copy . copy-primary-selection)))) ... only an awful lot longer in the general case (and if `print' emitted it, of course not laid out like that either). -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD