Contents of one of my workspaces
Stephen J. Turnbull
stephen at xemacs.org
Sun Feb 13 06:44:30 EST 2005
>>>>> "vin" == Vin Shelton <acs at xemacs.org> writes:
vin> "Ben Wing" <ben at 666.com> writes:
>> I went through just now and looked through the diff of "fixup",
>> one of my workspaces and perhaps the largest.
My immediate time crunch is over; if it would help discussion/
decision/integration, post this and I'll get to work on splitting it
as I did with littlefix (I think it was). It will take some time, but
I can post pieces as I go.
vin> Sounds like a good idea. Personally, I think migrating
vin> completely to autoconf 2.59 would be fine for the 21.5 (22.0)
>> 2. HAVE_SHLIB -> HAVE_MODULES
>> 3. has-modeline-p -> modeline-visible-p
"'tis better to be internally consistent than not, but 'tis better to
be GNU-compatible than sane." Is this variable not available in GNU?
>> 4. Move set-extent-* accessors to Lisp
>> 5. Sync font-lock with FSF 21.2
vin> This _sounds_ like a win, but how disruptive would this be?
It's a big win, unless you consider Gnus, AUCTeX, and JDEE little
applications. (At least, and there are plenty of posts to c.e.x
saying "I want to create a tiny mode with just syntax highlighting but
`set-font-lock-keywords' doesn't work", etc.) Unless we're going to
do the humane thing and euthanize the current font-lock implementation
entirely, this needs to be done ASAP (IMHO).
>> 6. Create a "splash frame" that pops up early, before XEmacs
>> loads the init file, similar to the way many modern apps work;
>> add hackery to support this (e.g. "no-title-bar" frame
vin> Personally, I'd rather not slow down startup at all, but I'm
vin> open to others' thoughts.
This doesn't need to slow things down much at all---even if there's a
big pixmap or something, it's a small number of X roundtrips, and it
would greatly simplify the working with the WM_COMMAND stuff. If X
roundtrips don't matter, then delay will be unnoticable, I think. (I
could be missing something.)
>> 7. Add code to optionally install hyper-apropos as the standard
>> help system
vin> Great idea!
>> 8. Add define-minor-mode and other constructs to
>> 9. Load custom file before init file
vin> As Michael has pointed out, I think we've discussed this one
vin> to death, and I wouldn't want to see a change in this area.
The conclusion of the discussion as I recall it was that
init-before-custom is broken in theory and practice as an API and
violates POLA as a UI (users expect their customizations to be in
effect when their init files are executed, as they are when they test
them interactively). As I recall the discussion people were worried
about hypothetical breakage in init files if we switched, but all the
actual examples of breakage were due to init-before-custom (to the
extent that there are several people habitually using the device in
Ben's sample.init.el to load custom first), and all the theoretical
examples of breakage due to the change would be easily fixed without
hacking in something equivalent to reverting the change.
I agree that this is a potentially dangerous and surprising change,
and for that reason it should be done as quickly as possible.
>> 10. define string-to-syntax as alias for syntax-string-to-code
Why? It's less precise.
>> 11. Rewrite the text property implementation for speed
>> (possibly not finished); also implement FSF-compatible
>> front-sticky, rear-nonsticky, etc.
>> 12. Mule-ize all of GTK code
>> 13. Factor out duplicated X/GTK event key code into event-xlike.c; likewise
>> for duplicated gccache code
-1 on all GTK v1 work. It's a waste of time at this point---my
understanding is that many GTK v2 APIs are dramatically different.
We may very well just throw out much of this GTK code.
>> 14. Add (unimplemented) stubs for (set-)char-table-parent
Are chartables used to implement syntax tables? If so, will this buy
us syntax parents which are currently hurting us in both Gnus and
AUCTeX? If yes and yes, this is high priority.
>> 15. Add weak-list, extent(+substructures) usage to memory-usage stats
>> 16. Use LISP_STRING_TO_SIZED_EXTERNAL and friends in place of generic
>> TO_EXTERNAL_FORMAT in many places
>> 17. LIST_LOOP -> OLD_LIST_LOOP
>> 18. Correct some places in device-x.c etc. that incorrectly use Qctext
>> 19. doprnt can now take data from lisp or C string (why?)
>> 20. implement insert-(before-markers-)and-inherit separate from
+0 (ie, yes unless htey're rskier than they look)
>> 21. Factor out duplicated X/MSW/GTK XBM and XFACE code
+1 despite the comment on GTK above.
>> 22. Add function write_string_to_lstream (used where?)
>> 23. Type-correct rewriting in various places (int->Bytecount, char->Ascbyte,
As for conditionns on accepting the code ... all I can say is that if
we're going to say no to this, we're basically saying we're not going
to release anything in this calendar year, and maybe not in the next.
I can live with that (and I probably will not even leave XEmacs :-).
But IMHO that is the choice because I don't see another leader. I
can't do it this year, for sure.
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
More information about the XEmacs-Beta