Re: please consider emacs-unicode for pervasive changes

[Dave Love]

Ken Raeburn <address@hidden> writes:

> 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'm not at all surprised, but that's not the point.  You're one of the
people I expected actually to understand what such changes entail
practically when it comes to a merge, but it wasn't directed just at
your changes.  Even things like straight global exchanges cause
problems in the end.  Yes, you _can_ go through all the changes, try
to understand them, and try to duplicate more-or-less the work that
was done originally.  But.

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

If you want to improve the GC (which would be very useful) what's the
reason for not trying the Boehm collector, as TODO suggests?  The
ex-Harlequin Memory Pool System has been released since then, but as
far as I remember it doesn't currently have a suitable licence and I
don't know whether it would be worth considering practically, in
contrast to Boehm's.

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

I didn't say anyone else should start a branch, but I don't know
what's being done.

> is that pervasive enough that you want it brought over,
> or small enough to merge later?

Well, if it's slow and painful, I certainly wouldn't want to do it,
especially if I'm not convinced it's going in the right direction.

> It may be better just to say *everything*
> goes into the branch as well as the trunk.

I doubt that's worthwhile for changes that don't go anywhere near Mule
unless they're fixing things which make it difficult actually to run
the branch version (which is the reason I looked at trying to merge
changes which might help).

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

Well, I'll give up at that stage.

> It would be helpful for automatic tools or other useful techniques to
> be made available,

I don't know what tool support could help.  I think it's basically a
question of management.

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

I disagree.  ``CVS is not a substitute for management.''

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

You mean there's some question about that happening, other than the
resources to do it which concerned me?  That's not what I understood
when I was pressed to do the Mule work.

> would you want to be required to merge them onto a Guile branch as
> well?

I'm afraid I don't want to waste my time on things related to Guile.
If we're competing against that, I'm going to stop.