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: Wed, 08 Oct 2014 17:54:46 +0200 Message-ID: <87siiy7e0p.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.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> <87mw97rjwm.fsf@yeeloong.lan> <8761fvn8io.fsf@yeeloong.lan> <87egujahw6.fsf@fencepost.gnu.org> <87wq8bd8w2.fsf@netris.org> <87y4sr909s.fsf@fencepost.gnu.org> <87ppe3lbkr.fsf@yeeloong.lan> <87oatn8dqz.fsf@fencepost.gnu.org> <87eguili20.fsf@yeeloong.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412788891 30885 80.91.229.3 (8 Oct 2014 17:21:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2014 17:21:31 +0000 (UTC) Cc: Richard Stallman , Andreas Schwab , dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, Eli Zaretskii , stephen@xemacs.org To: Mark H Weaver Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 08 19:21:24 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 1XbuvT-0000xs-HC for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 19:21:23 +0200 Original-Received: from localhost ([::1]:37605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbuvT-0001MF-2M for ged-emacs-devel@m.gmane.org; Wed, 08 Oct 2014 13:21:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbuvQ-0001M8-5N for emacs-devel@gnu.org; Wed, 08 Oct 2014 13:21:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbuvO-0006ZC-O9 for emacs-devel@gnu.org; Wed, 08 Oct 2014 13:21:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbuvO-0006Z2-L5 for emacs-devel@gnu.org; Wed, 08 Oct 2014 13:21:18 -0400 Original-Received: from localhost ([127.0.0.1]:52360 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbuvH-000524-0M; Wed, 08 Oct 2014 13:21:11 -0400 Original-Received: by lola (Postfix, from userid 1000) id 22F4EE054B; Wed, 8 Oct 2014 17:54:46 +0200 (CEST) In-Reply-To: <87eguili20.fsf@yeeloong.lan> (Mark H. Weaver's message of "Wed, 08 Oct 2014 11:03:51 -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:175149 Archived-At: Mark H Weaver writes: > David Kastrup writes: > >> Mark H Weaver writes: >> >>> David Kastrup writes: >>>> You cannot successfully cater for clueless application programmers. >>> >>> It is not "clueless" to expect a UTF-8 encoder to produce valid UTF-8. >> >> We are not talking about "producing" but "reproducing" here. > > I stand by my statement above, regardless of what input is feed into the > UTF-8 encoder, and I think I've said enough to make my point. You are > immovable, as always, and I don't want to waste any more time on this. Shrug. It's hard to move me when I have been around in similar circumstances and when I've been been exposed to the consequences of similar decisions before. AUCTeX's prv-xemacs.el contains (defcustom preview-buffer-recoding-alist (if (and (=3D emacs-major-version 21) (< emacs-minor-version 5)) '((utf-8-unix . raw-text-unix) (utf-8-dos . raw-text-dos) (utf-8-mac . raw-text-mac) (utf-8 . raw-text))) "Translate buffer encodings into process encodings. TeX is sometimes bad dealing with 8bit encodings and rather bad dealing with multibyte encodings. So the process encoding output might need to get temporarily reprocessed into the original byte stream before the buffer characters can be identified. XEmacs 21.4 is rather bad at preserving incomplete multibyte characters in that process. This variable makes it possible to use a reconstructable coding system in the run buffer instead. Specify an alist of base coding system names here, which you can get using \(coding-system-name (coding-system-base buffer-file-coding-system)) in properly detected buffers." :group 'preview-latex :type '(repeat (cons symbol symbol))) (defun preview-buffer-recode-system (base) "This is supposed to translate unrepresentable base encodings into something that can be used safely for byte streams in the run buffer. XEmacs mule-ucs is so broken that this may be needed." (or (cdr (assq (coding-system-name base) preview-buffer-recoding-alist)) base)) as opposed to prv-emacs.el's (defsubst preview-buffer-recode-system (base) "This is supposed to translate unrepresentable base encodings into something that can be used safely for byte streams in the run buffer. A noop for Emacs." base) What you don't see is the associated man-month of bug reports, hassles, head-scratching, debugging, solution-finding, abstracting and boiling down into a solution. I've been at the receiving end of the "reproducing the input bytes faithfully is not a priority" mindframe, and it is costly. If I=A0am immovable here, it's because I'm old. I've been a programmer long enough in this game to know that "but when _we_ do that, everything will be different" pans out rarely enough. And it's not like I'm not getting bitten at the current point of time while trying to get LilyPond (and thus C++ strings) play well with GUILE2 without buying into massive conversion overhead and/or possible column counting mismatches. We write out PostScript code. A mixture of material in Latin1, UTF16BE, and binary. We read in utf8 code and have a flex scanner working on in-memory byte streams it shares with the GUILE reader interpreting it in UTF-8. It's not like I don't know what I am talking about here. > You can add this to your long list of reasons why you consider me a > bad maintainer for Guile. To be honest, I was not even aware you were maintainer for GUILE. There are several committers to the stable/2.0 branch (and sometimes merging from there to master), and there is Andy Wingo committing to master in occasional spurts of commits of highly experimental character that are not discussed on any public list. While I=A0am clueless about the official roles of the various developers, the resulting workflows look more evolved than designed. I can hardly blame you for something that you do not appear to have much choice in. Many GNU maintainers are sovereigns without subjects or a castle, mostly endowed with the power to let the sun rise in the morning. --=20 David Kastrup