Re: Horrible term-mode problems on upgrade to 21.4

Nix <nix(a)esperi.demon.co.uk&gt; writes: > > Good point. In general, one should be able to stack "coding > > systems", e.g. a "gzip" coding system piped into a "NL detection > > coding system" piped into a "charset detection coding system" (for > > people who need that). > > Sort of like Streams? Right. XEmacs internally has very powerful Lstreams, which are capable of "stacking", but we have yet to come up with a good interface for exposing them to Lisp level.

> 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'. Exactly. A form of "coding system" would probably remain, because when you finally import the bytes into XEmacs, you have to convert them to chars of a certain charset. At this point the coding systems would still be useful. > 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. I'm not sure I would generalize to that point, but perhaps it's possible. > 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? I'm not sure about the "no GC" rule, but the no Lisp rule is there because of efficiency and robustness. Efficiency means that Lisp code might be too expensive to call within redisplay. Robustness means that there is no good way to handle Lisp errors while you're in redisplay "critical section". It's just too dangerous.

There have been discussions about how to circumvent the Golden Rules. One of them is to allow a safe subset of Lisp to be run, sort of like CCL is currently allowed. > - 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... You can, to an extent. But you cannot make them completely dynamic. Remember that a) specifiers are cached, and b) specifiers are resolved from within redisplay. The Golden Rules strike back. :-) > - 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. We can discuss that. I have personally made steps in that direction by implemented ways to create arbitrary events and adding read/print syntax to hash tables. Could you explain why you need a read/print syntax for keymaps? Speaking of keymaps, remember that they are not opaque objects because of our perversion. When you change key definitions, the keymap code actually recalculates internal caches that make operations like `where-is' fast, which is extremely important for menus. > 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. I would like to know more about the changes you envisioned. For instance, could you post a Lisp code snippet of how updating an opaque object from the reader would work with your patches applied.