Contents of one of my workspaces

[Ben Wing]

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

I doubt it.  I vaguely remember creating this monster myself, when for some
reason I couldn't think of the obviously better name.

> 
>     >> 4. Move set-extent-* accessors to Lisp
> 
> Why?

Just to eliminate some useless C code.

> 
>     >> 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
>     >> property)
> 
>     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.)

Currently, under Windows this frame pops up almost immediately, and then
many seconds later, after much path grinding, it goes away and the normal
frame appears.  This frame could also be used for any messages prior to
popping up the first frame, and eventually for moving the creation of the
first normal frame till *after* loading the init file, which would make it
extremely easy to customize the size of the first frame. (This is an
*ooollllldddd* proposal from Arch. XEmacs.)

BTW This "splash-frame" is a normal frame of the sort used in dialog boxes,
with the added feature of having no title bar (the new `no-title-bar' frame
property; only implemented on Windows currently, I need to get docs on the
various ways of communicating with window managers under X to control the
decorations.  Can all of you X-ers go look up any docs on window managers
you may have at hand and tell me what the tricks are?  Also I'd like the
names of the most common Window managers out there.  Alternatively, maybe
this should just be created override-redirect or something?  DOes that make
sense?)

>     >> 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
>     >> lisp-function-and-type-regexp
> 
>     >> 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.

Because it's FSF-compatible.

> 
>     >> 11. Rewrite the text property implementation for speed
>     >> (possibly not finished); also implement FSF-compatible
>     >> front-sticky, rear-nonsticky, etc.
> 
> +1
> 
>     >> 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.

1] it's already done.
2] it's probably not a waste of time. (NB In my glyphs workspace I have also
factored out much of the code shared between redisplay-x.c and
redisplay-gtk.c in the form of "xlike" input methods that implement
lower-level operations.) Most of what has been factored is stuff that's not
specific to X or GTK, with the appropriate X or GTK stuff stuck in through
ifdefs, or sometimes device methods.  As long as GTK v2 is parallel to X in
its basic model, the same approach will apply, and I strongly suspect it
will be, especially at the lower level where we care about because [1] GTK
v2 will surely want to be networkable, and X is the only well-known
networking system that's built ground-up to do this; [2] GTK v2 is going to
be running on top of X much of the time, hence it would not behoove it to
have a conceptually incompatible low level; [3] people rarely completely
throw away previous conceptual models, esp. at the lower levels, and in the
cases they do, it's all the rarer (and usually suicidal) for them to start
from scratch without looking at any model at all -- so what would they
choose?  Windows or MAC?  Doesn't seem too likely.

But I may be putting my foot in my mouth.

> 
>     >> 14. Add (unimplemented) stubs for (set-)char-table-parent
> 
> Are chartables used to implement syntax tables?

Yes

> If so, will 
> this buy us syntax parents which are currently hurting us in 
> both Gnus and AUCTeX?

Most likely.  But don't we already have an `inherit' syntax code, which
works fine?  Presumably this is not what you're referring to?
 
>     >> 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
> 
> +0 (ie, yes unless htey're rskier than they look)
> 
>     >> 21. Factor out duplicated X/MSW/GTK XBM and XFACE code
> 
>     vin> Yes!
> 
> +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,
>     >> etc.)
> 
> 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.
>