Re: please consider emacs-unicode for pervasive changes

[Ken Raeburn <raeburn@raeburn.org>]

I had written up a reply earlier, and Emacs crashed in the display
code, though I haven't figured out why yet.  I wonder if it's a
sign...


Dave Love <d.love@dl.ac.uk> writes:
> 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.

Yes, "but".  It's tedious work, whoever does it, and whichever
direction it's going, and unless you've got someone who understands
both sets of changes, merging them can be a problem.  I haven't yet
had a positive experience with extended development using branches.

Deciding who merges what and when is what's at issue.  Are we talking
about general policy for Emacs work, or special treatment for the
Unicode branch?  I haven't heard much about either.

Fortunately, in my case, most of my string-macro changes don't
actually require much understanding of the surrounding context; it's a
simple transformation on C source code.  So I probably could merge my
bigger recent changes into your branch without needing to understand
the overall gist of your changes.

> 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

This came up on emacs-hackers a few months ago.  Improving the GC
would be useful, but only if we decide we're not switching to Guile
any time soon.  If that happens, I'd probably be more interested in
working on fixing Guile, but I could probably be convinced to help
with more write-barrier stuff if someone else wanted to do the Emacs
GC work.

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

Can you describe "anywhere near Mule" a little more carefully?  Or
should I just run some cvs diffs on your branch to see if you've
touched the code I want to touch?

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

I'm assuming it because I've heard nothing else about "how we manage
development branches in Emacs".  Perhaps RMS simply doesn't want a
blanket policy right now.  Or maybe it hasn't been advertised well
enough in places where I've been looking.

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

I was thinking of things like the lisp code I used to make some
changes.  Or easy manual techniques for finding where certain changes
need to be made in the code.  Perhaps not applicable to most cases,
but when they are, sometimes they're for pervasive changes like mine.

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

So you think I need to understand your Unicode work, and Miles's
lexbind work (looks like he's added another field to Lisp_Symbol), and
whatever else might be "active" now, and merge any widespread changes
I make that might affect them onto N branches?  Or do you just want
special treatment for the Unicode branch?

Can we write up somewhere what's being done on branches that
developers need to be aware of, and when a developer should apply
changes to which branches?  Otherwise, how is someone who joins this
list next week going to know?

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

Poorly phrased, sorry.  I should have said, "If, when you do the
merging, there's a Guile branch..."

I don't know *how* you're going about the Unicode work, particularly
handling merges.  Apparently it involves getting other people to help
with some of the merging.

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

If you think Guile is a waste of time, I'm sorry to hear it.  I don't
plan to stop any time soon.  But I don't think that means there's any
sort of "competition" here.

And Guile wasn't the point of my question, anyways.  Assume for the
sake of argument that when you're ready to merge the Unicode changes,
there's some big, important, non-Guile-based branch that's also been
started by someone other than me, and it'll be affected by the Unicode
changes.  Do you think you should to be asked to merge the Unicode
changes onto that branch?

Ken