all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 13399@debbugs.gnu.org
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	[thread overview]
Message-ID: <838v80ugv1.fsf@gnu.org> (raw)
In-Reply-To: <50EFE99A.5070508@gmx.at>

> Date: Fri, 11 Jan 2013 11:29:46 +0100
> From: martin rudalics <rudalics@gmx.at>
> 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)?





  reply	other threads:[~2013-01-11 10:57 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10  8:29 bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B martin rudalics
2013-01-10 19:15 ` Eli Zaretskii
2013-01-11  8:16   ` martin rudalics
2013-01-11  8:58     ` Eli Zaretskii
2013-01-11 10:29       ` martin rudalics
2013-01-11 10:57         ` Eli Zaretskii [this message]
2013-01-11 14:30           ` martin rudalics
2013-01-11 14:49             ` Eli Zaretskii
2013-01-11 15:17               ` martin rudalics
2013-01-11 15:22                 ` Christopher Schmidt
2013-01-11 18:04                   ` martin rudalics
2013-01-11 15:53                 ` Eli Zaretskii
2013-01-11 18:04                   ` martin rudalics
2013-01-11 16:08             ` Stefan Monnier
2013-01-11 18:06               ` martin rudalics
2013-01-11 18:50                 ` Stefan Monnier
2013-01-11 19:29                   ` Eli Zaretskii
2013-01-11 22:47                     ` Stefan Monnier
2013-01-12  8:28                       ` Eli Zaretskii
2013-01-12 13:20                         ` Stefan Monnier
2013-01-12 14:12                           ` Eli Zaretskii
2013-01-12 16:06                             ` Stefan Monnier
2013-02-02 16:48                         ` martin rudalics
2013-02-02 17:52                           ` Eli Zaretskii
2013-02-02 18:20                             ` martin rudalics
2013-02-02 18:36                               ` Eli Zaretskii
2013-02-03  9:44                                 ` martin rudalics
2013-02-03 16:01                                   ` Stefan Monnier
2013-02-03 19:32                                   ` Eli Zaretskii
2013-02-04 17:04                                     ` martin rudalics
2013-02-04 17:57                                       ` Eli Zaretskii
2013-01-11 19:08                 ` Eli Zaretskii
2013-01-12 14:29                   ` martin rudalics
2013-01-12 14:56                     ` Eli Zaretskii
2013-01-12 16:37                       ` martin rudalics
2013-01-12 16:51                         ` Eli Zaretskii
2013-01-12 18:01                           ` martin rudalics
2013-01-12 18:38                             ` Eli Zaretskii
2013-01-14 18:04                               ` martin rudalics
2013-02-03 18:57   ` martin rudalics
2013-02-03 19:45     ` Eli Zaretskii
2017-12-08  1:02 ` Adam Tack
2017-12-08 10:12   ` martin rudalics
2017-12-08 15:38   ` Eli Zaretskii
2017-12-08 20:08     ` Eli Zaretskii
2017-12-09  3:50       ` Adam Tack
2017-12-12 17:13         ` Eli Zaretskii
2017-12-13  4:00           ` Adam Tack
2017-12-13 16:09             ` Eli Zaretskii
2017-12-17  2:22               ` Adam Tack
2020-09-18 14:55                 ` Lars Ingebrigtsen
2020-09-18 15:39                   ` Eli Zaretskii
2020-09-19 13:15                     ` Lars Ingebrigtsen
2020-09-19 14:36                       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=838v80ugv1.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=13399@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.