From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Word syntax question Date: Wed, 22 Oct 2008 21:21:38 +0200 Message-ID: References: <87mygy0ybq.fsf@catnip.gol.com> <87bpxd29ft.fsf@catnip.gol.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1224703394 792 80.91.229.12 (22 Oct 2008 19:23:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Oct 2008 19:23:14 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org, miles@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 22 21:24:14 2008 connect(): Connection refused 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 1KsjJM-0003KN-SQ for ged-emacs-devel@m.gmane.org; Wed, 22 Oct 2008 21:24:13 +0200 Original-Received: from localhost ([127.0.0.1]:46121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsjID-0004Cv-Fj for ged-emacs-devel@m.gmane.org; Wed, 22 Oct 2008 15:22:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsjHQ-0003xt-UW for emacs-devel@gnu.org; Wed, 22 Oct 2008 15:22:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsjHM-0003w9-Gd for emacs-devel@gnu.org; Wed, 22 Oct 2008 15:22:04 -0400 Original-Received: from [199.232.76.173] (port=53288 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsjHM-0003w6-Bb for emacs-devel@gnu.org; Wed, 22 Oct 2008 15:22:00 -0400 Original-Received: from mtaout2.012.net.il ([84.95.2.4]:23166) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KsjH4-0001hO-2X; Wed, 22 Oct 2008 15:21:42 -0400 Original-Received: from HOME-C4E4A596F7 ([77.126.98.197]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K95008BSN6D8Q61@i_mtaout2.012.net.il>; Wed, 22 Oct 2008 21:23:02 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 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:104854 Archived-At: > From: "Richard M. Stallman" > CC: miles@gnu.org, schwab@suse.de, emacs-devel@gnu.org > Date: Wed, 22 Oct 2008 02:20:44 -0400 > > I agree. I think we should introduce a user option to control whether > it stops on script boundaries or not, because sometimes it makes > sense, sometimes it doesn't. > > That is not a real solution. The right thing to do is a function > of the case, not the user. Making each user specify an option > according to which cases she typically encounters is not clean. I agree that it would be better to solve this automatically, but I sincerely doubt that we will get that right in time for the release (unless we delay the release for many months). > It seems that we need a way to specify which kinds of script > boundaries should be word boundaries, on designed to produce the > results that users generally want, and which could be set up inside > Emacs so that users don't have to change it. I think we lack the knowledge for doing this right. We don't even have enough experts on board to cover all the Unicode scripts, or even their majority. How in the world will we decide which scripts can or cannot be mixed in the same word, let alone how this might change in some specialized Emacs mode? Unicode annexes know nothing about many Emacs features, so their advice will not help us except maybe in Text mode and its closest derivatives. We will need to develop our own solutions as we go, like we did with syntax tables in previous versions, for example. However, developing those solutions might take a lot of time and user experience which we do not yet have. It will take a lot of effort just to solve the bugs and sluggish performance to bring Emacs 23 to a releasable state, so if on top of that we delay the release until this and similar Unicode-related issues are satisfactorily resolved, we will not release Emacs 23 before another 2 or 3 years pass by. With that in mind, my suggestion to provide a user option was meant to give users a fire escape in case Emacs 23.1 does not get their use-case right.