From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24603: [PATCHv5 08/11] Implement rules for title-casing Dutch ij =?UTF-8?Q?=E2=80=98letter=E2=80=99?= (bug#24603) Date: Fri, 17 Mar 2017 15:43:27 +0200 Message-ID: <838to4yq68.fsf@gnu.org> References: <20170309215150.9562-1-mina86@mina86.com> <20170309215150.9562-9-mina86@mina86.com> <83a88sdudb.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1489758322 20135 195.159.176.226 (17 Mar 2017 13:45:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Mar 2017 13:45:22 +0000 (UTC) Cc: 24603@debbugs.gnu.org To: Michal Nazarewicz Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 17 14:45:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cosBm-0003kS-1E for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Mar 2017 14:45:06 +0100 Original-Received: from localhost ([::1]:49080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cosBs-0000lc-1s for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 Mar 2017 09:45:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cosBm-0000jH-4B for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2017 09:45:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cosBi-0002SB-0C for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2017 09:45:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33331) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cosBh-0002S6-T1 for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2017 09:45:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cosBh-00070T-L2 for bug-gnu-emacs@gnu.org; Fri, 17 Mar 2017 09:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Mar 2017 13:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24603 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 24603-submit@debbugs.gnu.org id=B24603.148975824326848 (code B ref 24603); Fri, 17 Mar 2017 13:45:01 +0000 Original-Received: (at 24603) by debbugs.gnu.org; 17 Mar 2017 13:44:03 +0000 Original-Received: from localhost ([127.0.0.1]:59763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cosAk-0006yy-M8 for submit@debbugs.gnu.org; Fri, 17 Mar 2017 09:44:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cosAi-0006yK-54 for 24603@debbugs.gnu.org; Fri, 17 Mar 2017 09:44:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cosAZ-0002Eo-O1 for 24603@debbugs.gnu.org; Fri, 17 Mar 2017 09:43:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cosAZ-0002Ek-KN; Fri, 17 Mar 2017 09:43:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3693 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cosAY-0003Vo-Uq; Fri, 17 Mar 2017 09:43:51 -0400 In-reply-to: (message from Michal Nazarewicz on Thu, 16 Mar 2017 22:30:52 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130674 Archived-At: > From: Michal Nazarewicz > Cc: 24603@debbugs.gnu.org > Date: Thu, 16 Mar 2017 22:30:52 +0100 > > > If this is not mandated by Unicode 9.0 (and not by the latest draft of > > 10.0, AFAICS), shouldn't we have a user option for this, by default > > off? > > I don’t really see why. > > If the goal is to implement Unicode then ‘ij’ handling should not be > implemented at all and Unicode-mandated behaviour should not be > configurable, but implementing Unicode is a mean, not a goal in itself. That's true, but my thinking was that where Unicode says something shall be done we have more "moral authority" to implement what they say. Whereas where there's no Unicode-mandated behavior, we should consider the possibility that the behavior will be more controversial, and let users decide. > > I'm not sure I get this right: does this mean that writing in English > > (or any other non-Dutch language) in a Dutch locale will automatically > > capitalize "ij" to "IJ", just because the default value of > > buffer-language is "nl_NL" or somesuch, and no specific language was > > set for the buffer? Wouldn't that surprise users? > > Yes it does. And yes it would. > > This is currently the biggest blocker/concern for all the patches past > 07/11 and I’m still wondering what would be the best solution. > > I thought about having a ‘language’ string property so that programming > major modes would mark everything outside of comments as a ‘nil’ > language. This would require support from multiple major modes and > likely complicate them.¹ > > Or perhaps have off-by-default ‘special-casing-mode’ which enables > language-dependent casing rules. Similar effect could be accomplished > by replacing the ‘buffer-language’ with nil-by-default ‘casing-locale’ > variable applicable only to casing, but I would miss ‘buffer-language’ > since I believe it might get used for other things. I think buffer-language is a more broad issue, so if we want to let users control whether casing follows language rules, that should be a separate setting, independent of the language, and it shouldn't be a reason for not introducing buffer-language or language properties. So with this in mind, I think your second proposal is better. Btw, if we do introduce such properties, I think their values should be symbols, not strings, like we already do, for example, with 'charset' property we put on text decoded by some coding-systems. And such a property will indeed allow more fine-grained language-dependent behavior, provided that we find good ways of computing this property according to user expectations.