Re: Bidi support

[Stephen J. Turnbull]

Kenichi Handa writes:
 > In article <address@hidden>, "Stephen J. Turnbull" <address@hidden> writes:
 > 
 > > Stefan Monnier writes:
 > > Agreed.  The more I think about it, the more I think we need to open
 > > a new branch for "what will become emacs-24".
 > 
 > > That's what I thought, too, about XEmacs 21.5.  I was wrong.  We ended
 > > up having to uproot the trunk and move it to a branch, and graft the
 > > 21.5 branch back as the trunk.  Long-term development belongs either
 > > on the trunk, or in feature branches.  Not on a long-term development
 > > branch which collects several features.

 > Having an separate branch has at least one merit.  As far as
 > it is branched from a fairly stable version,

What you describe is what I mean by "feature branch".  Features
branches are a tried and true way to work; I do not mean to say "don't
use feature branches".

 > For the case of bidi, if there's a plan of another big
 > change in the display engine, the above merit is big.

bidi already has a branch or a repository or something.  It only needs
to be canonized as "accepted in principle" for v24, and given an
official URL.  My understanding of what Stefan proposed is something
different: that as the maintainers decide that some features are
important to add, they be merged to the "for v24" branch: bidi with
lexbind with ....

 > By the way, the case of emacs-unicode is very special.  It
 > simply can't be in the trunk while developing because the
 > new unicode feature can't be toggled.

By "can't", I guess you mean you didn't design it to be toggled?  Ben
Wing worked out how to have toggle-able buffer formats in 2002 (then
disappeared from XEmacs, unfortunately, but the infrastructure is
present).  I'm not saying it's a good idea, but it's possible.