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: Re: per-buffer language environments Date: Wed, 15 Dec 2010 13:51:40 +0900 Message-ID: <87hbefr63n.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20101211.162503.37993912.wl@gnu.org> <83sjy4t9s0.fsf@gnu.org> <20101212.072550.527160732.wl@gnu.org> <838vztj3n0.fsf@gnu.org> <87y67sr3cs.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1292388858 32100 80.91.229.12 (15 Dec 2010 04:54:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 15 Dec 2010 04:54:18 +0000 (UTC) Cc: handa@m17n.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 15 05:54:13 2010 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.69) (envelope-from ) id 1PSjNV-0003YJ-36 for ged-emacs-devel@m.gmane.org; Wed, 15 Dec 2010 05:54:13 +0100 Original-Received: from localhost ([127.0.0.1]:57007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSjNU-0004uO-6z for ged-emacs-devel@m.gmane.org; Tue, 14 Dec 2010 23:54:12 -0500 Original-Received: from [140.186.70.92] (port=58511 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSjNO-0004uI-R6 for emacs-devel@gnu.org; Tue, 14 Dec 2010 23:54:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSjNJ-0007ZP-F0 for emacs-devel@gnu.org; Tue, 14 Dec 2010 23:54:06 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:42392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSjNG-0007YS-Ve; Tue, 14 Dec 2010 23:53:59 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B8A3F2AF543; Wed, 15 Dec 2010 13:53:55 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id AAC922AF542; Wed, 15 Dec 2010 13:53:55 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id A8E1F3FA0556; Wed, 15 Dec 2010 13:53:55 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0B1951A3BD1; Wed, 15 Dec 2010 13:51:41 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:133706 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Cc: Kenichi Handa , > > emacs-devel@gnu.org > > Date: Tue, 14 Dec 2010 20:38:43 +0900 > > > > Eli Zaretskii writes: > > > > > > * Which coding systems have higher priority when inserting a > > > > file in the current buffer. > > > > > > I could understand how the font selection and the default input method > > > are related to the language, but what do encodings have to do with > > > that? The preferred encoding is generally an attribute of a locale, > > > not of a language. > > > > Note the word "insert", which implies "read". It is certainly true > > that a locale may specify an encoding. However, if the person is > > Japanese, they may specify ja_JP.UTF-8 for their locale and strongly > > prefer that files be written with that encoding, yet still need to > > read files in other encodings. [more examples snipped] > > Those are all valid concerns, but they are just the tip of an > iceberg. No, they *are* the iceberg, at least as far as the autopilot is concerned. After that, you *must* ask the user. > There's an almost infinite number of combinations of a language and > the preferred encoding Sure, but given a language and the set of encoding features Emacs knows how to detect *when reading from a stream*, there remains substantial ambiguity. Setting the priority list can remove almost all of that ambiguity, leaving what's left for the user. That is what the priority lists are for, and it is a useful feature of the language environment. All problems with the language environment that I know of stem from its global nature applying to all buffers and the application itself, not from appropriate use in a given buffer. IOW, it's just the defects of the POSIX_ME_HARDER locale mirrored into Emacs itself. The preferred encoding, OTOH, is a heuristic for the encoding of files read, and the default for the encoding of files written. These two are independent in principle, but of course "preferred encoding for writing" = "highest priority encoding for reading" is a very valuable heuristic. > , and it's impossible to fold them all, or even their significant > fraction, Of course a significant fraction is possible. That's precisely what the priority lists have been achieving since the early 1990s. If your complaint is that we should do better, "patches welcome" is the only thing I can think of to say. But it does a pretty damn good job already, and buffer-local language environments should cut current damage by 80% or more; your work is cut out for you. > in a reasonably usable user-level interface. We shouldn't even > try, IMO; we already have prefer-coding-system Huh? prefer-coding-system has two effects: it promotes a certain coding-system to highest priority in its category, and it promotes that category to highest priority in case of ambiguity. IOW, it's a user override of the priority setting that comes from the language environment. A completely different purpose (handling exceptions) from the language environment itself (handling the unmarked case). Are you sure you have any idea what you're talking about? (That's an honest question; the way you are going, I have to wonder. If you say "yes", I'll trust you, but I'd appreciate an explanation of what you're talking about that refers to real bugs in the current system, rather than general features that offend your sense of design.) > , the coding: cookies, the .dir_locals meta-data, Speaking of *my* sense of design, two features that are an offense against Man and a stench in the nostrils of God. But I digress. > etc. to cover the situations where the user knows what encoding should > be preferred/used, even though her language and locale say otherwise. > > set-language-environment accepts a single string, which should be a > language name, as its argument. (There are some "languages" that we > recognize, such as "Chinese-GB18030", which sneak in the encoding as > well, but that's an anomaly, I think, which goes back to when Emacs > didn't have locale environments to express that. Now that we do, we > could get rid of that, at least in principle.) Therefore, a language > environment should set the defaults suitable for the language, and > that doesn't include the encoding, or at least does not have to fit > each minor cultural variant of the language. That's not what coding priority settings are for. They are to remove ambiguities like "we have EUC, but which one?" and "we have Windows-125x, but which one?" and "since ISO-8859-1 allows all 256 bytes, if we want to give priority to Chinese or Japanese, that had better come late in the list!" > > > The fact that we mix them is because Emacs had > > > language environments before it had locale environments. > > > > What's a "locale environment"? > > See set-locale-environment. "[No match]" YAGNI, apparently. (For values of "you" == "me", obviously. YMMV. :-) > > AFAIK Emacsen use the locale as a heuristic for determining the > > language environment > > There's no heuristic involved, AFAIR. Emacs has a database of > languages _and_encodings_ suitable for the known locale names. You're confusing "algorithmic" with "non-heuristic". Of course it's possible to have a heuristic algorithm. And of course in this case, locale is a heuristic. *Emacs is a multilingual* (well, technically, multiscript) *application*, and any setting of the language environment that doesn't take into account the current text we're working with is surely heuristic. > set-locale-environment uses that database to get the language and the > preferred encoding(s), then calls set-language-environment with the > language, and sets the priorities of the encodings according to the > encoding preferences. That's an unnecessary API, ISTM. (set-language-environment nil) should do that. Perhaps there should be a `set-locale' command to override the POSIX_ME_HARDER locale taken from the environment, but the POSIX_ME_HARDER locale is an abomination in a multilingual application and should be buried as deeply as we can manage. It is, of course, a useful heuristic for the user's preferred language environment for *scratch*, but that's about as far as we can take that.