From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Usage of standard-display-table in MSDOS Date: Thu, 09 Sep 2010 20:57:27 +0900 Message-ID: References: <83aao8mjzx.fsf@gnu.org> <837hjcm9cw.fsf@gnu.org> <201008291016.o7TAG22t007365@beta.mvs.co.il> <201008291149.o7TBn3bO010199@beta.mvs.co.il> <201009072111.o87LBeU2009811@beta.mvs.co.il> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1284033470 17263 80.91.229.12 (9 Sep 2010 11:57:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Sep 2010 11:57:50 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org To: ehud@unix.mvs.co.il Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 09 13:57:47 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OtflB-0001dq-Uw for ged-emacs-devel@m.gmane.org; Thu, 09 Sep 2010 13:57:46 +0200 Original-Received: from localhost ([127.0.0.1]:36539 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtflA-0000n8-W6 for ged-emacs-devel@m.gmane.org; Thu, 09 Sep 2010 07:57:45 -0400 Original-Received: from [140.186.70.92] (port=47014 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Otfl5-0000lv-6w for emacs-devel@gnu.org; Thu, 09 Sep 2010 07:57:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Otfl3-0005SW-CF for emacs-devel@gnu.org; Thu, 09 Sep 2010 07:57:39 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:61253) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Otfl1-0005PE-2m; Thu, 09 Sep 2010 07:57:35 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id o89BvTc7004952; Thu, 9 Sep 2010 20:57:29 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id o89BvSfB009132; Thu, 9 Sep 2010 20:57:28 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id o89BvS8Z027731; Thu, 9 Sep 2010 20:57:28 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.71) (envelope-from ) id 1Otfku-0003zj-0Z; Thu, 09 Sep 2010 20:57:28 +0900 In-Reply-To: <201009072111.o87LBeU2009811@beta.mvs.co.il> (ehud@unix.mvs.co.il) X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129815 Archived-At: In article <201009072111.o87LBeU2009811@beta.mvs.co.il>, "Ehud Karni" writes: > > If you don't like it, you must give up decoding bytes > > #x80..#x9A into Hebrew chars. You decode them as raw-bytes, > > and setup a display table to display them as Hebrew chars. > > It can be done by this code: > I think I solved this by using text properties. Ah, ummm, a kind of dirty hack, but, perhaps it's unavoidable in your situation. > It is still unfinished, but it works, and I'll appreciate any comments. > There are some problems, see at the end. > Here is what I did (based on your advice). > (define-charset 'hebrew-MSDOS-binary > "Hebrew subset of CP862 (#x80-#x9A) with no-conversion" > :code-space [#x80 #x9A] > :map (let ((map (make-vector 54 0)) > (ix 27)) > (while (> ix 0) > (setq ix (1- ix)) > (aset map (+ ix ix) (+ #x80 ix)) > (aset map (+ ix ix 1) (+ #x80 ix))) > map) > :supplementary-p t) For that, you don't have to use :map but can use :code-offset as this: (define-charset 'hebrew-MSDOS-binary "Hebrew subset of CP862 (#x80-#x9A) with no-conversion" :code-space [#x80 #x9A] :code-offset #x80 :supplementary-p t) > (defun hebrew-iso-with-8bit-pre-write (start end) > (let* ((text (if (numberp start) > (buffer-substring start end) > start)) > (beg 0) > (end (length text)) > va) > (while (setq beg (text-property-any beg end 'Hebrew 'DOS text)) > (setq va (aref text beg)) > (and (>=3D va #x05D0) ;; =D7=90 > (<=3D va #x05EA) ;; =D7=AA > (aset text beg (- va #x550))) > (setq beg (1+ beg))) > (set-buffer (get-buffer-create " *heb-wrt*")) > (delete-region (point-min) (point-max)) > (insert text) > nil)) You don't have to make a working buffer. You can directly modify the current buffer because it's already a working buffer managed by Emacs itself. > There are some Problems: > 1. (describe-character-set 'hebrew-MSDOS-binary) exit with error: > Wrong type argument: char-or-string-p, [128 128 129 129 130 130 131 13= 1 132 132 ...] > The vector is the :map value. Ah, I'll fix it soon. > 2. The `:post-read-conversion' function must return a number otherwise th= ere is an error. > There is nothing about it in `define-coding-system' documentation. I'm going to fix the docstring as this. `: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. > 3. The documentation for `write-region-annotate-functions' has: > "The function should return a list of pairs of the form (POSITION . S= TRING), > consisting of strings to be effectively inserted at the specified pos= itions > of the file being written (1 means to insert before the first byte wr= itten). > The POSITIONs must be sorted into increasing order." > This did not work at all. I had to use the alternate pathway: > An annotation function can return with a different buffer current. > Doing so removes the annotations returned by previous functions, and > resets START and END to `point-min' and `point-max' of the new buffer. For this part, I'm going to fix as this: `:pre-write-conversion' VALUE must be a function to call after all functions in `write-region-annotate-functions' and `buffer-file-format' are called, and before the text is encoded by the coding system itself. This function should convert the whole text in the current buffer. For backward compatibility, this funciton is passed two arguments which can be ignored. --- Kenichi Handa handa@m17n.org