From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter Dyballa Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: =?iso-8859-1?q?Re=3A_GNU_Emacs_22=2E0=2E50_fails_to_find_=E4_in_?= =?iso-8859-1?q?different_ISO_Latin_encodings?= Date: Fri, 22 Sep 2006 11:06:03 +0200 Message-ID: <453787ED-925B-49B5-A203-3211329FCB13@web.de> References: <1B8CD230-9A54-4F2A-B0FA-5CD02730F034@web.de> <4CEE7BA9-0CEF-40CD-A081-2C707A44833B@web.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1158916069 25004 80.91.229.2 (22 Sep 2006 09:07:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 22 Sep 2006 09:07:49 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org, rms@gnu.org, Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 22 11:07:48 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GQh0S-0006a8-4A for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2006 11:07:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GQh0Q-0002tR-N5 for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2006 05:07:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GQgzy-0002qq-Nz for emacs-devel@gnu.org; Fri, 22 Sep 2006 05:07:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GQgzx-0002nJ-Bj for emacs-devel@gnu.org; Fri, 22 Sep 2006 05:07:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GQgzw-0002mY-SO; Fri, 22 Sep 2006 05:07:05 -0400 Original-Received: from [217.72.192.227] (helo=fmmailgate02.web.de) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GQh3c-0004hw-3R; Fri, 22 Sep 2006 05:10:52 -0400 Original-Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id 8004D210EA94; Fri, 22 Sep 2006 11:06:07 +0200 (CEST) Original-Received: from [87.193.29.218] (helo=[192.168.1.2]) by smtp06.web.de with asmtp (TLSv1:RC4-SHA:128) (WEB.DE 4.107 #114) id 1GQgz0-00027Q-00; Fri, 22 Sep 2006 11:06:06 +0200 In-Reply-To: X-Image-Url: http://homepage.mac.com/sparifankal/.cv/thumbs/me.thumbnail Original-To: Miles Bader X-Mailer: Apple Mail (2.752.2) X-Sender: Peter_Dyballa@web.de 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:60093 gmane.emacs.pretest.bugs:14090 Archived-At: Am 22.09.2006 um 02:44 schrieb Miles Bader: > Peter Dyballa writes: >> Anyway, what also does not work is: C-s C-q > greater >> 177 octal code>. For those with really small keyboards this is the >> (almost?) only chance to find some of the x times 64 K characters in >> Unicode ... > > Eh? It works for me: > > E.g., the Emacs 22 character code of "=E5=AD=97" is octal 0156772. > > If I enter C-s C-q 0156772 (followed by some other char to =20 > terminate the > octal code), it correctly adds that character to the search string =20 > (and > finds in the buffer). OK, I did not check in the "higher" Unicode regions, and I did not =20 check in an UTF-8 encoded buffer, and I did not input so long numbers =20= I cannot compute, I was still in my simple ISO 8859-X test files =20 (your example works for me too in an UTF-8 encoded buffer). After =20 launching GNU Emacs 22.0.50 with -Q the phenomenon seems to be that =20 input like C-s C-q <[23][0-7][0-7]> RET is interpreted as trying to "name/point to" an ISO 8859-1 encoded =20 character. For example: C-s C-q 245 in ISO 8859-16 does not find ``=E2=80=9E=C2=B4=C2=B4 = (U+201E) =E2=80=93 mini-=20 buffer tells me that ``=C2=A5=C2=B4=C2=B4 (\245 in ISO 8859-1) cannot be = found. C-s C-q 241 RET searches for =C2=A1. C-s C-q 242 RET searches for =C2=A2. C-s C-q 243 RET searches for =C2=A3. C-s C-q 244 RET searches for =C2=A4 (CURRENCY SIGN, U+00A4). Evaluating (unify-8859-on-decoding-mode t) does not change this =20 specific behaviour. Which is the formula to map octal 0156772 to a Unicode slot/position? =20= Octal 0156772 is DDFA in hex, which is different from 5B57, =E5=AD=97's =20= position in Unicode. Or: how can I find the octal value for a given =20 Unicode slot (U+ABCD)? There is probably some function for this =20 purpose ... -- Greetings Pete "It isn't pollution that's harming the environment. It's the =20 impurities in our air and water that are doing it."