Re: Horrible term-mode problems on upgrade to 21.4
Nix <nix(a)esperi.demon.co.uk> 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.