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 15:30:04 +0100 Message-ID: <50F021EC.4040107@gmx.at> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.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 1357914668 811 80.91.229.3 (11 Jan 2013 14:31:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 14:31:08 +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 15: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 1Ttfdk-00071S-6M for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 15:31:24 +0100 Original-Received: from localhost ([::1]:58654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtfdT-0003sC-Fd for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 09:31:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtfdL-0003rY-40 for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 09:31:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtfdJ-0000Nj-1y for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 09:30:58 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtfdI-0000NU-V3 for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 09:30:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TtfdP-0005Mi-Cs for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 09:31:03 -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 14: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.135791463520589 (code B ref 13399); Fri, 11 Jan 2013 14:31:02 +0000 Original-Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 14:30:35 +0000 Original-Received: from localhost ([127.0.0.1]:55311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttfco-0005Lq-MP for submit@debbugs.gnu.org; Fri, 11 Jan 2013 09:30:33 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:53611) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttfcj-0005La-L2 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 09:30:23 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MF6gP-1TjUKp2YmZ-00GJSF for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 15:30:08 +0100 Original-Received: (qmail invoked by alias); 11 Jan 2013 14:30:08 -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 (mp017) with SMTP; 11 Jan 2013 15:30:08 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/ok1IDj2boy9ujGyPFBiY3Y3gTTsltoYBrW1y1hg YkXAWKwIxTl3tk In-Reply-To: <838v80ugv1.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:69606 Archived-At: >> 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. My bad. It works when I enable `visual-line-mode'. It doesn't with only `word-wrap' set to t. > Then the indicators should disappear on wrapped lines. [...] >> 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. Nothing serious. I detected zero-width spaces and noticed that emacs can display them, so I was mislead that word wrap would handle them. >> 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. Good. >> 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). Never mind, it works. What I meant was that when, for example, I have two adjacent parts of text with the same mouse-face property and the mouse hovers over one of the words, the other word gets highlighted as well. Maybe it's just stickyness or whatever, but till now I hadn't found a method to turn this off. Not recommended for normal buffers because `forward-char' appears to hang, but that's a different story. >> 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. OK. I take your word for it. Maybe it could be also useful for adding soft hyphens (if we can make `forward-char' handle them). >> Is it useful to make a _separate_ table for line-break properties? > > Why not? What existing table would you reuse for that? No idea. Do we have a list of predefined character tables somewhere? >> 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? This needs an up to date display, IIUC :-( > Anyway, how would you word-wrap in Lisp, except by adding display > strings with newlines (which AFAIR features like longlines > etc. already do)? By adding hard newlines. All I care about is to (1) show the entire buffer text in a fixed-width window and (2) make that window as small as possible. martin