Arthur Miller <arthur.mil...@live.com> writes: >>> IMNSHO, discussing a rewrite of Emacs in _any_ language is waste of >>> time and energy. We've seen this many times (because people still >>> insist on bringing this up from time to time). From where I stand, >>> the main reason is not even the fact that we decided not to do that, >>> but the fact that such a rewrite will never happen in practice. Such >>> a rewrite is a massive job which requires very good knowledge of Emacs >>> internals and features, and a lot of time. People who come close to >>> the required knowledge level are not interested in doing this job >>> (because they understand the futility), and those who think it should >>> be done simply don't know enough and/or don't have enough time on >>> their hands to pull it through. >>> >>> If Emacs will ever be "rewritten", it will not be Emacs, but a >>> text-processing system with a very different architecture and design, >>> which will take from the Emacs experience the lessons we learned and >>> implement them differently, to produce a system whose starting point >>> is closer to the needs of today's users and whose main technologies >>> are more modern from the get-go. >> >>I couldn't agree more. >> >>To me, a rewrite is quatsch, while adding CL facilities to Emacs makes a >>lot of sense. > > I use to say often: either CL will come to Emacs or Emacs to CL, whichever > way around. We need some of features available on CL platforms, sbcl > notably: built-in concurrency and better garbage collectors from the get-go; > and > some of the CL language features, namespaces notably, would be very nice to > have.
I agree. Alas, others, who haven't seem the light yet, don't :-). > I am not sure which one is easier to achieve, porting elisp to cl, or > rewriting core to have all those features. I don't know either, of course. I guess it depends on the feature. Some random thoughts: I'm pretty sure that CL packages could be added to Emacs as it is, if some people would work on it. I'm also pretty sure that an incremental + generational GC could be added, at least as an option, because I would have almost done it some 20+ years ago. It was torpedoed by a patent issue concerning mostly-copying GC. The patent has since expired. A lot of work, of course. I think some people do or have done something in this area, but I don't know details. I'm not at all sure that non-cooperative multi-threading could be added to Emacs. But I'm also not sure how a CL core would help here. On the other hand, I'm pretty convinced that an Emacs core written in CL would have to be close to 100% compatible with the existing C core to be accepted by users. That includes a CL rewrite of the C Elisp, including byte code interpreter. That's a massive endeavor. My hair stands up when I remember the compatibility problems I faced with the new redisplay ages ago. Multiply that by some factor > 1. But maybe that's a burnt child dreading the fire :-). I'm also not sure how a CL (not Elisp) program would look like using a CL Emacs core. Is it nice enough, so to speak? Think of Emacs strings, which couldn't be CL strings because of text properties, buffer-local variables... (Another ansatz might be to make Emacs C core a lib. I haven't given that much thought, but it could be more promising than rewriting the whole shit in CL :-).) > CFFI would also be nice to have so > that users can extend Emacs themselves with other libraries and not have to > wait > for the core devs to do it for them. That would also lessen the burden on > maintaining that stuff in the core. FFI for Emacs once existed, I think Dave Love wrote one, for instance. Don't know what became of that. Might be an issue with interfacing to non-free libs.
