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: Creating a coding system Date: Sat, 20 Dec 2014 18:38:23 +0100 Message-ID: <87r3vugr1s.fsf@fencepost.gnu.org> References: <87ppbeitcs.fsf@fencepost.gnu.org> <87sigasa3n.fsf@igel.home> <878ui2ieu1.fsf@fencepost.gnu.org> <87k31ms3gr.fsf@igel.home> <87zjaigtkz.fsf@fencepost.gnu.org> <83tx0qqn4d.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1419097121 18970 80.91.229.3 (20 Dec 2014 17:38:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Dec 2014 17:38:41 +0000 (UTC) Cc: schwab@linux-m68k.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 20 18:38:32 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 1Y2Nz5-00063W-C2 for ged-emacs-devel@m.gmane.org; Sat, 20 Dec 2014 18:38:31 +0100 Original-Received: from localhost ([::1]:35375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2Nz4-0006mx-ND for ged-emacs-devel@m.gmane.org; Sat, 20 Dec 2014 12:38:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2Nz1-0006mr-L0 for emacs-devel@gnu.org; Sat, 20 Dec 2014 12:38:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2Nyz-00068J-PS for emacs-devel@gnu.org; Sat, 20 Dec 2014 12:38:27 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2Nyz-00068B-LZ for emacs-devel@gnu.org; Sat, 20 Dec 2014 12:38:25 -0500 Original-Received: from localhost ([127.0.0.1]:50573 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2Nyy-0006E0-8i; Sat, 20 Dec 2014 12:38:24 -0500 Original-Received: by lola (Postfix, from userid 1000) id C5673E056B; Sat, 20 Dec 2014 18:38:23 +0100 (CET) In-Reply-To: <83tx0qqn4d.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 20 Dec 2014 18:53:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:180390 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Sat, 20 Dec 2014 17:43:40 +0100 >> Cc: emacs-devel@gnu.org >> >> Andreas Schwab writes: >> >> >>> The translation table operates on the decoded contents. >> >> >> >> Why would something be decoded twice in a row? >> > >> > You don't know the characters before decoding. >> >> That's an "Andreas" answer: an insider joke comprehensible only once you >> already know the answer. It's not even a hint. > > :-) > > Let me try being a bit more helpful. The translation table is a > char-table that converts one character into another. Since these > tables convert _characters_, you need to have a character before you > apply the table. Ok, so the table is not actually a "decoding-table" but rather a table applied after decoding. So basically it provides the same sort of functionality/level as `:post-read-conversion' VALUE must be a function to call after some text is inserted and decoded by the coding system itself and before any functions in `after-insert-functions' are called. This function is passed one argument; the number of characters in the text to convert, with point at the start of the text. The function should leave point the same, and return the new character count. does, but employing a different mechanism. > To have a character, you need to decode the byte stream into > characters. > > You can find more details on this in the node "Translation of > Characters" in the ELisp manual. Huh. I'll look again, but I _did_ look in the manual previously. Maybe a coding system is not even the right way to do this, but at least it seems like a builtin mechanism and consequently fast. But at least the decoding table does not appear to be able to _drop_ unwanted bytes: if my TO vector is empty for any sequence, the table construction fails, apparently when constructing the (unneeded) reverse table. -- David Kastrup