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 11:20:32 +0200 Message-ID: <871tqcz5pb.fsf@fencepost.gnu.org> References: <54193A70.9020901@member.fsf.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> <83r3yg9bpu.fsf@gnu.org> <83y4sn83ig.fsf@gnu.org> <87oath276y.fsf@fencepost.gnu.org> <87egucz9gm.fsf@fencepost.gnu.org> <83vbno74jt.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413192062 13675 80.91.229.3 (13 Oct 2014 09:21:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 09:21:02 +0000 (UTC) Cc: rms@gnu.org, mhw@netris.org, dmantipov@yandex.ru, emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, stephen@xemacs.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 13 11:20:47 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 1Xdbo7-000343-7N for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 11:20:47 +0200 Original-Received: from localhost ([::1]:60944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdbo6-0004rc-L7 for ged-emacs-devel@m.gmane.org; Mon, 13 Oct 2014 05:20:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdbo2-0004rI-UH for emacs-devel@gnu.org; Mon, 13 Oct 2014 05:20:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xdbo1-0003PF-RI for emacs-devel@gnu.org; Mon, 13 Oct 2014 05:20:42 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdbo1-0003PB-PG for emacs-devel@gnu.org; Mon, 13 Oct 2014 05:20:41 -0400 Original-Received: from localhost ([127.0.0.1]:37663 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xdbnt-0006Yt-DL; Mon, 13 Oct 2014 05:20:33 -0400 Original-Received: by lola (Postfix, from userid 1000) id EC2C6E069D; Mon, 13 Oct 2014 11:20:32 +0200 (CEST) In-Reply-To: <83vbno74jt.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 11:32:54 +0300") 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:175319 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: eliz@gnu.org, mhw@netris.org, dmantipov@yandex.ru, >> emacs-devel@gnu.org, handa@gnu.org, monnier@iro.umontreal.ca, >> stephen@xemacs.org >> Date: Mon, 13 Oct 2014 09:59:21 +0200 >> >> Syntax highlighting may want to point such things out. That's perfectly >> fine. > > Emacs indeed shows raw bytes in a distinct face. Which probably comes at some cost. I think at one time it provided some mouse-over information in an overlay and I seem to remember that this overlay may even have been the _whole_ difference between, say, a raw byte 0xa0 and the Unicode character at code point 0xa0. Making this distinction a part of the encoding rather than of a side channel like an overlay seems quite smart to me. Again: the overlay thing is just some vague memory and it might actually have been in either Emacs or XEmacs. At any rate, it would appear to carry a somewhat excessive cost. Syntax highlighting also comes at a cost, but at least it only happens on buffers actually being displayed rather than in the process of strings and buffers employed programmatically. For programmatic use, stray undecodable bytes come at the cost of an additional byte. That's cheap enough to be acceptable in more than just exceptional cases. And I commend Emacs for doing its best for not prescribing my decisions and workflow by making some viable choices unnecessarily expensive or hard. -- David Kastrup