[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future

From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Mon, 13 Oct 2014 11:20:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: address@hidden, address@hidden, address@hidden,
>> address@hidden, address@hidden, address@hidden,
>> address@hidden
>> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]