From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: whitespace includes U+3000 Date: Thu, 29 Jun 2006 13:57:34 -0400 Message-ID: References: <871wtegf13.fsf@jidanni.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1151603911 1317 80.91.229.2 (29 Jun 2006 17:58:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2006 17:58:31 +0000 (UTC) Cc: jidanni@jidanni.org, handa@m17n.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 29 19:58:27 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 1Fw0mT-0003fV-1U for ged-emacs-devel@m.gmane.org; Thu, 29 Jun 2006 19:58:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fw0mS-00039q-JV for ged-emacs-devel@m.gmane.org; Thu, 29 Jun 2006 13:58:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fw0lk-0002k6-Jq for emacs-devel@gnu.org; Thu, 29 Jun 2006 13:57:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fw0lj-0002jQ-Vt for emacs-devel@gnu.org; Thu, 29 Jun 2006 13:57:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fw0lj-0002jF-J3 for emacs-devel@gnu.org; Thu, 29 Jun 2006 13:57:35 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fw0yK-0007SI-GA for emacs-devel@gnu.org; Thu, 29 Jun 2006 14:10:36 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Fw0li-00023u-6T; Thu, 29 Jun 2006 13:57:34 -0400 Original-To: Kenichi Handa In-reply-to: (message from Kenichi Handa on Thu, 29 Jun 2006 11:01:15 +0900) 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:56298 Archived-At: 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. That's right. There is "characters that would print as whitespace" and there is "characters that would display as whitespace in Emacs." These are different for good reason; it is not a mistake that they are different. Maybe we need to clarify the documentation so that people will understand that there are two different concepts of whitespace. In theory we might want to use two different words for these concepts. But that seems strained and difficult. They really are two applications of of the standard concept of "whitespace". We might want to speak of "screen whitespace" and "text whitespace". And, we can't use "whitespace" syntax at least for show-trailing-whitespace. Yes, that is true. > 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? Yes, I assumed it used one. However, on second thought, I've concluded that show-trailing-whitespace doesn't need to know about NBSP at all. Since NBSP is now indicated on the screen by a color, it is no longer likely to go unnoticed. So there is no problem with NBSP and show-trailing-whitespace. show-trailing-whitespace ought to know about all characters that will be indistinguishable on the screen from "end of the line". By the way, I've just found that currently the special face for NBSP is overriden by show-trailing-whitespace. Do you mean, show-trailing-whitespace would override the special face for NBSP _if_ you modify it to recognize NBSP along with SPC and TAB? That means my expectation was mistaken; I stand corrected. But since show-trailing-whitespace does not need to recognize NBSP, this isn't a _problem_. 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? It depends how they are used. How does Emacs display them? 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. It is an interesting question what fixup-whitespace should do with NBSP. I am not sure; it depends on how NBSP is used. When the existing space is just one NBSP, fixup-whitespace should not change it. Do people use multiple NBSP to force more space between two words? If so, maybe fixup-whitespace should leave that untouched. Or maybe fixup-whitespace should convert a run of NBSP to a single NBSP. When there is a series of whitespace including NBSP and SPC (or TAB), the runs of ordinary whitespace should be compacted to a single SPC, and the runs of NBSP should be treated as above. Similar reasoning needs to be applied to other kinds of whitespace, to figure out what behavior users will really find useful and helpful in fixup-whitespace. How about the case of delete-trailing-whitespace? That is meant to get rid of junk. It should probably delete NBSP just like SPC and TAB, since that is useless at the end of a line.