Re: Horrible term-mode problems on upgrade to 21.4

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