My XEmacs wish list

[Jerry James]

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
help.  Hmmmm.....

> pymacs is still around, though.  Francois Pinard recently reassumed
> maintainership, and it's been getting attention (minor) on the Python
> lists.

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. :-)
-- 
Jerry James
http://loganjerry.googlepages.com/