Contents of one of my workspaces

[Vin Shelton]

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 at 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