From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Bidi support Date: Sat, 22 Aug 2009 14:39:59 +0900 Message-ID: <87bpm84dao.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87praszybe.fsf@stupidchicken.com> <838whgik6y.fsf@gnu.org> <8363cjipz6.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250919036 14485 80.91.229.12 (22 Aug 2009 05:30:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Aug 2009 05:30:36 +0000 (UTC) Cc: Eli Zaretskii , cyd@stupidchicken.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 22 07:30:28 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MejBL-0005Rw-M3 for ged-emacs-devel@m.gmane.org; Sat, 22 Aug 2009 07:30:27 +0200 Original-Received: from localhost ([127.0.0.1]:56149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MejBL-0003u4-1V for ged-emacs-devel@m.gmane.org; Sat, 22 Aug 2009 01:30:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MejBF-0003t1-GR for emacs-devel@gnu.org; Sat, 22 Aug 2009 01:30:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MejBB-0003np-A3 for emacs-devel@gnu.org; Sat, 22 Aug 2009 01:30:21 -0400 Original-Received: from [199.232.76.173] (port=36501 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MejBB-0003nX-3g for emacs-devel@gnu.org; Sat, 22 Aug 2009 01:30:17 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:37106) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MejB7-0000xd-UX; Sat, 22 Aug 2009 01:30:14 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 5777C8210; Sat, 22 Aug 2009 14:30:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5ED1D1A25CB; Sat, 22 Aug 2009 14:39:59 +0900 (JST) X-Now-Playing: Dave Mason In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 891381effa11+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114505 Archived-At: 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. Once you move to bzr, this will become less costly, but remember that in bzr (like CVS, but not so disastrously as CVS) some branches are more equal than others in the way they are presented to the user. It's not like git where you just do git branch emacs-23 master git branch -f master emacs-24 git branch -D emacs-24 # optional and everything's alright. > I think it will stay unstable for too long, so it's not good enough for > the current trunk (which I'd like to keep for shorter-term changes). I know how you feel, but doing things this way is either going to be a lot of work (synching "short-term changes" from the trunk to the long-term branch -- in my experience, people work on features like unicode and bidi in spurts, and they're pervasive changes so conflicts are frequent if you come back every month or so), or discourage work on the long-term branch (conflict resolution is enthusiasm-draining). It also fails to encourage work on the instabilities by third parties. I may be all wet; ask Ken'ichi and Miles how they feel about the long stalls on the unicode and lexbind branches. And maybe bzr will be flexible enough to handle it, but you won't know that until Christmas, I would guess. I'm still finding new things I dislike about Mercurial 20 months after our conversion....