bug#2749: 23.0.91; Visual Line Mode: incorrect line wrapping in corner case

[pent]

Hello!

I've discovered a minor problem with the new Visual Line Mode. To
reproduce:

0) emacs -Q

1) Switch to the *scratch* buffer.

2) Select menu item Options/Line Wrapping in this Buffer/Wrap at
Window Edge.

3) Type '-' symbol. Keep typing '-' until the the line is
wrapped. Delete the last symbol (the one which caused
wrapping). The line should now be fully filled with '-'s, and there
should be no wrapping.

4) Hit Enter and repeat 3). There are now 2 fully filled lines one
after another, with no space between them (expected).

5) Select menu item Options/Line Wrapping in this Buffer/Word Wrap
(Visual Line Mode). An empty line between 2 lines has appeared
(unexpected).

I've found the inconsistency while working with horizontally split
Ediff windows, where the probability of wrapping exactly at the line
width is high. Hope the fix is trivial.

I'm ready to provide any additional info,
Andrey Paramonov

In GNU Emacs 23.0.91.1 (i486-pc-linux-gnu, GTK+ Version 2.14.7)
of 2009-03-20 on elegiac, modified by Debian
(emacs-snapshot package, version 1:20090320-1)
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.91/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.91/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''

Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ru_RU.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t

Major mode: svn-status

Minor modes in effect:
TeX-PDF-mode: t
diff-auto-refine-mode: t
delete-selection-mode: t
show-paren-mode: t
pc-selection-mode: t
pretty-control-l-mode: t
shell-dirtrack-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
global-visual-line-mode: t
visual-line-mode: t
transient-mark-mode: t

[Chong Yidong]

> 3) Type '-' symbol. Keep typing '-' until the the line is
> wrapped. Delete the last symbol (the one which caused
> wrapping). The line should now be fully filled with '-'s, and there
> should be no wrapping.

> 4) Hit Enter and repeat 3). There are now 2 fully filled lines one
> after another, with no space between them (expected).

> 5) Select menu item Options/Line Wrapping in this Buffer/Word Wrap
> (Visual Line Mode). An empty line between 2 lines has appeared
> (unexpected).

This behavior is expected. The word wrap algorithm treats lines that
are too long to wrap using the ordinary line-wrapping rules, and since
overflow-newline-into-fringe is disabled in Visual Line mode, the extra
empty line is used to show the non-overflowed newline character.

After the release, I might look into letting word wrap handle
overflow-newline-into-fringe behavior. I suspect, however, that this
may lead to confusing results in some circumstances.

[Stefan Monnier]

> This behavior is expected. The word wrap algorithm treats lines that
> are too long to wrap using the ordinary line-wrapping rules, and since
> overflow-newline-into-fringe is disabled in Visual Line mode, the extra
> empty line is used to show the non-overflowed newline character.

> After the release, I might look into letting word wrap handle
> overflow-newline-into-fringe behavior. I suspect, however, that this
> may lead to confusing results in some circumstances.

BTW: why is overflow-newline-into-fringe ignored when word-wrap is
non-nil? What kind of confusing results are you thinking of?

Stefan

[Stephen Berman]

I would like to use a string of length window-width in a display overlay
together with word-wrap and a non-nil wrap-prefix. Currently this
results in a following empty line with indentation, which is rather
disconcerting. But after removing `&& (IT)->line_wrap != WORD_WRAP'
from the definition of IT_OVERFLOW_NEWLINE_INTO_FRINGE and rebuilding
Emacs, the empty indented line is gone and I have just what I want. I
haven't yet seen anything confusing. So I too would be very interested
to know if there are known or suspected problems with allowing non-nil
overflow-newline-into-fringe with word-wrap. If it's not clear there
are any, could we allow it and then see if anyone screams bloody murder?

Steve Berman

[Stephen Berman]

I've been using Emacs as described above (i.e., with the patch below)
and till today have had no problems, but I just bumped into one, which
is indeed confusing, even pretty nasty. I've reproduced it with -Q on a
fresh build from the latest trunk (with the patch added). I don't know
how to debug it, but I will describe how to reproduce it, in the hope
that someone can fix it (or at least give me some help in trying to
debug it) and then hopefully overflow-newline-into-fringe can be allowed
in Visual Line mode.

Here's the recipe:

-1. Apply the following patch and rebuild Emacs:

*** /home/steve/bzr/emacs/trunk/src/xdisp.c 2013-05-10 12:51:51.000000000 +0200
--- /home/steve/bzr/emacs/quickfixes/src/xdisp.c 2013-05-10 14:56:22.000000000 +0200
***************
*** 378,385 ****
&& ((IT)->bidi_it.paragraph_dir == R2L \
? (WINDOW_LEFT_FRINGE_WIDTH ((IT)->w) > 0) \
: (WINDOW_RIGHT_FRINGE_WIDTH ((IT)->w) > 0)) \
! && (IT)->current_x == (IT)->last_visible_x \
! && (IT)->line_wrap != WORD_WRAP)

#else /* !HAVE_WINDOW_SYSTEM */
#define IT_OVERFLOW_NEWLINE_INTO_FRINGE(it) 0
--- 378,384 ----
&& ((IT)->bidi_it.paragraph_dir == R2L \
? (WINDOW_LEFT_FRINGE_WIDTH ((IT)->w) > 0) \
: (WINDOW_RIGHT_FRINGE_WIDTH ((IT)->w) > 0)) \
! && (IT)->current_x == (IT)->last_visible_x)

#else /* !HAVE_WINDOW_SYSTEM */
#define IT_OVERFLOW_NEWLINE_INTO_FRINGE(it) 0

0. emacs -Q
1. Type `C-u 69 x SPC C-u 10 x' to make a string of 69 x's followed by a
space followed by a string of 10 x's; point should be in the fringe.
2. Type `RET C-u 69 x RET C-u 69 x' to add two more lines 69 x's long
(this is not essential to show the bug but helps in describing its
effects).
3. M-x visual-line-mode; now the string of 10 x's in the first line has
wrapped to occupy its own visual line below the first string of x's,
i.e., you see a line of 69 x's followed by a line of 10 x's followed
by two more lines of 69 x's.
4. If you click with the mouse (which button doesn't matter, but mouse-1
is least intrusive) anywhere in the buffer up to and including the
space following the last x in the first line of x's, point is set
where you click, as usual.
Now come the confusing results.
5. If you click with the mouse on the first column after the space at
the end of the first line of x's, point is set on the first x of the
following word-wrap line; if you click on the second column after the
space, point is set on the second x below, and so on up to the fringe
in the first line of x's.
6. If you click with the mouse on any position starting with the first x
in the second, visual, line (the word-wrapped line), point is set one
line below in the same column. The goes for all following lines in
the buffer, even if not word-wrapped (actually, with further
word-wrapping below the first word-wrapped line, I've seen point
being set two lines below, but it's harder to reproduce that).
7. If you put point (using the keyboard, whose events are not effected
by this bug) somewhere on the second line of 69 x's (the one just
below the word-wrapped line of 10 x's) and then type `C-l' twice to
move that line to the top of the window, now clicking with the mouse
anywhere on this line or lower again correctly sets point where you
click. If you scroll vertically so that the word-wrapped line is
again visible in the window, the point setting problem happens again.
8. If you add one character to the first line of x's, thus making its
(unwrapped) length longer than window-width, the point setting
problem does not happen.

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Date: Fri, 10 May 2013 16:01:22 +0200
> Cc: pent <pe...@aparamon.msk.ru>, 27...@debbugs.gnu.org

>
> I've been using Emacs as described above (i.e., with the patch below)
> and till today have had no problems, but I just bumped into one, which
> is indeed confusing, even pretty nasty. I've reproduced it with -Q on a
> fresh build from the latest trunk (with the patch added). I don't know
> how to debug it, but I will describe how to reproduce it, in the hope
> that someone can fix it (or at least give me some help in trying to
> debug it) and then hopefully overflow-newline-into-fringe can be allowed
> in Visual Line mode.

Does the patch below fix the problem (and whatever original problem
that led you to this recipe)?

--- src/xdisp.c~0 2013-05-10 17:56:44.338000000 +0300
+++ src/xdisp.c 2013-05-10 17:57:07.197375000 +0300
@@ -8466,7 +8466,8 @@
&& it->bidi_it.paragraph_dir == R2L)
? WINDOW_LEFT_FRINGE_WIDTH (it->w)
: WINDOW_RIGHT_FRINGE_WIDTH (it->w)) == 0
- || IT_OVERFLOW_NEWLINE_INTO_FRINGE (it))
+ || (IT_OVERFLOW_NEWLINE_INTO_FRINGE (it)
+ && it->line_wrap != WORD_WRAP))
{
if (!get_next_display_element (it))
{

[Stephen Berman]

Yes, it fixes the "confusing results" with the patch in my previous
mail. Thanks very much! (I wish I understood why this problem occurred
and how your patch fixes it...) Unless someone knows of another problem
with allowing overflow-newline-into-fringe in Visual Line mode, I would
like to request that both my patch and yours be committed to the trunk;
I can do that if I'm given the go-ahead. Then I think this bug could be
closed.

Steve Berman

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Cc: mon...@iro.umontreal.ca, pe...@aparamon.msk.ru, 27...@debbugs.gnu.org
> Date: Fri, 10 May 2013 17:49:40 +0200

>
> > Does the patch below fix the problem (and whatever original problem
> > that led you to this recipe)?
> >
> > --- src/xdisp.c~0 2013-05-10 17:56:44.338000000 +0300
> > +++ src/xdisp.c 2013-05-10 17:57:07.197375000 +0300
> > @@ -8466,7 +8466,8 @@
> > && it->bidi_it.paragraph_dir == R2L)
> > ? WINDOW_LEFT_FRINGE_WIDTH (it->w)
> > : WINDOW_RIGHT_FRINGE_WIDTH (it->w)) == 0
> > - || IT_OVERFLOW_NEWLINE_INTO_FRINGE (it))
> > + || (IT_OVERFLOW_NEWLINE_INTO_FRINGE (it)
> > + && it->line_wrap != WORD_WRAP))
> > {
> > if (!get_next_display_element (it))
> > {
>
> Yes, it fixes the "confusing results" with the patch in my previous
> mail. Thanks very much!

You are welcome.

> (I wish I understood why this problem occurred and how your patch
> fixes it...)

I didn't really debug it, I just applied Sherlock Holmes's principle:
when you have eliminated all the other possible explanations, the one
that stays is the correct one.

IT_OVERFLOW_NEWLINE_INTO_FRINGE is used in a small number of places.
Most of them are related to actually displaying text, which couldn't
be the reason here, because no text was displayed, only the cursor.
Of the 2 that are left, one was conditioned by it->line_wrap == TRUNCATE,
so again couldn't be the reason. What's left was the one I fixed, and
the fix just added back the condition you removed from
IT_OVERFLOW_NEWLINE_INTO_FRINGE.

I can give you a vague idea of why the problem occurred. When you
click the mouse, Emacs needs to determine what buffer position is at
that place, so it could move point there. The code which determines
buffer position from pixel coordinates simulates the display, starting
at the window beginning and producing glyphs for display (and
discarding them) until it gets to the desired pixel coordinates. The
code where I made the change is part of that display simulation. It
assumed without testing that word-wrap can never be on when
IT_OVERFLOW_NEWLINE_INTO_FRINGE is true, which means that you cannot
click outside of text, because text goes to the very end of the
window. But with the change in IT_OVERFLOW_NEWLINE_INTO_FRINGE, that
assumption was no longer true.

> Unless someone knows of another problem with allowing
> overflow-newline-into-fringe in Visual Line mode, I would like to
> request that both my patch and yours be committed to the trunk

Do you use Org mode or any other modes (e.g., magit) that are heavy
users of display strings? If not, then I'm not prepared to believe
that the above is the only problem with this change. I'd like to see
much more reports from users of those modes that this change doesn't
cause any trouble, before I'd agree to installing it. Just look how
much time it took until this problem popped up. Since I knew the only
change was in a single macro that is used in a small number of places,
fixing it was a 5-min job. But imagine that the same would happen 3
years after committing this change, with gazillions of unrelated
changes in the display code since then.

Thanks.

[Stephen Berman]

On Fri, 10 May 2013 20:37:08 +0300 Eli Zaretskii <el...@gnu.org> wrote:

>> From: Stephen Berman <stephen...@gmx.net>

[...]
>> (I wish I understood why this problem occurred and how your patch
>> fixes it...)
[...]
> I can give you a vague idea of why the problem occurred.

[...]

Thanks for the explanation.

>> Unless someone knows of another problem with allowing
>> overflow-newline-into-fringe in Visual Line mode, I would like to
>> request that both my patch and yours be committed to the trunk
>
> Do you use Org mode or any other modes (e.g., magit) that are heavy
> users of display strings?

I don't use either of those modes, but I have been developing a new
version of todo-mode.el for a very long time (which I plan to submit for
possible inclusion in Emacs, hopefully before the next pretest begins)
and it uses before-string overlays, on the order of hundreds per buffer
(though most are not in the visible window at any time), as well as
word-wrap and wrap-prefix.

> If not, then I'm not prepared to believe
> that the above is the only problem with this change. I'd like to see
> much more reports from users of those modes that this change doesn't
> cause any trouble, before I'd agree to installing it. Just look how
> much time it took until this problem popped up. Since I knew the only
> change was in a single macro that is used in a small number of places,
> fixing it was a 5-min job. But imagine that the same would happen 3
> years after committing this change, with gazillions of unrelated
> changes in the display code since then.

I may be misunderstanding you here, but it sounds like you think the
patch to enable overflow-newline-into-fringe in Visual Line mode is
already in the trunk; it isn't. This bug report was initiated more than
four years ago by someone (not me) who noticed the odd display of a line
whose length is window-width when Visual Line mode is enabled. Chong
Yidong pointed out that this was because fringe overflow was disabled in
Visual Line mode and he suspected "confusing results" if it were
enabled. Then this past February, almost four years later, I posted
that I had enabled it in my local branch and had not observed any
problems. I've been using it since then and only today hit the problem
that I reported and you quickly fixed. Nobody using the vanilla trunk
can have run into the problem, because fringe overflow is still disabled
in Visual Line mode there. But if it were now enabled (with my patch)
and your patch were also added (to prevent the problem I reported
today), then Org and magit users and others will be able to see if other
problems do arise. Does this make sense, or have I completely
misunderstood you?

Steve Berman

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Cc: mon...@iro.umontreal.ca, pe...@aparamon.msk.ru, 27...@debbugs.gnu.org

> Date: Fri, 10 May 2013 21:06:15 +0200

>
> > Do you use Org mode or any other modes (e.g., magit) that are heavy
> > users of display strings?
>
> I don't use either of those modes, but I have been developing a new
> version of todo-mode.el for a very long time (which I plan to submit for
> possible inclusion in Emacs, hopefully before the next pretest begins)
> and it uses before-string overlays, on the order of hundreds per buffer
> (though most are not in the visible window at any time), as well as
> word-wrap and wrap-prefix.

Before- and after-strings are much easier on the display engine than
'display' text properties and overlays with 'display' properties.

> I may be misunderstanding you here, but it sounds like you think the
> patch to enable overflow-newline-into-fringe in Visual Line mode is
> already in the trunk; it isn't.

I know. I said "imagine" because I understand this change is not in
the repository.

> But if it were now enabled (with my patch) and your patch were also
> added (to prevent the problem I reported today), then Org and magit
> users and others will be able to see if other problems do arise.

I suspect subtle issues will be triggered by this change in modes that
make heavy use of display properties. But if Stefan is willing to
take that risk, let's install this and see what breaks.

[Stephen Berman]

On Fri, 10 May 2013 22:31:53 +0300 Eli Zaretskii <el...@gnu.org> wrote:

>> From: Stephen Berman <stephen...@gmx.net>
[...]

>> I may be misunderstanding you here, but it sounds like you think the
>> patch to enable overflow-newline-into-fringe in Visual Line mode is
>> already in the trunk; it isn't.
>
> I know. I said "imagine" because I understand this change is not in
> the repository.
>
>> But if it were now enabled (with my patch) and your patch were also
>> added (to prevent the problem I reported today), then Org and magit
>> users and others will be able to see if other problems do arise.
>
> I suspect subtle issues will be triggered by this change in modes that
> make heavy use of display properties. But if Stefan is willing to
> take that risk, let's install this and see what breaks.

I hope Stefan's silence till now just means he hasn't yet had time to
give this issue due consideration....

In the mean time, I've encountered another problem, which has nothing to
do with display properties or overlays:

-1. Apply both my patch and yours (Eli's).
0. emacs -Q
1. Type `a RET C-80 x RET b' to insert three line of text, of which the
second runs the width of the window, up to the right fringe.
2. M-x visual-line-mode
3. With point on `a', type `C-n': now point is on the first `x' of the
second inserted line.
Here's the first instance of the problem:
4. Type `C-n' again: now point is in the fringe at the end of the line
of x's.
Here's the next instance of the problem:
5. Type `C-p': now point is back on the first `x' of the second inserted
line.

(If you type `C-n' again after step 4, so point is on `b' in the third
inserted line, and then type `C-p', now point is back in the fringe at
the end of the line of x's. I assume this is not an instance of the
problem, but point moving correctly back to the goal column.)

As you've no doubt guessed by now, the problem occurs in
vertical-motion, and can be reproduced by replacing `C-n' and `C-p' in
the recipe by `M-: (vertical-motion 1)' and `M-: (vertical-motion -1)',
respectively. I tried to debug it but my GDB skills are unfortunately
too limited; if you feel like advising me, I'm all ears. Otherwise, it
would be great if you could fix this as quickly as you fixed the last
problem I reported!

Steve Berman

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Cc: mon...@iro.umontreal.ca, 27...@debbugs.gnu.org
> Date: Sat, 18 May 2013 22:30:00 +0200

>
> I hope Stefan's silence till now just means he hasn't yet had time to
> give this issue due consideration....
>
> In the mean time, I've encountered another problem, which has nothing to
> do with display properties or overlays:

So let me see if I understand how this works: you discover one by one
the problems about this change, those same problems I was afraid of,
and I get to debug them, is that right? ;-)

Is there any point in this game where we say "enough", as too many
problems were discovered for too small a gain? Or does this go on
forever?

> -1. Apply both my patch and yours (Eli's).

If you don't apply mine, does this problem still happen?

[Stephen Berman]

On Sun, 19 May 2013 18:29:26 +0300 Eli Zaretskii <el...@gnu.org> wrote:

>> From: Stephen Berman <stephen...@gmx.net>
>> Cc: mon...@iro.umontreal.ca, 27...@debbugs.gnu.org
>> Date: Sat, 18 May 2013 22:30:00 +0200
>>
>> I hope Stefan's silence till now just means he hasn't yet had time to
>> give this issue due consideration....
>>
>> In the mean time, I've encountered another problem, which has nothing to
>> do with display properties or overlays:
>
> So let me see if I understand how this works: you discover one by one
> the problems about this change, those same problems I was afraid of,
> and I get to debug them, is that right? ;-)

Is this new problem one you anticipated? I thought you were worried
about problems arising from heavy use of display properties, but this
doesn't involve any. Anyway, I really do wish I knew how to debug this
myself. I tried stepping though Fvertical_motion but that has many
calls to other parts of the code and I couldn't follow it well -- didn't
know what could be skipped over, or what values to test, etc. It looked
like point moved into the fringe after a call to, I think, read_char but
I couldn't tell if that was really the trigger (doesn't seem likely).
Of course, I would be grateful if you'd give me any help or advice about
how to debug it, but I suspect that wouldn't be less burdensome to you
than debugging it yourself ;-)

> Is there any point in this game where we say "enough", as too many
> problems were discovered for too small a gain? Or does this go on
> forever?

Well, I hope you agree what started this is a real bug. If you, Stefan
or other Emacs maintainers tell me it's not worth fixing, I can live
with that. But as long as long as it's not fixed, other people may
encounter it and report it again....

>> -1. Apply both my patch and yours (Eli's).
>
> If you don't apply mine, does this problem still happen?

No, with my patch and without yours, this problem goes away. So then
we're back to the previous problem.... ;-)

Steve Berman

[Eli Zaretskii]

> From: Stephen Berman <stephen...@gmx.net>
> Cc: mon...@iro.umontreal.ca, 27...@debbugs.gnu.org

> Date: Sun, 19 May 2013 18:28:59 +0200

>
> On Sun, 19 May 2013 18:29:26 +0300 Eli Zaretskii <el...@gnu.org> wrote:
>
> >> From: Stephen Berman <stephen...@gmx.net>
> >> Cc: mon...@iro.umontreal.ca, 27...@debbugs.gnu.org
> >> Date: Sat, 18 May 2013 22:30:00 +0200
> >>
> >> I hope Stefan's silence till now just means he hasn't yet had time to
> >> give this issue due consideration....
> >>
> >> In the mean time, I've encountered another problem, which has nothing to
> >> do with display properties or overlays:
> >
> > So let me see if I understand how this works: you discover one by one
> > the problems about this change, those same problems I was afraid of,
> > and I get to debug them, is that right? ;-)
>
> Is this new problem one you anticipated? I thought you were worried
> about problems arising from heavy use of display properties, but this
> doesn't involve any.

Changes such as the one you suggested are bound to break any number of
places that are all related to functions that simulate display.
vertical-motion is one of them, but in no way the only one. Display
properties and overlays tend to reveal such problems sooner, because
they already strain the relevant code, and require all kinds of
ad-hoc'ery that is easy to break. But they are not the only ones.

> Of course, I would be grateful if you'd give me any help or advice about
> how to debug it, but I suspect that wouldn't be less burdensome to you
> than debugging it yourself ;-)
>
> > Is there any point in this game where we say "enough", as too many
> > problems were discovered for too small a gain? Or does this go on
> > forever?
>
> Well, I hope you agree what started this is a real bug. If you, Stefan
> or other Emacs maintainers tell me it's not worth fixing, I can live
> with that. But as long as long as it's not fixed, other people may
> encounter it and report it again....

I don't mind trying a bit longer, I just want to know what kind of
process are we involved in here. If there were a decision (by Stefan)
to introduce this feature no matter what, then I'd understand that any
fallout needs to be fixed. But this not being the case, I wonder what
are we trying to accomplish here.

I'll take a look when I have time.

[Stefan Monnier]

> I hope Stefan's silence till now just means he hasn't yet had time to
> give this issue due consideration....

No, the thread was simply mis-filed. I'm a user of word-wrap and I like
overflow-newline-into-fringe, so I'm in favor of this patch.
That's assuming any serious fall-out can get fixed, obviously.


Stefan

[Eli Zaretskii]

> From: Stefan Monnier <mon...@iro.umontreal.ca>
> Date: Tue, 28 May 2013 18:26:57 -0400
> Cc: Eli Zaretskii <el...@gnu.org>, 27...@debbugs.gnu.org

I fixed the two known problems with the original proposal, and
committed everything to the trunk as revision 113259.

This bug is now officially closed. Any fallout should be reported as
separate bugs.

[Stefan Monnier]

>> No, the thread was simply mis-filed. I'm a user of word-wrap and I like
>> overflow-newline-into-fringe, so I'm in favor of this patch.

> I fixed the two known problems with the original proposal, and
> committed everything to the trunk as revision 113259.

Cool, thanks,


Stefan

[Stephen Berman]

On Tue, 02 Jul 2013 18:54:39 +0300 Eli Zaretskii <el...@gnu.org> wrote:

>> From: Stefan Monnier <mon...@iro.umontreal.ca>
>> Date: Tue, 28 May 2013 18:26:57 -0400
>> Cc: Eli Zaretskii <el...@gnu.org>, 27...@debbugs.gnu.org
>>
>> > I hope Stefan's silence till now just means he hasn't yet had time to
>> > give this issue due consideration....
>>

>> No, the thread was simply mis-filed. I'm a user of word-wrap and I like
>> overflow-newline-into-fringe, so I'm in favor of this patch.

>> That's assuming any serious fall-out can get fixed, obviously.
>

> I fixed the two known problems with the original proposal

Confirmed, and many thanks!

Steve Berman