outdated url-library: is XEmacs still the next generation of Emacs?
Stephen J. Turnbull
stephen at xemacs.org
Fri Jun 11 00:10:43 EDT 2010
Aidan Kehoe writes:
> (while (not (eq (point) (point-max)))
Which is bad style anyway, it should be "=".
> needs to become
> (while (not (eql (point) (point-max)))
> (but we can have the byte-compiler check for that, plus, maybe, the
> pseudo-Ebola stuff I mentioned) and will generate a lot of immediately
> garbage bignums. But if you *want* to deal with files that big in XEmacs,
> you probably have lots of memory (in which case we really should increase
> gc-cons-threshold appreciably at startup) or are working noninteractively,
> so garbage collection isn’t as annoying as it otherwise might be.
Yes, agreed. That's my rationale for suggesting it, too. However,
you can't increase the threshold indefinitely, because even on a
4-cylinder 2.4GHz Opteron box GC can make XEmacs drop dead for seconds
with current default settings. `point' is called a lot, but
`point-max' I think is much less frequent than `point-min'.
> > > it’s eminently reasonable, and shouldn’t be too much work. (I’m
> > > thinking, move the Charbpos, Bytebpos and Membpos typedefs to
> > > corresponding to off_t rather than EMACS_INT;
> > I don't understand that. off_t is likely to be 32 bits on 32-bit
> > platforms.
> Not on 32-bit platforms with large file support. Though as I understand it,
> large file support on Linux is a bit of a red-headed stepchild, it needs
> special compile time defines.
Exactly. And AIUI the underlying kernel calls are different (ie, you
can choose at runtime whether you want a large file version or not).
Apple at least supports off64_t (or whatever it is) though, so
probably there's a standard typedef for this.
Basically your strategy makes explicit what I was thinking, I was just
confused by your choice of off_t here. We need to be careful about
that. If there is a standard typedef that makes it explicit that
"this supports large file sizes and offsets", we should use that,
otherwise we should use something like EMACS_OFF64_T (or maybe just
However, note that if a (void *) is 32 bits, all we get out of this is
a (maximum) of a 4GB file anyway, since that's an absolute upper bound
on buffer size. Properly warning the users of such systems when
attempting to access such files will be important.
More information about the XEmacs-Beta