From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Thu, 09 Oct 2014 09:36:13 +0200 Message-ID: <877g097l02.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.org> <87r3yxwdr6.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx3tmi3t.fsf@fencepost.gnu.org> <834mvttgsf.fsf@gnu.org> <87lhp5m99w.fsf@fencepost.gnu.org> <87h9ztm5oa.fsf@fencepost.gnu.org> <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87d2a54t1m.fsf@yeeloong.lan> <83lhotme1e.fsf@gnu.org> <871tql17uw.fsf@yeeloong.lan> <838uktm9gw.fsf@gnu.org> <87h9zgarvp.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412840205 17421 80.91.229.3 (9 Oct 2014 07:36:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Oct 2014 07:36:45 +0000 (UTC) Cc: mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org, stephen@xemacs.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 09 09:36:38 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xc8H7-0004Kg-L0 for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 09:36:37 +0200 Original-Received: from localhost ([::1]:40899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8H7-0002we-AA for ged-emacs-devel@m.gmane.org; Thu, 09 Oct 2014 03:36:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8Gu-0002wN-DP for emacs-devel@gnu.org; Thu, 09 Oct 2014 03:36:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xc8Gr-0000H7-Or for emacs-devel@gnu.org; Thu, 09 Oct 2014 03:36:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8Gr-0000H3-Ln for emacs-devel@gnu.org; Thu, 09 Oct 2014 03:36:21 -0400 Original-Received: from localhost ([127.0.0.1]:40235 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xc8Gj-0001Gl-U0; Thu, 09 Oct 2014 03:36:14 -0400 Original-Received: by lola (Postfix, from userid 1000) id 7235BE0500; Thu, 9 Oct 2014 09:36:13 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Tue, 07 Oct 2014 20:47:04 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175171 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > UTF-8 is defined as not containing "overlong" sequences, so Emacs > decodes them into two raw-byte indicating characters, one indicating > 0xC0, one indicating 0xA2. When encoding, it reassembles them into > 0xC0 0xA2. > > In that case, it might be reasonable to ask the user whether to accept > a UTF-8 file decoding that contains any raw-byte characters. > > What do people think of this? > > One problem with that is that quite often Emacs' choice of a coding > system for a buffer is the result of heuristics rather than dependable > information. Not making a fuzz might often be simplest. > > Could you explain what "fuzz" means here? You load a file, edit a line, try saving. Emacs complains that it feels insecure doing so even though the line you edited is perfectly fine. That's getting in the way of doing work. It would be worse if Emacs already prompted for approval when loading. More often than not, the locale applied for operations is not even explicitly specified but a consequence of the user environment or preexisting content. Having internal operations and file read/write fail depending on the state of the user environment is a nuisance. That's particularly a danger when most core developers actually use basic English locales and don't even notice the havoc "locale-awareness" may cause. A recurring phenomenon in that direction is generation of number presentations that can no longer be processed because of being written under the influence of an LC_NUMERIC setting developers did not expect. -- David Kastrup