Re: Contents of one of my workspaces
Hi Ben,
Thanks for sending this summary along. It really helps to let us see
what you have in the pipeline. Most of this stuff is _really_
exciting. See my comments inline.
"Ben Wing" <ben(a)666.com> writes:
I went through just now and looked through the diff of
"fixup", one of my
workspaces and perhaps the largest.
Following is an approximate list of the contents:
1. Cleanup configure, redo configure and various other code so that GTK and
X support are independent and both possible at once
Sounds like a good idea. Personally, I think migrating completely to
autoconf 2.59 would be fine for the 21.5 (22.0) release.
2. HAVE_SHLIB -> HAVE_MODULES
3. has-modeline-p -> modeline-visible-p
4. Move set-extent-* accessors to Lisp
5. Sync font-lock with FSF 21.2
This _sounds_ like a win, but how disruptive would this be?
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 property)
Personally, I'd rather not slow down startup at all, but I'm open to
others' thoughts.
7. Add code to optionally install hyper-apropos as the standard help
system
Great idea!
8. Add define-minor-mode and other constructs to
lisp-function-and-type-regexp
9. Load custom file before init file
As Michael has pointed out, I think we've discussed this one to death,
and I wouldn't want to see a change in this area.
10. define string-to-syntax as alias for syntax-string-to-code
11. Rewrite the text property implementation for speed (possibly not
finished); also implement FSF-compatible front-sticky, rear-nonsticky, etc.
+;; We used to create one extent for each distinct property; that is, if a
+;; range of text has two text-properties on it, there would be two extents.
+;; The problem is that the extent code gets much slower in this case,
+;; especially when you have one extent that straddles the entire buffer --
+;; and this is exactly what happens with lazy-lock, which sets
+;; `lazy-lock-fontified' to t on all regions that are up-to-date.
+
+;; Therefore, we now use just one extent to track all text properties in a
+;; region, and have *NO* overlapping text-property extents (#### Not
+;; actually true if duplicable and non-duplicable properties are mixed).
+;; The value of `text-prop' is a list indicating all properties being
+;; governed.
Sounds really good. Potentially disruptive, but the gain is probably
worth the pain. Definitely needs to be finished, though.
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
Yes!
14. Add (unimplemented) stubs for (set-)char-table-parent
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 insert
21. Factor out duplicated X/MSW/GTK XBM and XFACE code
Yes!
22. Add function write_string_to_lstream (used where?)
23. Type-correct rewriting in various places (int->Bytecount, char->Ascbyte,
etc.)
So, my bottom line is that much of what you propose is great stuff -
big visionary changes that will help move the code base forward
(consolidating X/GTK, etc), most of the rest of it is conceptually ver
good but potentially very disruptive (perhaps buggy) stuff and the
last bit (init vs. customize) is not OK.
So, I don't think we can accept this whole-hog. If you were willing
to break out the pieces that the review board found unacceptable, I
would be grateful for you to check this in, provided:
1. You finished off the unfinished parts.
2. You posted the code (or checked it in on a branch) for a week or 2
so we could all build and experiment with it. Ideally, you'd give
us a little warning beforehand so we could clear our decks and
spend some time working with the new code. 1 or 2 weeks after you
send out the patch (or check in on a branch), I would be OK with
your checking in to 21.5,
3. This is probably the most important part - you have to promise to
stay around to work through the issues that will inevitably arise
after your checkins. You have made enormous contributions to the
XEmacs project, but when you disappear for long stretches of time,
the rest of us don't know how to proceed with the codebase. It's
as if in the evolution of the XEmacs project, we don't quite reach
the equilibrium part of the punctuated equilibrium, because you
almost deliver us to the next level but then you disappear. To be
fair, this time you have been much easier to work with and I know
that you have worked hard to get here. Also, there's no way to
tell if your RSI might act up, so you can't make promises on that
score, but I'm asking for a good faith promise that you will
attempt to stick with us and work with us as we use your code as
the basis for a revitalized XEmacs 22.0.
What do you think?
- Vin