Re: please consider emacs-unicode for pervasive changes

[Ken Raeburn]

Dave Love <address@hidden> writes:
> There have been various pervasive changes recently which will cause
> grief merging the unicode branch eventually.  Could people doing this
> for Mule-related files (including display) please be prepared to
> modify the `emacs-unicode' branch too.  I don't know if handa would
> like to be consulted beforehand, but I assume he'd appreciate having
> it done now, with less problems later on.

My string-macro changes, while fairly pervasive, are not as tough to
make as they might appear.  You might be surprised by what can be
accomplished with a set of regular expressions that correspond to
various styles of C expressions :-).  I've attached the Lisp code I
use; scmcvt-string and scmcvt-string-2 are the interesting bits.
There's always a little cleanup needed afterwards (a few cases that
aren't matched; restoring lisp.h macros that become defined to expand
to themselves because the definition matched the pattern) but it does
95% of the work.

Other changes I'm working on right now are to reduce the uses of SDATA
that aren't read-only, to make it easier to identify places for
inserting write-barrier code; that's a slow and manual process, and
while by no means as pervasive, still twice as painful if I have to do
it on a branch as well.  Though aside from a few cases where SDATA is
used to write to a string, it'll mostly consist of adding "const" to
char pointers in places, and eventually adding a const cast to the
SDATA macro; is that pervasive enough that you want it brought over,
or small enough to merge later?

As soon as any big changes that need to be applied to the branch
depend on any small changes that weren't applied to the branch, we get
a maintenance hassle, with someone who didn't write those small
changes trying to bring them and anything they might depend on over to
the branch.  (The dependencies may be obvious, but if they're of the
sort "simplify macro X because all code relying on side-effect Y has
been changed over the course of a couple months to not rely on it",
they may be hard to find.)  It may be better just to say *everything*
goes into the branch as well as the trunk.

Then again, is anything else likely to be as problematic as taking
string handling in two different directions on different branches?

>   (I guess the same would go
> for other active branches, if there are any.)

I've assumed that when I start work on a Guile branch, I'd be
responsible for dealing with merges in both directions and all the
coordination that implies.  ("We", not "I"; I really hope to get some
help in this work.)  That's also why I am taking the approach I am --
essentially, I *am* merging changes to the trunk that I made in my
divergent source tree started long ago.

It would be helpful for automatic tools or other useful techniques to
be made available, but I wouldn't want to demand that everyone making
big changes on the trunk also be required to know which branches are
"active" and how their changes might have to be applied differently to
those branches, and rewrite their changes to suit.  If you get around
to merging in some big changes to the trunk to change the
character-data handling in ways that better support the Unicode
changes -- or perhaps the completed set of Unicode changes -- would
you want to be required to merge them onto a Guile branch as well?

I realize the Unicode work, which we've been talking about as the "big
thing" for Emacs 22, is probably in a special category, and maybe it
makes sense to ask for parallel development in this case and not
others.

Ken

txtXOwo08LKp8.txt
Description: c expr rewrite code