Re: Lexical binding -- do we really need it?

[William M. Perry]

Simon Josefsson <address@hidden> writes:

> Per Abrahamsen <address@hidden> writes:
> 
> > Richard Stallman <address@hidden> writes:
> >
> >> I don't think it is worth while working on optimization in the Emacs
> >> Lisp compiler.  It could be an unlimited time sink, drawing effort
> >> away from features that benefit the user into something users will
> >> hardly notice.
> ...
> > Also, I had to give one of the most complex options
> > (nnmail-split-fancy) the customize type "sexp", because the structured
> > type resulted in an unusable slow UI.  And that is bound by the Lisp
> > compiler.
> 
> A slow UI is very irritating for the user, and I see this from time to
> time with customize so I believe it is important.  But maybe the solution
> should be to separate the rendering of Emacs from the single threaded
> lisp enginge -- many GUI programs separate the rendering or view aspects
> from the controlling part of the program.  Perhaps support for GTK gets
> you this?

It could, but I'm not sure how much this would buy you other than having
the menubars and toolbar updated while the lisp interpreter was busy.
Until the lisp interpreter becomes even partially thread-safe, we would
have to have a huge lock around evaluation of lisp forms and variable
lookup.

You could make Xt events be handled in a separate thread right now, no
need to wait for a theoretical GTK port.

Would it be worth it to let the user come down and choose a menu option
when it won't actually get a chance to go into the lisp interpreter until
the current operation actually finishes?  The only exception to this would
be setting quit-flag.

-bp
-- 
Ceterum censeo vi esse delendam