From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: Re: whitespace includes U+3000 Date: Thu, 29 Jun 2006 11:01:15 +0900 Message-ID: References: <871wtegf13.fsf@jidanni.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1151546516 18266 80.91.229.2 (29 Jun 2006 02:01:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2006 02:01:56 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, handa@m17n.org, jidanni@jidanni.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 29 04:01:52 2006 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fvlqo-0000fm-1V for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Jun 2006 04:01:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fvlqn-0006r9-Qx for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2006 22:01:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fvlqm-0006qy-RD for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2006 22:01:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fvlql-0006pj-Qg for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2006 22:01:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fvlql-0006pa-MH for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2006 22:01:47 -0400 Original-Received: from [150.29.246.133] (helo=mx1.aist.go.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fvm3B-0006XG-Ne; Wed, 28 Jun 2006 22:14:38 -0400 Original-Received: from smtp4.aist.go.jp ([150.29.246.12]) by mx1.aist.go.jp with ESMTP id k5T21g0a020416; Thu, 29 Jun 2006 11:01:42 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id k5T21cZH010403; Thu, 29 Jun 2006 11:01:39 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1FvlqF-0007yZ-00; Thu, 29 Jun 2006 11:01:15 +0900 Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Wed, 28 Jun 2006 13:25:00 -0400) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:15185 Archived-At: In article , Richard Stallman writes: >> No. The current Emacs treat only TAB and SPACE as >> "whitespace" characters. >> It would be very easy to fix this by setting the syntax table entries >> for those characters--if there are not too many of them. So why not >> fix it? > Are you sure that "whitespace" of syntax has the same > meaning as the "whitespace" of show-trailing-whitespace? > I am not sure which one we're talking about here. > Is it show-trailing-whitespace? show-trailing-whitespace is just an example. I think his question is about all Emacs functionalities handling "whitespace" in some meaning (examples are listed by M-x apropos RET whitespace RET). > If so, that would also be easy to change, if it ought to be changed. Of course it's easy to change. The difficult thing is to determine if it ought to be changed. > For instance, currently ^L (formfeed) has syntax > "whitespace". But, it is displayed with glyph "^L". Should > it be the target of show-trailing-whitespace? > No. Then we have different meanings in "whitespace"; the set of characters that have "whitespace" syntax is different from the set of characters that are displayed by "whitespace" glyph. And, we can't use "whitespace" syntax at least for show-trailing-whitespace. > For instance, currently NBSP (U+00A0) has syntax "." > (punctuation), and it is displayed with special face to > indicated the existing of that character. Should it be > changed to "whitespace" syntax, or shoudn't be changed? > The special face for that character should not be overridden, but the > other whitespace after it _and before it_ should probably be displayed > specially by show-trailing-whitespace. > You can probably get this result by putting NBSP into the pattern > for show-trailing-whitespace to recognize. Redisplay will override > the face, for the NBSP. What do you mean by "pattern" here? Regular expression? Currently the function highlight_trailing_whitespace doesn't use regular expression but checks TAB and SPACE directly (i.e. hardcoded). By the way, I've just found that currently the special face for NBSP is overriden by show-trailing-whitespace. That is because highlight_trailing_whitespace is called at the near end of display_line. Anyway, Unicode has lots more space-like characters (e.g. U+2000..U+200B). Should them be treated by the same way as NBSP (i.e. displayed with nobreak-face)? Or as SPACE? How about the case of fixup-whitespace? It seems that this function should delete only TAB and SPACE. So, here we have the third meaning of "whitespace"; just TAB and SPACE. How about the case of delete-trailing-whitespace? How about the case of ... Do you think we should define the semantics of "whitespace" and "space character" in all cases clearly before the release, and should modify codes if necessary? --- Kenichi Handa handa@m17n.org