bug#36858: 27.0.50; display bugs with display-fill-column-indicator-mode

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 5 Aug 2019 17:27:47 +0200
> From: Ergus <spacibba@aol.com>
> Cc: 36858@debbugs.gnu.org, Davor Rotim <rotim.davor@gmail.com>
> 
> 1) The condition ends_at_zv_p didn't work as expected, I don't know If
> this is an issue somewhere else, but at least in my tests, the condition
> was always false. (for all the lines implied before and after ZV, where
> there was company window or not)
> 
> So the filter condition I am using now is:
> 
> IT_CHARPOS (*it) < ZV
> 
> which seems to work fine.
> 
> 2) There is a corner case because the indicator is never generated for
> the latest line in the buffer. So a \n is required always at the end of
> the buffer if there is text, which for me is fine (unix format), but I
> don't know if I should correct that, should I?

Unix format has nothing to do with this, as in a buffer we always have
only \n characters at end of line.  But notr having the indicator show
in the last line of a buffer that doesn't end in a newline is
unfortunate.  Which is why I suggested to test the ends_at_zv_p flag.
What exactly didn't work with it?  Can you show me a test case where
the glyph rows past ZV don't have this flag set?  Maybe you should
test the enabled_p flag as well?

> In terminal emacs, in the original emacs-26 code, in the function:
> extend_face_to_end_of_line the code was:
> 
> ```
>  face = FACE_FROM_ID (f, (it->face_before_selective_p
> 			   ? it->saved_face_id
> 			   : it->face_id));
>  (...)
> 
>  if (it->glyph_row->ends_at_zv_p)
>      it->face_id = default_face->id;
>  else
>      it->face_id = face->id;
>  PRODUCE_GLYPHS (it);
> 
>  while (it->current_x <= it->last_visible_x)
>      PRODUCE_GLYPHS (it);
> ```
> 
> So the rest of the line was filled with the last face, (so this issue was
> already there since then, because the rest of the line is filled with an
> underlined face)
> 
> I can change the code to fill the rest of the line with a new merged
> face (as I do for graphical emacs), but I think that this fix is
> unrelated with dfci, so maybe someone else must give a look before to
> prevent me breaking anything.

This is a more general issue, and I will respond to your question on
emacs-devel.

Thanks.