My XEmacs wish list
A few off-the-cuff comments which shouldn't be taken too seriously
unless they're actually helpful at first glance.
Jerry James writes:
1. Large file support
It will be necessary, at the very least, to support
"incomplete"
(or not full) blocks. That implies that we cannot find a given
file offset by computing a block number and an offset into that
block.
Not to worry. This is already impossible under Mule and jkacompr.
Ie, it doesn't even work if you use complete 1-byte blocks. :-รพ
We'll have to take incomplete blocks between the start of
the file and the target location into account. I don't know
whether a sorted list of adjustment points or some kind of index
structure would be better.
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.
Traditional font lock, which fontifies the entire buffer at load
time,
won't work at all. We'll have to commit to one (or more) of the lazy
fontifiers.
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.
2. Layered views & transformers
This is cool! It doesn't have to be that much more expensive in
memory: we just make the associated lstream buffers big enough for the
whole window available for display. This would be expensive in time
for unseekable streams (eg, encrypted or gzipped files). Oh, I see
you already notices that.
In conjunction with project #1, each view would be a cache for the
view "below" it. This is tricky,
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.
3. Separation of data and presentation layers
We now have to worry about the security of the connection point.
However, properly managed, this is a good thing, as it makes XEmacs
into an instant collaborative tool.
I think this is probably a solved problem somewhere, or at least we
can borrow a reasonable technology that's in development from
somewhere.
4. Extension language replacement
And even changing to Scheme or Common Lisp won't save us
from having to rewrite all of the Elisp in both core and the packages.
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.
My big fear here is that we would be doomed to the fate of perlmacs.
Perlmacs was a joke. At that time the OO stuff in Perl was very new.
The effect was basically to allow keyboard macros to be obfuscated as
Perl one-liners (like further obfuscation was necessary?!)
pymacs is still around, though. Francois Pinard recently reassumed
maintainership, and it's been getting attention (minor) on the Python
lists.
Whatever happened to Guilized Emacs?
It's still a sore point with RMS, and still on the agenda AFAIK.
In any case, this is a dangerous road to go down, because [...] it
dooms any further efforts to sync with Emacs.
Er, that's a benefit, isn't it?<duck />
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!
5. Voice recognition support
I've always liked this one. Also addition of Emacspeak.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta