From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Several serious problems Date: Wed, 24 Jul 2002 13:37:49 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200207240437.NAA26632@etlken.m17n.org> References: <200207221711.g6MHBZo02496@aztec.santafe.edu> <200207231335.WAA25692@etlken.m17n.org> <200207240325.g6O3PdX04898@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1027485502 1784 127.0.0.1 (24 Jul 2002 04:38:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2002 04:38:22 +0000 (UTC) Cc: spiegel@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17XDuk-0000SX-00 for ; Wed, 24 Jul 2002 06:38:18 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XE9O-0000WM-00 for ; Wed, 24 Jul 2002 06:53:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XDur-0002hg-00; Wed, 24 Jul 2002 00:38:25 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17XDuJ-0002fy-00; Wed, 24 Jul 2002 00:37:51 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g6O4bnl19337; Wed, 24 Jul 2002 13:37:49 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g6O4bn928304; Wed, 24 Jul 2002 13:37:49 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id NAA26632; Wed, 24 Jul 2002 13:37:49 +0900 (JST) Original-To: rms@gnu.org In-Reply-To: <200207240325.g6O3PdX04898@aztec.santafe.edu> (message from Richard Stallman on Tue, 23 Jul 2002 21:25:39 -0600 (MDT)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6005 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6005 In article <200207240325.g6O3PdX04898@aztec.santafe.edu>, Richard Stallman writes: > Do you mean a command something like this? > (defun check-coding-system-region (from to coding-system &optional max-num) > "Check if the text after point is encodable by the specified coding system. > When called from a program, takes three arguments: > CODING-SYSTEM, FROM, and TO. START and END are buffer positions. > Value is a list of positions of characters that are not encodable by > CODING-SYSTEM. > Optional 4th argument MAX-NUM, if non-nil, limits the length of > returned list. By default, there's no limit." > This could do the internals of the job. To be useful, it needs a user > interface. Ooops, I forgot to include this sentence in the docstring. If an unencodable character is found, move point to that character. So, this function can be used both for an internal job and for an interactive job (to find the next unencodable character). > How about if you modify it to make overlays to highlight those characters > instead of returning a list saying where they are? If the specified coding system is totally inappropriate for the buffer, highlighting them will results in huge amount of overlays and also it takes long time to finish the job. If we limit the number of highlighting, it may give users incorrect information (i.e. non-highlighted characters seems to be encodable). So, I thought just moving point to the next unencodable character is better. --- Ken'ichi HANDA handa@etl.go.jp