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 10:58:49 +0200 Message-ID: <8761foz6pi.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> <83y4sk7biu.fsf@gnu.org> <87k344nzqw.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1413190763 29496 80.91.229.3 (13 Oct 2014 08:59:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 08:59:23 +0000 (UTC) Cc: rms@gnu.org, mikegerwitz@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, Eli Zaretskii To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 10:59:16 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 1XdbTH-0003ni-1Z for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 10:59:15 +0200 Original-Received: from localhost ([::1]:60876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbTG-0000jO-OO for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 04:59:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbT3-0000jI-5S for emacs-devel@gnu.org; Mon, 13 Oct 2014 04:59:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdbT1-00051O-JC for emacs-devel@gnu.org; Mon, 13 Oct 2014 04:59:01 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbT1-00051H-GK for emacs-devel@gnu.org; Mon, 13 Oct 2014 04:58:59 -0400 Original-Received: from localhost ([127.0.0.1]:37204 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdbSr-0004hD-P0; Mon, 13 Oct 2014 04:58:50 -0400 Original-Received: by lola (Postfix, from userid 1000) id 2686CE069D; Mon, 13 Oct 2014 10:58:49 +0200 (CEST) In-Reply-To: <87k344nzqw.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 13 Oct 2014 17:24:39 +0900") 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:175317 Archived-At: "Stephen J. Turnbull" writes: > Eli Zaretskii writes: > > > There's also the case that the application was invoked on a remote > > host, and its output is passed via the network (a.k.a. "Tramp"). Not > > sure if those 3 cases cover that. > > My three cases were intended to cover the "local" case, where the user > presumably has control of the files on her system. The case you are > describing is covered under network streams as far as I'm concerned > (YMMV, that's just the way I broke things down). > > > > An example of (3) is David's case, with AUCTeX handling of TeX error > > > messages containing non-unibyte text.) AFAIK such applications are > > > quite rare nowadays. > >=20 > > "Rare" doesn't mean unimportant to users to the degree we can ignore > > them. If we do want to cater to those "rare" cases, the only way of > > doing that is maintain a database of programs and their behaviors. > > That's my main strategy, yes. We have `file-coding-system-alist' for > filename cases, similar features for process and network streams, and > individual modes such as AUCTeX are developed by hackers who have > proved themselves able to take care of themselves. But that's not what happens. AUCTeX uses the normal defaults. When those defaults prove _insufficient_ to do the trick (which happens in sub-percentages of the total) for finding the corresponding source in a (normally encoding-correct) buffer of characters by interpreting the error context messages on a terminal where byte-based linebreaks may corrupt characters, _then_ the error context message (which came in from a terminal with an encoding, so no byte stream exists any more) are reencoded to utf-8, the line break is removed, and the byte stream is redecoded and matched again to the source file buffer containing _characters_ in the same encoding as those used for decoding the terminal. So the point is that a) TeX daring to produce error output on its console does not cause beeps and interruptions b) I have a fallback strategy for dealing with that kind of "ugh" that is _not_ covered by the standard fallback strategies but that can be hand-implemented _because_ there was no information loss. The alternative would be to create an encoding utf-8-with-bad-linebreaks and the respective coders/recoders and have that as the terminal encoding for running TeX. And I have no doubt that people will say that I should be forced to go that path since it is the "correct" one. Except that a single TeX run may very well go across several files with _different_ encodings, so there really is no single "correct" encoding for the terminal messages of TeX. Which means that the current "don't mess with things you have not been told to mess with" behavior leaves the programmer in the situation to focus on the _actual_ problem rather than fighting Emacs' preconceptions about what problem he is allowed to encounter. > Nevertheless, things are much better today than in the days when Erik > Naggum declared that "Emacs has a fatal disease, and its name is > 'MULE'". Erik was the highest profile programmer/user abandoning Emacs for XEmacs in order to avoid the consequences of multibyte encodings. I seem to remember that he blamed the principle of multibyte encodings rather than the early buggy MULE implementations (the earliest implementations worked with byte offsets for buffer and string positions so there was wagonloads of fallout, but I=A0think he also objected to the performance implications when closing that problem vector by making buffer and string positions character-based). I have no idea which Emacs variant he would be using these days if he were still around. It may well be XEmacs since part of his objections against MULE (which is now pretty unavoidable in XEmacs as well I=A0_think_) was the manner of the top-down decision-making resulting in its early inclusion in Emacs when it was not all-that-ready. > I suppose it would be reasonable to distinguish between Internet > streams, local network streams (but only if a valid certificate was > presented, otherwise there's little reason to be confident), and local > files or processes. But doing that conveniently and accurately sounds > like a painstaking task. The only thing one case sensibly do in stacked problems like this is to have each level deal with its own problems. And that means that it needs to pass on data that is not being processed at its own level. --=20 David Kastrup