all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Adam Tack <adam.tack.513@gmail.com>
Cc: 13399@debbugs.gnu.org
Subject: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B
Date: Fri, 08 Dec 2017 17:38:29 +0200	[thread overview]
Message-ID: <83609hw7pm.fsf@gnu.org> (raw)
In-Reply-To: <CAA+VxxHdj3795qbgTJV-EE_G+nC9-yLGvjs5KmQJMN4RE-RMAA@mail.gmail.com> (message from Adam Tack on Fri, 8 Dec 2017 01:02:08 +0000)

> From: Adam Tack <adam.tack.513@gmail.com>
> Date: Fri, 8 Dec 2017 01:02:08 +0000
> 
> I have a patch for the original issue of word-wrap not wrapping at a
> zero-width space.  The implementation uses a character table, and is
> closely based on that written by Martin Rudalics
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13399#113), with Eli
> Zaretski's suggestions regarding unicode.

Thanks for working on this!

> However, this is my first foray into modifying a serious C codebase,
> so I am not sure if I have done the right thing.  In particular, I
> have serious doubts about the second and third cases from
> IT_DISPLAYING_WHITESPACE, especially since I don't really know when
> they would be applicable.
> 
>    || ((STRINGP (it->string)                        \
>     && !NILP (CHAR_TABLE_REF                    \
>           (Vword_wrap_chars, STRING_CHAR            \
>            (SDATA (it->string) + IT_STRING_BYTEPOS (*it)))))    \
>        || (it->s && !NILP (CHAR_TABLE_REF                \
>                (Vword_wrap_chars,                \
>                 STRING_CHAR(it->s + IT_BYTEPOS (*it)))))    \

I think this is okay, but maybe the macro could be converted into an
inline function, and then fetching the character from the various
objects separated from looking up the char-table for that character?

> Additionally, I'm not certain whether syms_of_character in character.c
> is the right location for the definition of the char-table and whether
> the range of characters U+2000 to U+200B should be in the chartable,
> or if it should just be space and tab, by default.

Well, since it's a char-table, users will probably want to control
which characters cause word-wrap.  One idea would be to have a minor
mode or some such, providing users an ability to include or exclude
different groups of related whitespace characters as a whole?  This
could be in follow-up patches, though.

We could also look at LineBreak.txt in the Unicode database for
inspiration and ideas.

But I do think that the default should be only TAB and SPC, as Emacs
always did, and the rest should be optional, and probably in Lisp, not
C.

> I am aware that if this were to be accepted, I would also need to make
> a change to etc/NEWS, probably the docstring of `word-wrap' and
> somewhere in the Texinfo manual.

And also a couple of tests (the ones you used would be a good start).

> I have not yet filled out a copyright assignment form, though I will
> do so if this patch (modulo changes) is considered acceptable.

I will send the forms off-list, thanks.





  parent reply	other threads:[~2017-12-08 15:38 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
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 [this message]
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=83609hw7pm.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=13399@debbugs.gnu.org \
    --cc=adam.tack.513@gmail.com \
    /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.