Eli Zaretskii <eliz@gnu.org> writes:

— a/src/xdisp.c
+ b/src/xdisp.c
@@ -8430,6 8430,34 @@ get_{nextdisplayelement} (struct it *it)
int lface_id = 0;
int escape_glyph;

+ if (c = '\f' && it->current_x = it->first_visiblex)

IMO, this condition is incorrect. You should test for the previous
character being a newline. The it->first_visiblex condition will be
wrong in a continuation line, when the window is hscrolled, and when
display-line-numbers-mode is turned on, as well as in some other
situations (line/wrap-prefix etc.).

+ {
+ const int save_faceid = it->face_id;
+ const int save_char = it->char_todisplay;
+ const int save_currentx = it->current_x;
+ const int save_ascent = it->ascent;
+ const int save_descent = it->descent;
+
+ face_id =
+ merge_faces (it->w, Qtrailing_whitespace, 0, it->face_id);
+ XSETINT (it->ctl_chars[0], 0);
+ ctl_len = 0;
+
+ it->char_todisplay = '-';
+ it->face_id = face_id;
+ for ( ; it->current_x - it->end_charpos <= it->last_visiblex; it->current_x+)

This condition is also incorrect, IMO: it->current_x is the pixel
coordinate, whereas it->end_charpos is a character position in the
buffer, so you cannot meaningfully subtract them. Also, I think this
will be incorrect when the window has display margins.

The right way to figure out the usable width is to call the function
window_boxwidth or window_{boxrightoffset}.

These wrong conditions are probably the reasons for at least part of
the problems you see with this patch.

I'll take it into account. Thanks.

+ {
+ PRODUCE_GLYPHS (it);
+ }

I think it's not a good idea to call PRODUCE_GLYPHS inside
get_{nextdisplayelement}.

I originally wanted to put this in display_line, however,
get_{nextdisplayelement} was overriding the character face so i thought
that adding it to get_{nextdisplayelement} (where ^L is displayed)
would be a better solution.

Alternatively, we could implement this entirely in the
terminal-specific back-end of the display engine (xterm.c, w32term.c,
etc.), where we could detect the "^L" glyph sequence and replace it
with a horizontal line of a suitable width and thickness. That would
allow us to produce a separator that is much better-looking than just
showing a long line of dashes.

The dashes are temporal, I'm planning to add a variable that store
the character to display (like display-fill-column-indicator-character).

I don't think it would be better display a line instead a character, in
that case, I would have preferred to use a face with a strike-through.

This should work for both Terminal and GUI frames.

In any case, this must be an optional feature, so we will need a user
option to control it, by default off.

Yeah, this will be buffer-local and have an user option (not minor mode)
for enable/disable it (disabled by default), i didn't added the options
yet because first i was testing if this works well, the same for the
face used.