My XEmacs wish list
james at xemacs.org
Mon Feb 18 12:57:38 EST 2008
Sorry to keep dropping in and out of conversations. Dang microorganisms.
Thanks for the comments, everyone. I notice the extension language
item got the most attention. :-)
On Feb 12, 2008 5:22 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> GNU uses a b-tree (or similar) for overlays and properties anyway.
> Ben (presumably) suggests a b-tree instead of the SOE. I've recently
> been studying up on AVL and related search trees because of this.
> Finding locations in an Emacs buffer is nontrivial anyway.
I didn't know Ben didn't like the SOE. I've never looked closely at
the implementation. Sounds like it's time.
> This isn't going to work in principle, because of strings and other
> constructs with symmetric delimiters. We need an entirely different
> approach. The current font-lockers need to be replaced by a syntactic
> font-lock mechanism.
Yes, that would also provide the means of getting more accurate
font-locking, too. My big worry is how to update the font-lock
properties as the user types. That process has to be pretty fast.
I've been wondering about the feasibility of doing a syntactic
font-lock initially, with on-the-fly updates using regular expressions
like we do now, with a repeat of the syntactic font-lock at fixed time
intervals, moments of user quiescence, save time, or some other
criteria. But then writing font-lock rules becomes that much harder
for the poor mode writer. We've discussed the work on incremental
parsers on this list before, too; that's worth another look.
> Ulrich Drepper once told me that the hardest thing he ever coded in
> glibc was the gconv stuff, which is structurally very similar, but
> much simpler since it only ever moves forward in the file. :-(
> Maybe this is only going to be available for "small" files that can be
> held in one "project #1" memory block.
Probably. It could be done for large files if all streams are seekable.
> I think this is false. Implementing Lisp in Lisp is now pretty much
> of a parlor trick. It will be a lot of effort, but worth it (both
> much less expensive than translating all existing packages and
> maintaining forward compatibility with Emacs.
As a test, I put together a Common Lisp Elisp reader. It went pretty
quickly, to my surprise, although it is incomplete. The one thing I
didn't do was implement a Mule-reader, though, so it only reads ASCII
Elisp files successfully. I see that recode has some Mule support,
although it appears to be pretty incomplete, so I guess that won't
> pymacs is still around, though. Francois Pinard recently reassumed
> maintainership, and it's been getting attention (minor) on the Python
Yes, I'm digging through it to see how it was implemented.
> > The benefits are the potential for better performance (although it
> > would be easy to fail to realize that potential) and the
> > possibility of attracting more developers due to choosing a more
> > widely known language (Javamacs, anyone?).
> Bailiff! Gag the plaintiff!
What? This is a free country and you can't MMRRFFFRMMRMRMMRG!
> > 5. Voice recognition support
> I've always liked this one. Also addition of Emacspeak.
Me, too. I think I'll do that one first. As soon as I buy myself an
expensive microphone, of course. :-)
More information about the XEmacs-Beta