From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Miles Bader" Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: =?windows-1252?q?Re=3A_GNU_Emacs_22=2E0=2E50_fails_to_find_=E4_i?= =?windows-1252?q?n_different_ISO_Latin_encodings?= Date: Sat, 23 Sep 2006 08:25:08 +0900 Message-ID: References: <4CEE7BA9-0CEF-40CD-A081-2C707A44833B@web.de> <453787ED-925B-49B5-A203-3211329FCB13@web.de> <35A5EBE2-652D-488C-9CFD-E7B56A8C2D07@web.de> <9A1B7415-8272-41D8-A1D6-C6837CE5AC09@web.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1158967543 7532 80.91.229.2 (22 Sep 2006 23:25:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 22 Sep 2006 23:25:43 +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 Sat Sep 23 01:25:40 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 1GQuOZ-0004dQ-EC for ged-emacs-devel@m.gmane.org; Sat, 23 Sep 2006 01:25:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GQuOY-0005az-Nc for ged-emacs-devel@m.gmane.org; Fri, 22 Sep 2006 19:25:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GQuOM-0005Yi-HI for emacs-devel@gnu.org; Fri, 22 Sep 2006 19:25:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GQuOL-0005YI-To for emacs-devel@gnu.org; Fri, 22 Sep 2006 19:25:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GQuOL-0005YD-Qp for emacs-devel@gnu.org; Fri, 22 Sep 2006 19:25:09 -0400 Original-Received: from [66.249.82.228] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GQuSB-000790-KR for emacs-devel@gnu.org; Fri, 22 Sep 2006 19:29:07 -0400 Original-Received: by wx-out-0506.google.com with SMTP id i26so1319550wxd for ; Fri, 22 Sep 2006 16:25:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=aHUUedqxmnge+pwsvI/yPjmR26G/qtj2cAvW9rPLxmHDP55bz8utM4Tbalml9wzQ0JFjx64jpF8BarHcEhtldWWKgv0OY1tQJwmDnq6RDlfprslTfwUmDf3iwbiN2U5ax6s7v0od916mtI4wmvDu8XSssKgbMB0xT1k2dyUi57s= Original-Received: by 10.90.120.6 with SMTP id s6mr916849agc; Fri, 22 Sep 2006 16:25:08 -0700 (PDT) Original-Received: by 10.90.69.15 with HTTP; Fri, 22 Sep 2006 16:25:08 -0700 (PDT) Original-To: "Peter Dyballa" In-Reply-To: <9A1B7415-8272-41D8-A1D6-C6837CE5AC09@web.de> Content-Disposition: inline X-Google-Sender-Auth: 7fde7c69eb781e4f 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:60121 gmane.emacs.pretest.bugs:14119 Archived-At: On 9/23/06, Peter Dyballa wrote: > The improvement is that I can find via an Unicode value an ISO > Latin encoded character =96 is this an improvement? It's what you asked for -- that input codes use some well-known encoding rather than the unfamiliar emacs codes. > The file code is A4 > in any ISO Latin case, and the character is U+20AC in Unicode when in > ISO Latin-10/ISO Latin-0 or ISO Latin-9. This looks like a Do What I > Mean. Really not bad! But the real way should be C-s C-q 2 4 4 RET or > C-s C-q A 4 RET or C-s C-q 1 6 4 RET (decimal), because it searches > for the codes one expects in the encoded file, and which does not work. I think that sounds awful -- I do not think users want to learn the codepoints in all encodings they use, they simply want to be able to enter _characters_ that they don't know how to enter via the keyboard. UCS codepoints are good because they allow _all_ emacs characters to be entered in a consistent way. Having C-q use the buffer's file encoding on the other hand seems quite annoying, because it requires users to use different numbers depending on what the file they're editing was saved in (and I suspect a large portion of the time, users don't even _know_ what encoding their file uses). Nonetheless, if you feel that is the right method, feel free to implement it and allow us to try it out (I offered the patch above because it is very simple and offers useful functionality, but I do not know offhand how to implement what you want). -Miles --=20 Do not taunt Happy Fun Ball.