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: per-buffer language environments Date: Fri, 17 Dec 2010 13:51:59 +0200 Message-ID: <8362ushb1c.fsf@gnu.org> 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> <87hbefr63n.fsf@uwakimon.sk.tsukuba.ac.jp> <874oadqv8r.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1292587143 26718 80.91.229.12 (17 Dec 2010 11:59:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 17 Dec 2010 11:59:03 +0000 (UTC) Cc: emacs-devel@gnu.org, handa@m17n.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 17 12:58:59 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 1PTYxe-0003K2-EI for ged-emacs-devel@m.gmane.org; Fri, 17 Dec 2010 12:58:58 +0100 Original-Received: from localhost ([127.0.0.1]:39891 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTYxc-0003lN-My for ged-emacs-devel@m.gmane.org; Fri, 17 Dec 2010 06:58:56 -0500 Original-Received: from [140.186.70.92] (port=50583 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTYrl-0005oQ-MU for emacs-devel@gnu.org; Fri, 17 Dec 2010 06:53:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PTYrO-0005Nb-DD for emacs-devel@gnu.org; Fri, 17 Dec 2010 06:52:52 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:61823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PTYrO-0005Mz-5s for emacs-devel@gnu.org; Fri, 17 Dec 2010 06:52:30 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LDK00200M6B3400@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 17 Dec 2010 13:51:54 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.229.167.122]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LDK000ZVMAGFXG0@a-mtaout20.012.net.il>; Fri, 17 Dec 2010 13:51:54 +0200 (IST) In-reply-to: <874oadqv8r.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:133765 Archived-At: > From: "Stephen J. Turnbull" > Cc: handa@m17n.org, > emacs-devel@gnu.org > Date: Fri, 17 Dec 2010 06:10:44 +0900 > > I know you were talking about something else, but I can't figure out > what or why. Sorry for not making myself clear. Let me try again: . The issue is what it means to have a separate buffer-local "language environment". . The current machinery of language environments was invented and evolved to its current form as a global session-wide setting. I'm not sure the same set of heuristics, or even the extent of what "language environment" means and what settings it affects, are still correct for a buffer-local setting. . There's any number of possible use-cases for needing this kind of feature. They are all quite rare (if they weren't, we would have many complaints about not having such a feature, which we don't). The current heuristics encoded in the global language environment does not cover well rare and marginal use-cases, being just that -- a set of heuristics. It is therefore quite probable that just making the language environment buffer-local and keeping all the rest of its machinery and semantics would do the wrong thing for a large portion of the use-cases which need such a buffer-local feature. . IMO, the way we set priorities for selecting an encoding based on the language runs the highest risk being inappropriate for this kind of buffer-local "language environment". That's because selection of an appropriate encoding depends on factors that have nothing to do with the language, for those languages which have several alternative encodings. These factors include the locale, the filesystem on which the buffer's file lives (which could be local or remote), the purpose of the text that is edited (it could be a text file, or a program source, or an email message meant to be sent, or text to be sent to a subsidiary program or copy/pasted through a selection), and possibly some more. Setting the language can surely identify a small set of appropriate encodings, but I very much doubt that it can correctly select The Right One. . Therefore, I think that buffer-local "language environments" should not automatically select the encodings given just the language name, but instead let the user specify them separately when she selects the buffer-local language. > > > That's an honest question; the way you are going, I have to wonder. > > > > Knowing me for as long as you do, I wonder how can such a question be > > honest. But I digress. > > Usually you don't miss a point like "nobody is proposing anything new > here for how language environments work". (All that is being proposed > is making them buffer-local.) Since you did miss it, I have to wonder > if you know anything about how encoding detection works internally. Since you have the logs to get you straight about the degree of my knowledge in that issue, you should rather wonder whether I'm missing your point because I misunderstood what you are saying or because you failed to explain it clearly.