Re: My XEmacs wish list
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(a)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/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta