At 08:49 PM 1/21/02 +0000, Nix wrote:
On Mon, 21 Jan 2002, Andy Piper yowled:
> At 08:27 AM 1/21/02 +0000, Nix wrote:
>>(I don't expect to be calling *much* from redisplay, anyway; but equally
>>I don't really want the system to explode because I've called a few
>>things, either.)
>
> What you should aim for is that in the steady state lisp isn't called
at all.
If we took that route to its logical conclusion, we'd end up with a
completely non-extensible editor.
No. There was an implied "inside of redisplay" at the end there. You are
welcome to call lisp anywhere else, but calling it inside of redisplay
slows things down.
The more that Lisp is called, the more places users can customize and
extend XEmacs.
This was, I thought, part of the point of XEmacs. :)
Sure. But not inside redisplay.
(In any case, surely speeding up the Lisp evaluator is a better
target
than reducing the use of Lisp? If the bytecode compiler and eval layers
were smarter, we'd hopefully not have to *care* about the potential
speed impact of Lisp.)
This sounds like swing all over again, don't get me started ....
And the fact that specifiers of all kinds do that has rendered what
could be a useful generic metavariable type useless for every single
purpose I'd otherwise have had for it; specifiers are, IMHO, essentially
useless except for display frobbery, mainly because of that.
I think they originated for display frobbery.
andy