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: Mon, 13 Oct 2014 19:24:40 +0200 Organization: Organization?!? Message-ID: <87bnpfyjaf.fsf@fencepost.gnu.org> References: <87d2ahm3nw.fsf@fencepost.gnu.org> <871tqneyvl.fsf@netris.org> <87zjd9swfj.fsf@uwakimon.sk.tsukuba.ac.jp> <87oatnqpml.fsf@uwakimon.sk.tsukuba.ac.jp> <874mvdrj45.fsf@uwakimon.sk.tsukuba.ac.jp> <20141009044917.GA19957@fencepost.gnu.org> <83lhopisfr.fsf@gnu.org> <87ppe1pldu.fsf@uwakimon.sk.tsukuba.ac.jp> <8761ft5wpo.fsf@fencepost.gnu.org> <83k349b0vj.fsf@gnu.org> <83bnph96kh.fsf@gnu.org> <87ppdwo7ll.fsf@uwakimon.sk.tsukuba.ac.jp> <543BE7CB.9040801@cs.ucla.edu> <87egubopls.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413221128 22741 80.91.229.3 (13 Oct 2014 17:25:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 17:25:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 19:25:20 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 1XdjN0-0003cT-7r for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 19:25:18 +0200 Original-Received: from localhost ([::1]:34578 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdjMz-0003t0-OJ for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 13:25:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdjMh-0003qr-0W for emacs-devel@gnu.org; Mon, 13 Oct 2014 13:25:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdjMa-0006N3-V1 for emacs-devel@gnu.org; Mon, 13 Oct 2014 13:24:58 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdjMa-0006Mq-P1 for emacs-devel@gnu.org; Mon, 13 Oct 2014 13:24:52 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XdjMa-0003Pr-77 for emacs-devel@gnu.org; Mon, 13 Oct 2014 19:24:52 +0200 Original-Received: from x2f43f1e.dyn.telefonica.de ([2.244.63.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Oct 2014 19:24:52 +0200 Original-Received: from dak by x2f43f1e.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Oct 2014 19:24:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f43f1e.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:dwurgTJfv+U4bdvNPyKhJ+3OXxU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:175332 Archived-At: "Stephen J. Turnbull" writes: > Paul Eggert writes: > > Stephen J. Turnbull wrote: > > > The file or application is truly local, provided with the OS or > > > created by the user. In that case on a well-maintained system, > > > the encoding should be valid > > > > It could easily be mixed. For example, in the Emacs source code > > the output of the shell command "grep -r she *" produces some text > > that is UTF-8 and some that is 8-bit EUC. So the shell command's > > output is not valid even though all its input files are valid. > > This type of thing is not uncommon. > > Not uncommon, but no more (and no less) sensible than "zgrep she > /vmlinuz". Both commands are useful in some contexts, but neither > command's output should be thought of as "encoded text" in the sense > that any codec I know of can handle and produce useful output for all > of the encodings (or even more than one). > > If you're planning further processing you shouldn't allow something as > mechanical as a codec anywhere near that stuff: you should accept it > into a buffer as binary, and do your own conversions based on any > useful heuristics you have. Binary is quite unpractical when you are working in a locale and the vast majority of output fits it. Then you want to have things displayed according to locale and have that stuff which doesn't fit formatted as some sort of recognizable escape sequence. And I am mighty glad that Emacs does that without some "if Emacs cannot be 100% correct it should at least be 100% inconvenient" rule getting in the way of getting work done. -- David Kastrup