From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Date: Fri, 11 Jan 2013 12:57:38 +0200 Message-ID: <838v80ugv1.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1357901882 8792 80.91.229.3 (11 Jan 2013 10:58:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 10:58:02 +0000 (UTC) Cc: 13399@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 11 11:58:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TtcJW-0003Cx-Pk for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 11:58:19 +0100 Original-Received: from localhost ([::1]:56813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtcJG-0002Fz-Kk for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 05:58:02 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtcJC-0002Ff-Cd for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:58:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtcJA-0000lu-Ha for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:57:58 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtcJA-0000lo-De for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:57:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TtcJF-0007qf-WD for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jan 2013 10:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13399 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13399-submit@debbugs.gnu.org id=B13399.135790185330133 (code B ref 13399); Fri, 11 Jan 2013 10:58:01 +0000 Original-Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 10:57:33 +0000 Original-Received: from localhost ([127.0.0.1]:55159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtcIn-0007px-BV for submit@debbugs.gnu.org; Fri, 11 Jan 2013 05:57:33 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37233) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtcIl-0007pi-06 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 05:57:32 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGG00900JR4UK00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 12:57:18 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG009YUJRHKT50@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 12:57:18 +0200 (IST) In-reply-to: <50EFE99A.5070508@gmx.at> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:69600 Archived-At: > Date: Fri, 11 Jan 2013 11:29:46 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> > You mean, not wrapped at all. Witness the continuation bitmaps in the > >> > fringes, which shouldn't appear when a line is wrapped. > >> > >> I thought these bitmaps appear when a line is wrapped. > > > > Not by default. Not unless you customize visual-line-fringe-indicators. > > With emacs -Q I see curly arrows in the fringes regardless of whether I > set `visual-line-fringe-indicators' or not. What am I missing? If this is still with u+200B? You need to try with regular spaces. Then the indicators should disappear on wrapped lines. > >> The doc-string of `word-wrap' says > >> > >> When word-wrapping is on, continuation lines are wrapped at the space > >> or tab character nearest to the right window edge > >> > >> Since U-200B is a space character the line should wrap at it. > > > > No, it means literally "the space character", U+0020. > > So `word-wrap' is ASCII-only? Yes. > The doc-string should say so. Well, I personally find it hard to imagine that "the space character" could be interpreted as something other than U+0020. But I see what you mean. > >> and Emacs apparently does handle it specially since it reserves a few > >> pixels when drawing it. > > > > See glyphless-char-display and glyphless-char-display-control for why. > > IIUC it has a `thin-space' display method entry and I could set this to > `zero-width' (the doc-string of `glyphless-char-display' is ambiguous > about that)? Yes. > Does this also mean that I can separate text properties of > adjacent words by inserting a zero-width space between them? Yes, I think so (if I understand correctly what you mean). > >> > If we want to add more characters to the set, we should probably > >> > arrange a special char-table for this, and have it exposed to Lisp, so > >> > it could be customized. Patches are welcome. > >> > >> IIUC all breakable spaces are between U-2000 and U-200B so maybe a > >> character table is not needed. > > > > Who said we want only break at breakable space characters? Who said > > Unicode will never add more such characters in another block? And > > what about low-ASCII characters, which are already in a different > > block? > > But implementing a character table and working with it is harder. I don't think it's harder, it's actually very simple. You have a simple API for setting values in the table and a simple API for accessing a property of a character. > > In any case, even if you are right, a char-table is a way to store > > character properties efficiently. In particular, it will waste very > > little storage to mark a contiguous range of characters with the same > > property. The advantage of using a char-table is that it will > > dynamically expand as needed if more characters are added to the set. > > Is it useful to make a _separate_ table for line-break properties? Why not? What existing table would you reuse for that? > > What did _you_ want exposed to Lisp? > > Two functions: One to get the width of some arbitrary buffer text in > pixels and one to get the full height of a buffer text line in pixels. > The former would be used for doing word-wrapping variants in Lisp, the > latter for fitting windows to their buffers. The latter already exists as window-line-height, doesn't it? Anyway, how would you word-wrap in Lisp, except by adding display strings with newlines (which AFAIR features like longlines etc. already do)?