unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
@ 2009-10-12 20:49 Lennart Borgman
  2011-09-18  8:53 ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 22+ messages in thread
From: Lennart Borgman @ 2009-10-12 20:49 UTC (permalink / raw)
  To: emacs-pretest-bug

If you have an underline text property that crosses a line boundary it
will be displayed in a rather disturbingly way. The whole indentation on
the next line will be underlined.

For an example see https://bugs.launchpad.net/nxhtml/+bug/449837 where
there are some images.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/emacs/u/090928/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
 of 2009-09-28
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2009-10-12 20:49 bug#4710: 23.1.50; Bad display of underlines crossing line boundaries Lennart Borgman
@ 2011-09-18  8:53 ` Lars Magne Ingebrigtsen
  2011-09-18  9:12   ` Deniz Dogan
  0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18  8:53 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 4710

Lennart Borgman <lennart.borgman@gmail.com> writes:

> If you have an underline text property that crosses a line boundary it
> will be displayed in a rather disturbingly way. The whole indentation on
> the next line will be underlined.
>
> For an example see https://bugs.launchpad.net/nxhtml/+bug/449837 where
> there are some images.

The images seem to have disappeared from that page.

Anyway, do you still see this bug in Emacs 24?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-18  8:53 ` Lars Magne Ingebrigtsen
@ 2011-09-18  9:12   ` Deniz Dogan
  2011-09-18  9:20     ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 22+ messages in thread
From: Deniz Dogan @ 2011-09-18  9:12 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: 4710

On 2011-09-18 10:53, Lars Magne Ingebrigtsen wrote:
> Lennart Borgman<lennart.borgman@gmail.com>  writes:
>
>> If you have an underline text property that crosses a line boundary it
>> will be displayed in a rather disturbingly way. The whole indentation on
>> the next line will be underlined.
>>
>> For an example see https://bugs.launchpad.net/nxhtml/+bug/449837 where
>> there are some images.
>
> The images seem to have disappeared from that page.
>
> Anyway, do you still see this bug in Emacs 24?
>

I still see it: http://i.imgur.com/abMZu.png

(This is with the wrap-prefix text property.)





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-18  9:12   ` Deniz Dogan
@ 2011-09-18  9:20     ` Lars Magne Ingebrigtsen
  2011-09-18  9:42       ` Eli Zaretskii
  0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18  9:20 UTC (permalink / raw)
  To: Deniz Dogan; +Cc: 4710

Deniz Dogan <deniz@dogan.se> writes:

> I still see it: http://i.imgur.com/abMZu.png

Oh, that problem.  Yes, when folding text that contains text properties,
the spaces at the beginning of the next line will also contain those
text properties.

This is usually what we want -- if, for instance, the text is a button,
you don't want the text to suddenly become two buttons just because it's
been folded.

But visually with underlines, it looks quite unfortunate.

Special-casing for `underline' (or any face properties that happen to
have `underline' set) sounds quite awkward, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-18  9:20     ` Lars Magne Ingebrigtsen
@ 2011-09-18  9:42       ` Eli Zaretskii
  2011-09-18  9:43         ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-18  9:42 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: 4710

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 18 Sep 2011 11:20:51 +0200
> Cc: 4710@debbugs.gnu.org
> 
> Deniz Dogan <deniz@dogan.se> writes:
> 
> > I still see it: http://i.imgur.com/abMZu.png
> 
> Oh, that problem.  Yes, when folding text that contains text properties,
> the spaces at the beginning of the next line will also contain those
> text properties.
> 
> This is usually what we want -- if, for instance, the text is a button,
> you don't want the text to suddenly become two buttons just because it's
> been folded.
> 
> But visually with underlines, it looks quite unfortunate.

"If it hurts, don't do that" comes to mind.

My vote is "won't fix".





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-18  9:42       ` Eli Zaretskii
@ 2011-09-18  9:43         ` Lars Magne Ingebrigtsen
  2011-09-19 20:03           ` Stefan Monnier
  0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18  9:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 4710

Eli Zaretskii <eliz@gnu.org> writes:

> "If it hurts, don't do that" comes to mind.

But it does look really ugly.  :-)  This single behavioural tic is what
makes underlines undesirable.  If somebody had a good idea how to fix
this in general, that would be a win.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-18  9:43         ` Lars Magne Ingebrigtsen
@ 2011-09-19 20:03           ` Stefan Monnier
  2011-09-19 21:20             ` Drew Adams
  0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2011-09-19 20:03 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: 4710

>> "If it hurts, don't do that" comes to mind.
> But it does look really ugly.  :-)  This single behavioural tic is what
> makes underlines undesirable.  If somebody had a good idea how to fix
> this in general, that would be a win.

Maybe someone could come up with a neater way to display "face
continuations" (face that applies to the text where a line is
wrapped).  For underline, we could put a short bit of dotted underline
as in:
              foo bar baz
                  ——————-⋯
              toto titi turlu
             ⋯————


        Stefan





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-19 20:03           ` Stefan Monnier
@ 2011-09-19 21:20             ` Drew Adams
  2011-09-20  1:38               ` Stefan Monnier
  0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2011-09-19 21:20 UTC (permalink / raw)
  To: 'Stefan Monnier', 'Lars Magne Ingebrigtsen'; +Cc: 4710

> >> "If it hurts, don't do that" comes to mind.

To my mind also, FWIW.

> > But it does look really ugly.  :-)  This single behavioural 
> > tic is what makes underlines undesirable.  If somebody had
> > a good idea how to fix this in general, that would be a win.
> 
> Maybe someone could come up with a neater way to display "face
> continuations" (face that applies to the text where a line is
> wrapped).  For underline, we could put a short bit of dotted underline
> as in:
>               foo bar baz
>                   -------?
>               toto titi turlu
>              ?----

Why assume that underlined whitespace should not show an underline?
Likewise for other face attributes.

Down that path lies dwimmadness.

At the very least, any such fiddling should be done only for indentation (i.e.,
in the code that indents text).  And it certainly should be under user control
(e.g., optional).






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-19 21:20             ` Drew Adams
@ 2011-09-20  1:38               ` Stefan Monnier
  2011-09-20  2:21                 ` Drew Adams
  2011-09-20  9:41                 ` Lars Magne Ingebrigtsen
  0 siblings, 2 replies; 22+ messages in thread
From: Stefan Monnier @ 2011-09-20  1:38 UTC (permalink / raw)
  To: Drew Adams; +Cc: 'Lars Magne Ingebrigtsen', 4710

>> > But it does look really ugly.  :-)  This single behavioural 
>> > tic is what makes underlines undesirable.  If somebody had
>> > a good idea how to fix this in general, that would be a win.
>> Maybe someone could come up with a neater way to display "face
>> continuations" (face that applies to the text where a line is
>> wrapped).  For underline, we could put a short bit of dotted underline
>> as in:
>>     foo bar baz
>>         -------⋯
>>     toto titi tur
>>    ⋯----
> Why assume that underlined whitespace should not show an underline?
> Likewise for other face attributes.

I believe you're confused: I'm talking about line-wrapping done by the
redisplay engine.  I.e. there's no newline in the above example (but
there are curly arrows in the fringe instead).


        Stefan





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20  1:38               ` Stefan Monnier
@ 2011-09-20  2:21                 ` Drew Adams
  2011-09-20  2:29                   ` Stefan Monnier
  2011-09-20  9:41                 ` Lars Magne Ingebrigtsen
  1 sibling, 1 reply; 22+ messages in thread
From: Drew Adams @ 2011-09-20  2:21 UTC (permalink / raw)
  To: 'Stefan Monnier'; +Cc: 'Lars Magne Ingebrigtsen', 4710

> > Why assume that underlined whitespace should not show an underline?
> > Likewise for other face attributes.
> 
> I believe you're confused: I'm talking about line-wrapping done by the
> redisplay engine.  I.e. there's no newline in the above example (but
> there are curly arrows in the fringe instead).

Fair enough; I didn't understand the context.

But even in that case, there could be an argument for showing the same face
attributes across the "split" (whatever you want to call it).  Not doing so
could give the impression that there is actually a break (change) in the face
attributes when there is not.  If you do that, then perhaps some additional
display artifact should convey that - e.g., perhaps a different fringe marker.

This sounds like something that users might want to be able to control (e.g.
optional).  Dunno (I don't use such line wrapping/soft returns, myself).






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20  2:21                 ` Drew Adams
@ 2011-09-20  2:29                   ` Stefan Monnier
  2011-09-20 14:05                     ` Drew Adams
  0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2011-09-20  2:29 UTC (permalink / raw)
  To: Drew Adams; +Cc: 'Lars Magne Ingebrigtsen', 4710

> Not doing so could give the impression that there is actually a break
> (change) in the face attributes when there is not.  If you do that,
> then perhaps some additional display artifact should convey that -
> e.g., perhaps a different fringe marker.

Again, you seem to be confused: I'm specifically talking about "face
continuations", i.e. ways to express the fact that the face continues
rather than being broken.  That's the whole point of the two ⋯ in
my example.
Please make sure there's an actual disagreement before jumping on your
keyboard ;-)


        Stefan





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20  1:38               ` Stefan Monnier
  2011-09-20  2:21                 ` Drew Adams
@ 2011-09-20  9:41                 ` Lars Magne Ingebrigtsen
  2011-09-20 14:04                   ` Drew Adams
  1 sibling, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-20  9:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 4710

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Maybe someone could come up with a neater way to display "face
>>> continuations" (face that applies to the text where a line is
>>> wrapped).  For underline, we could put a short bit of dotted underline
>>> as in:
>>>     foo bar baz
>>>         -------⋯
>>>     toto titi tur
>>>    ⋯----
>> Why assume that underlined whitespace should not show an underline?
>> Likewise for other face attributes.
>
> I believe you're confused: I'm talking about line-wrapping done by the
> redisplay engine.  I.e. there's no newline in the above example (but
> there are curly arrows in the fringe instead).

I was talking about things that do have newlines in them.  :-)

If you have the following text, where some of it underscores.  Like
this:

      This is a text with words This is a text with words This is a text with words 
                                                    -------------------------

Then you fill it with `M-q':

      This is a text with words This is a text with words This is a text
                                                    --------------------
      with words
----------


and then you get this ugly-looking result.

I have no idea how to fix this in an except in an extremely hacky way,
though.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20  9:41                 ` Lars Magne Ingebrigtsen
@ 2011-09-20 14:04                   ` Drew Adams
  2011-09-20 21:46                     ` Stefan Monnier
  0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2011-09-20 14:04 UTC (permalink / raw)
  To: 'Lars Magne Ingebrigtsen', 'Stefan Monnier'; +Cc: 4710

> >> Why assume that underlined whitespace should not show an underline?
> >> Likewise for other face attributes.
> >
> > I believe you're confused: I'm talking about line-wrapping 
> > done by the redisplay engine.  I.e. there's no newline in
> > the above example (but there are curly arrows in the fringe
> > instead).
> 
> I was talking about things that do have newlines in them.  :-)
> If you have the following text, where some of it underscores.
> Like this:... and then you get this ugly-looking result.

That was what I thought the bug report and discussion were about.  Thanks for
clarifying.

And checking the original report and its linked pages (e.g.,
https://bugs.launchpad.net/nxhtml/+bug/449837), I still have that impression:

"After using tidy if an underlined html/CSS items is immediately followed by a
line break/return the underline continues across the page & goes on to the next
line to finish @ the next block of text."

"Followed by a line break/return" seems pretty clear to me.

So maybe Stefan wants to file a separate bug for the soft-return/line-wrapping
case he's really interested in. ;-)






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20  2:29                   ` Stefan Monnier
@ 2011-09-20 14:05                     ` Drew Adams
  2016-07-14  4:15                       ` Andrew Hyatt
  0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2011-09-20 14:05 UTC (permalink / raw)
  To: 'Stefan Monnier'; +Cc: 'Lars Magne Ingebrigtsen', 4710

> > Not doing so could give the impression that there is 
> > actually a break (change) in the face attributes when
> > there is not.  If you do that, then perhaps some additional
> > display artifact should convey that -
> > e.g., perhaps a different fringe marker.
> 
> Again, you seem to be confused: I'm specifically talking about "face
> continuations", i.e. ways to express the fact that the face continues
> rather than being broken.  That's the whole point of the two ? in
> my example.  Please make sure there's an actual disagreement before
> jumping on your keyboard ;-)

Great, so you jumped on your keyboard to express your violent agreement. ;-)

At any rate, it looks like your and my proposals for such a
line-wrapping-without-breaking case, while perhaps interesting, do not
correspond to the bug reported.

It appears that the OP was indeed about face extension across (hard) line breaks
into indented text on the next line.

That was what my original response was to: If it hurts, don't do it; and let's
not assume that whitespace should not show the face attributes of the adjacent
text just because it represents indentation.






^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20 14:04                   ` Drew Adams
@ 2011-09-20 21:46                     ` Stefan Monnier
  2011-09-21 18:36                       ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2011-09-20 21:46 UTC (permalink / raw)
  To: Drew Adams; +Cc: 'Lars Magne Ingebrigtsen', 4710

> So maybe Stefan wants to file a separate bug for the soft-return/line-wrapping
> case he's really interested in. ;-)

FWIW, Deniz Dogan said "This is with the wrap-prefix text property",
which is why I assumed we're talking about dynamic wrapping done by the
redisplay rather than by fill-paragraph.

If there's a \n, at least Elisp code can change the property on the \n
char to influence the display.


        Stefan





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20 21:46                     ` Stefan Monnier
@ 2011-09-21 18:36                       ` Lars Magne Ingebrigtsen
  2011-09-21 20:27                         ` Lennart Borgman
  2011-09-22  1:18                         ` Stefan Monnier
  0 siblings, 2 replies; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-21 18:36 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 4710

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> If there's a \n, at least Elisp code can change the property on the \n
> char to influence the display.

Yes...  but the main question is what to do about the text property on
the next line -- if there's leading space on the next line.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-21 18:36                       ` Lars Magne Ingebrigtsen
@ 2011-09-21 20:27                         ` Lennart Borgman
  2011-09-22  1:18                         ` Stefan Monnier
  1 sibling, 0 replies; 22+ messages in thread
From: Lennart Borgman @ 2011-09-21 20:27 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: 4710

On Wed, Sep 21, 2011 at 20:36, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> If there's a \n, at least Elisp code can change the property on the \n
>> char to influence the display.
>
> Yes...  but the main question is what to do about the text property on
> the next line -- if there's leading space on the next line.

Don't underline the leading spaces.

BTW, I have sent another bug report about this (that was recently
closed I believe, I did not have time to respond).





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-21 18:36                       ` Lars Magne Ingebrigtsen
  2011-09-21 20:27                         ` Lennart Borgman
@ 2011-09-22  1:18                         ` Stefan Monnier
  1 sibling, 0 replies; 22+ messages in thread
From: Stefan Monnier @ 2011-09-22  1:18 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: 4710

>> If there's a \n, at least Elisp code can change the property on the \n
>> char to influence the display.
> Yes...  but the main question is what to do about the text property on
> the next line -- if there's leading space on the next line.

Same thing as the properties on the \n.


        Stefan





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2011-09-20 14:05                     ` Drew Adams
@ 2016-07-14  4:15                       ` Andrew Hyatt
  2016-07-14 11:45                         ` Noam Postavsky
  2016-07-14 15:10                         ` Eli Zaretskii
  0 siblings, 2 replies; 22+ messages in thread
From: Andrew Hyatt @ 2016-07-14  4:15 UTC (permalink / raw)
  To: Drew Adams
  Cc: 'Lars Magne Ingebrigtsen', 'Stefan Monnier', 4710

"Drew Adams" <drew.adams@oracle.com> writes:

>> > Not doing so could give the impression that there is 
>> > actually a break (change) in the face attributes when
>> > there is not.  If you do that, then perhaps some additional
>> > display artifact should convey that -
>> > e.g., perhaps a different fringe marker.
>> 
>> Again, you seem to be confused: I'm specifically talking about "face
>> continuations", i.e. ways to express the fact that the face continues
>> rather than being broken.  That's the whole point of the two ? in
>> my example.  Please make sure there's an actual disagreement before
>> jumping on your keyboard ;-)
>
> Great, so you jumped on your keyboard to express your violent agreement. ;-)
>
> At any rate, it looks like your and my proposals for such a
> line-wrapping-without-breaking case, while perhaps interesting, do not
> correspond to the bug reported.
>
> It appears that the OP was indeed about face extension across (hard) line breaks
> into indented text on the next line.
>
> That was what my original response was to: If it hurts, don't do it; and let's
> not assume that whitespace should not show the face attributes of the adjacent
> text just because it represents indentation.

Now we are almost 5 years into the future, and this bug hasn't been
updated.  Drew's response didn't get agreement or disagreement, so would
anyone object if we considered this not a bug, as he suggests?





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2016-07-14  4:15                       ` Andrew Hyatt
@ 2016-07-14 11:45                         ` Noam Postavsky
  2016-07-14 15:15                           ` Eli Zaretskii
  2016-07-14 15:10                         ` Eli Zaretskii
  1 sibling, 1 reply; 22+ messages in thread
From: Noam Postavsky @ 2016-07-14 11:45 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: Lars Magne Ingebrigtsen, Stefan Monnier, 4710

On Thu, Jul 14, 2016 at 12:15 AM, Andrew Hyatt <ahyatt@gmail.com> wrote:
>> It appears that the OP was indeed about face extension across (hard) line breaks
>> into indented text on the next line.
>>
>> That was what my original response was to: If it hurts, don't do it; and let's
>> not assume that whitespace should not show the face attributes of the adjacent
>> text just because it represents indentation.
>
> Now we are almost 5 years into the future, and this bug hasn't been
> updated.  Drew's response didn't get agreement or disagreement, so would
> anyone object if we considered this not a bug, as he suggests?
>
>
>

Hmm, seems somewhat related to
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23574 (that one is about
underline from the end of line to the edge of screen, this one is
about underline from beginning of next line). Perhaps the new
defcustom discussed there
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23574#67) should cover
this too?





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2016-07-14  4:15                       ` Andrew Hyatt
  2016-07-14 11:45                         ` Noam Postavsky
@ 2016-07-14 15:10                         ` Eli Zaretskii
  1 sibling, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2016-07-14 15:10 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: larsi, monnier, 4710

> From: Andrew Hyatt <ahyatt@gmail.com>
> Date: Thu, 14 Jul 2016 00:15:40 -0400
> Cc: 'Lars Magne Ingebrigtsen' <larsi@gnus.org>,
> 	'Stefan Monnier' <monnier@iro.umontreal.ca>, 4710@debbugs.gnu.org
> 
> Now we are almost 5 years into the future, and this bug hasn't been
> updated.  Drew's response didn't get agreement or disagreement, so would
> anyone object if we considered this not a bug, as he suggests?

My opinion is in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4710#17
FWIW.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* bug#4710: 23.1.50; Bad display of underlines crossing line boundaries
  2016-07-14 11:45                         ` Noam Postavsky
@ 2016-07-14 15:15                           ` Eli Zaretskii
  0 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2016-07-14 15:15 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: ahyatt, larsi, 4710, monnier

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 14 Jul 2016 07:45:32 -0400
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, 4710@debbugs.gnu.org
> 
> Hmm, seems somewhat related to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23574 (that one is about
> underline from the end of line to the edge of screen, this one is
> about underline from beginning of next line). Perhaps the new
> defcustom discussed there
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23574#67) should cover
> this too?

No, it won't.  Face extension to the end of line uses a separate
mechanism, because it determines the way we draw the part of the
screen where there's no text at all.

By contrast, the issue in this report is with drawing of characters
that are part of buffer text, or are determined by text properties or
overlays associated with buffer text.  For these, the display engine
follows a very simple strategy: it uses the same face until it gets to
a buffer position where the face changes, at which point it also finds
the next position where the face changes, and stores that position in
the iterator object used to traverse the text to be displayed.  Rinse,
repeat.  So disabling that will need a separate solution, at least
implementation-wise.





^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2016-07-14 15:15 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-12 20:49 bug#4710: 23.1.50; Bad display of underlines crossing line boundaries Lennart Borgman
2011-09-18  8:53 ` Lars Magne Ingebrigtsen
2011-09-18  9:12   ` Deniz Dogan
2011-09-18  9:20     ` Lars Magne Ingebrigtsen
2011-09-18  9:42       ` Eli Zaretskii
2011-09-18  9:43         ` Lars Magne Ingebrigtsen
2011-09-19 20:03           ` Stefan Monnier
2011-09-19 21:20             ` Drew Adams
2011-09-20  1:38               ` Stefan Monnier
2011-09-20  2:21                 ` Drew Adams
2011-09-20  2:29                   ` Stefan Monnier
2011-09-20 14:05                     ` Drew Adams
2016-07-14  4:15                       ` Andrew Hyatt
2016-07-14 11:45                         ` Noam Postavsky
2016-07-14 15:15                           ` Eli Zaretskii
2016-07-14 15:10                         ` Eli Zaretskii
2011-09-20  9:41                 ` Lars Magne Ingebrigtsen
2011-09-20 14:04                   ` Drew Adams
2011-09-20 21:46                     ` Stefan Monnier
2011-09-21 18:36                       ` Lars Magne Ingebrigtsen
2011-09-21 20:27                         ` Lennart Borgman
2011-09-22  1:18                         ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).