> Right, I missed that.  But then I guess it might be better to leave
> this a macro, as the function is not prettier.  Or maybe leave the
> case of the char-table being nil as a macro, and put the rest in a
> function, like we do in several other places.

I've split out the non-nil char-table case out into a function, as I
think that using a named function slightly improves readability, and
having a macro over 20 lines long, somehow feels "wrong".  If the
compiler does actually follow the inline directive, there should be no
additional performance hit.

Is the convention for "static inline" functions to be in lower-case?
(The few cases that I've found in w32term.c are not capitalised.)

Attached is a working (and hopefully complete) patch for word-wrap
using the `word-wrap-chars' char-table (without a nice lisp
interface).


Also attached is a patch for the lisp interface.

However, upon reflection, I'm not sure whether my approach of using a
new minor mode (the horribly named `word-wrap-chars-mode') is the
best, as it's not very discoverable and adds yet another minor mode,
whose existence must be remembered and whose lighter will clutter the
mode-line.  The alternative would be to just use `visual-line-mode',
without changing the default behaviour and allow customization by
customizing `word-wrap-type'.

`visual-line-mode' would then be modified slightly so that, when
being enabled:

i)  it calls `set-word-wrap-chars',
ii) it saves `word-wrap-chars' to `visual-line--saved-state', if it
had been locally set (like for the other relevant variables),

and when disabled, it unsets `word-wrap-chars'.  The default of
`word-wrap-type' would be changed to ascii-whitespace.

By default, the effect of `visual-line-mode' would not change, other
than a redundant call to `set-word-wrap-chars' which would keep
`word-wrap-chars' set to nil.  `word-wrap-type' would have to be
customized for char-table-based wrapping to be used.  Would such
a change to `visual-line-mode' be acceptable?

(The attached patch for the lisp interface then mostly stays the same,
other than the dropping of `word-wrap-chars-mode'.)


An option to add all unicode line breaking characters from
LineBreak.txt to the `word-wrap-chars' char-table is still missing, as
I'm not too comfortable with the unicode-category-table, it's probably
not an option too urgently needed and it would be an incomplete
implementation anyway, since the algorithm can only use the last
character, not the following one, or the surroundings.

Would the cleanest approach be to add a new `line-break' character
property (corresponding to the Unicode Line_Break:
http://unicode.org/reports/tr44/#Line_Break ), set it by parsing
LineBreak.txt (during compilation of emacs), and then set
`word-wrap-chars' based on which characters have the correct
`line-break' property (SP, ZW, BA, B2, HY (?), SY (?), CB (???),
SA (???)) when needed (and perhaps cache it)?


Thank you for your continued guidance and best wishes,
Adam