From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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 11:29:46 +0100 Message-ID: <50EFE99A.5070508@gmx.at> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1357900270 26181 80.91.229.3 (11 Jan 2013 10:31:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 10:31:10 +0000 (UTC) Cc: 13399@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 11 11:31:25 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 1TtbtQ-0004wm-FN for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 11:31:20 +0100 Original-Received: from localhost ([::1]:41500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtbtA-000236-EE for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 05:31:04 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttbt6-00022v-Jv for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:31:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ttbt3-0001jH-0F for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:31:00 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttbt2-0001j5-TG for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:30:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ttbt8-0007En-JK for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 05:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jan 2013 10:31:02 +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.135790020827751 (code B ref 13399); Fri, 11 Jan 2013 10:31:02 +0000 Original-Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 10:30:08 +0000 Original-Received: from localhost ([127.0.0.1]:55133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtbsF-0007DY-8u for submit@debbugs.gnu.org; Fri, 11 Jan 2013 05:30:07 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:63573) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtbsB-0007C8-O6 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 05:30:05 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ljfl8-1TI47r2lmy-00bdlv for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 11:29:51 +0100 Original-Received: (qmail invoked by alias); 11 Jan 2013 10:29:51 -0000 Original-Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp032) with SMTP; 11 Jan 2013 11:29:51 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/YqvV0ShnYom1Ac2T1WpBwWA3KdkprnDK6BgvCMa udPx/Wb8BTZBys In-Reply-To: <83ip74ume7.fsf@gnu.org> X-Y-GMX-Trusted: 0 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:69599 Archived-At: >> > 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? >> 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? The doc-string should say so. >> 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)? Does this also mean that I can separate text properties of adjacent words by inserting a zero-width space between them? > #define IT_DISPLAYING_WHITESPACE(it) \ > /* If the character to be displayed is SPC or TAB */ [...] > In any case, you can clearly see that it only tests for literal SPC > and TAB characters. Even if I don't understand the code I can see that, yes. >> > 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. > 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? >> Anway, exposing displayed text to Lisp would be great. We'd just need >> two functions - one that gets the pixel width of an arbitrary buffer >> string wrt a specific window, and one that gets the pixel height of an >> arbitrary buffer string (newlines ignored) wrt a specific window. This >> way we could get rid of lots of problems currently hidden in the display >> engine ... > > You lost me here. By "exposing to Lisp" I meant expose the char-table > of word-wrap characters to Lisp. I only now understand what you meant. > 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. martin