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: Sun, 12 Oct 2014 10:38:01 +0200 Organization: Organization?!? Message-ID: <87h9z91y52.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.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> <83y4srjaot.fsf@gnu.org> <83r3yhiu8c.fsf@gnu.org> <83siiw9c6t.fsf@gnu.org> <83zjd3846e.fsf@gnu.org> <8738auyxke.fsf@netris.org> <874mvaoys7.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 1413103119 1184 80.91.229.3 (12 Oct 2014 08:38:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Oct 2014 08:38:39 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 12 10:38:34 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 1XdEfh-000251-O5 for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 10:38:33 +0200 Original-Received: from localhost ([::1]:56554 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdEfh-0003aR-C9 for ged-emacs-devel@m.gmane.org; Sun, 12 Oct 2014 04:38:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdEfa-0003aJ-0k for emacs-devel@gnu.org; Sun, 12 Oct 2014 04:38:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdEfU-0000MV-SD for emacs-devel@gnu.org; Sun, 12 Oct 2014 04:38:25 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdEfU-0000M7-Md for emacs-devel@gnu.org; Sun, 12 Oct 2014 04:38:20 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XdEfT-0001zC-6A for emacs-devel@gnu.org; Sun, 12 Oct 2014 10:38:19 +0200 Original-Received: from x2f49373.dyn.telefonica.de ([2.244.147.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Oct 2014 10:38:19 +0200 Original-Received: from dak by x2f49373.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Oct 2014 10:38:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f49373.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:lzf/D/exNoHLxo5e31rkkC+JfxU= 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:175280 Archived-At: "Stephen J. Turnbull" writes: > Mark H Weaver writes: > > Eli Zaretskii writes: > > > > Specify, and then drag it all the way down the encoding/decoding > > > machinery. > > > > The strictness flag should conceptually be part of the encoding, and > > thus associated with the I/O port. > > This is the way Emacs works already. > > However, I think the Python system, where strictness is part of the > I/O port, not the encoding, and the encodings are designed to error > and then hand the invalid raw bytes to the error handler if desired, > is a better API. I don't know how easy it would be to provide this in > Emacs Emacs uses CCL programs for encoding/decoding. It would be a performance disaster for loading files with binary parts (like PostScript) to break out of the CCL program for every "invalid raw byte". I cannot believe this, really. We _fought_ all the Emacs 20 encoding wars decades ago. It looks like a bunch of armchair strategists trying to reinvent the wheel but these are actually people fundamentally involved with the original efforts. Which makes this doubly as baffling. Richard was _part_ of the Emacs 20 efforts and basically the one who forced the MULE issue, and Stephen was on the XEmacs side which now has ailed in popularity not least of all because Emacs tends to work better in practice _now_ regarding the current prevalence of multibyte codings in spite of XEmacs being earlier in aligning itself internally with utf-8 (If memory serves me right). I can understand GUILE developers being unaware of the experience we gained through all those years. But I am baffled at those who _led_ the respective efforts wanting to repeat history, persuaded that everything will be different next time round. Actually not even that: it would appear that our history and experience are not just treated as irrelevant but rather as non-existent. This thread is called "Emacs Lisp's future", but we seem determined to plan this future starting in 1994 rather than 2014. -- David Kastrup