GNU bug report logs - #77544
(WIP) [PATCH] Prettify page separators.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77544 in the body.
You can then email your comments to 77544 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: (WIP) [PATCH] Prettify page separators.
Date: Fri, 04 Apr 2025 23:01:02 -0600

[Message part 1 (text/plain, inline)]

Tags: patch


This feature prettify the page separator character (^L) with
a horizontal line (to end of buffer) only if the character
is at beginning of line.

Unlike popular packages like page-break-lines and form-feed(-st), this
one is written in C and does not present performance problems (I hope).

This package tries to be close to page-break-lines and be an alternative
to make-separator-line.

This partially works, however there are a few bugs that I can't find a
solution for:

- It won't display the characters inserted in front.
  I want to make it similar to display-fill-column, that only
  insert the horizontal line character if the row is empty.
- For some reason it inserts newlines after inserting the character.
- The highlighting stops when inserting or deleting newlines from
  previous or next line.

I would like to hear your suggestions.

Thanks.

[0001-Prettify-page-separators.-bug.patch (text/patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #8 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 05 Apr 2025 10:40:25 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Date: Fri, 04 Apr 2025 23:01:02 -0600
> 
> This feature prettify the page separator character (^L) with
> a horizontal line (to end of buffer) only if the character
> is at beginning of line.
> 
> Unlike popular packages like page-break-lines and form-feed(-st), this
> one is written in C and does not present performance problems (I hope).
> 
> This package tries to be close to page-break-lines and be an alternative
> to make-separator-line.
> 
> This partially works, however there are a few bugs that I can't find a
> solution for:
> 
> - It won't display the characters inserted in front.
>   I want to make it similar to display-fill-column, that only
>   insert the horizontal line character if the row is empty.
> - For some reason it inserts newlines after inserting the character.
> - The highlighting stops when inserting or deleting newlines from
>   previous or next line.
> 
> I would like to hear your suggestions.

Thanks, please see a fewe comments below.

> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -8430,6 +8430,34 @@ get_next_display_element (struct it *it)
>  	      int lface_id = 0;
>  	      int escape_glyph;
>  
> +	      if (c == '\f' && it->current_x == it->first_visible_x)

IMO, this condition is incorrect.  You should test for the previous
character being a newline.  The it->first_visible_x 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_face_id = it->face_id;
> +		  const int save_char = it->char_to_display;
> +		  const int save_current_x = 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_to_display = '-';
> +		  it->face_id = face_id;
> +		  for ( ; it->current_x - it->end_charpos <= it->last_visible_x; 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_box_width or window_box_right_offset.

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

> +		    {
> +		      PRODUCE_GLYPHS (it);
> +		    }

I think it's not a good idea to call PRODUCE_GLYPHS inside
get_next_display_element.  And in any case, this implementation is
unnecessarily complicated, because we should probably use the display
vector instead.  The only complication here is that the number of
glyphs in the display vector cannot be the one you need, since we need
to produce the number of glyphs according to the window width.  So we
will need some special flag in the iterator object to keep producing
glyphs from the display vector until we hit the right edge of the
window's text area.

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.

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

Adding Gerd in case he has ideas, suggestions, or further comments.

Thanks for working on this.

Message #11 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 05 Apr 2025 10:53:06 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Adding Gerd in case he has ideas, suggestions, or further comments.

Nothing to add to your comments ATM, but maybe an alternative idea: how
about solving this with a new type of display property for drawing a
horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
something to draw a line to the end of the display area? That would have
the advantage that it would be a relatively locally confined change and
would have no impact when not used, and hopefully little potential to
break unrelated things when not used.

One would have to have some Lisp though that puts the display property
on form-feeds.

Message #14 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: eg642616 <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 05 Apr 2025 13:33:31 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
>   77544 <at> debbugs.gnu.org
> Date: Sat, 05 Apr 2025 10:53:06 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Adding Gerd in case he has ideas, suggestions, or further comments.
> 
> Nothing to add to your comments ATM, but maybe an alternative idea: how
> about solving this with a new type of display property for drawing a
> horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
> something to draw a line to the end of the display area? That would have
> the advantage that it would be a relatively locally confined change and
> would have no impact when not used, and hopefully little potential to
> break unrelated things when not used.

Thanks, sounds like a good idea.

> One would have to have some Lisp though that puts the display property
> on form-feeds.

Right.  Maybe a minor mode?  Or an optional feature of whitespace-mode?

Message #17 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 05 Apr 2025 11:57:42 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> --- a/src/xdisp.c
>> +++ b/src/xdisp.c
>> @@ -8430,6 +8430,34 @@ get_next_display_element (struct it *it)
>>  	      int lface_id = 0;
>>  	      int escape_glyph;
>>  
>> +	      if (c == '\f' && it->current_x == it->first_visible_x)
>
> IMO, this condition is incorrect.  You should test for the previous
> character being a newline.  The it->first_visible_x 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_face_id = it->face_id;
>> +		  const int save_char = it->char_to_display;
>> +		  const int save_current_x = 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_to_display = '-';
>> +		  it->face_id = face_id;
>> +		  for ( ; it->current_x - it->end_charpos <= it->last_visible_x; 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_box_width or window_box_right_offset.
>
> 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_next_display_element.

I originally wanted to put this in display_line, however,
get_next_display_element was overriding the character face so i thought
that adding it to get_next_display_element (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.

[Message part 2 (text/html, inline)]

[Message part 3 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #20 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 05 Apr 2025 12:08:02 -0600

[Message part 1 (text/plain, inline)]

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Nothing to add to your comments ATM, but maybe an alternative idea: how
> about solving this with a new type of display property for drawing a
> horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
> something to draw a line to the end of the display area? That would have
> the advantage that it would be a relatively locally confined change and
> would have no impact when not used, and hopefully little potential to
> break unrelated things when not used.

I like this idea.

> One would have to have some Lisp though that puts the display property
> on form-feeds.

In this case I would move this code to Lisp instead of C.

[Message part 2 (text/html, inline)]

[Message part 3 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #23 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 05 Apr 2025 12:13:26 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> One would have to have some Lisp though that puts the display property
>> on form-feeds.
>
> Right.  Maybe a minor mode?

I think a minor mode would be better.

> Or an optional feature of whitespace-mode?

I don't think whitespace-mode is related to this.

[Message part 2 (text/html, inline)]

[Message part 3 (text/plain, inline)]

-- 
                                          - E.G via GNU Emacs and Org.

Message #26 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 08:06:27 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  77544 <at> debbugs.gnu.org
> Date: Sat, 05 Apr 2025 12:08:02 -0600
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
>  Nothing to add to your comments ATM, but maybe an alternative idea: how
>  about solving this with a new type of display property for drawing a
>  horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
>  something to draw a line to the end of the display area? That would have
>  the advantage that it would be a relatively locally confined change and
>  would have no impact when not used, and hopefully little potential to
>  break unrelated things when not used.
> 
> I like this idea.
> 
>  One would have to have some Lisp though that puts the display property
>  on form-feeds.
> 
> In this case I would move this code to Lisp instead of C.

A new kind of display property must be implemented in C.  The rest of
the code can be in Lisp.

Message #29 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 08:07:09 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>   77544 <at> debbugs.gnu.org
> Date: Sat, 05 Apr 2025 12:13:26 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>  One would have to have some Lisp though that puts the display property
>  on form-feeds.
> 
>  Right. Maybe a minor mode?
> 
> I think a minor mode would be better.
> 
>  Or an optional feature of whitespace-mode?
> 
> I don't think whitespace-mode is related to this.

The form-feed ^L character is one of whitespace characters.

Message #32 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 5 Apr 2025 23:24:54 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,  77544 <at> debbugs.gnu.org
> > Date: Sat, 05 Apr 2025 12:08:02 -0600
> >
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >  Nothing to add to your comments ATM, but maybe an alternative idea: how
> >  about solving this with a new type of display property for drawing a
> >  horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
> >  something to draw a line to the end of the display area? That would have
> >  the advantage that it would be a relatively locally confined change and
> >  would have no impact when not used, and hopefully little potential to
> >  break unrelated things when not used.
> >
> > I like this idea.
> >
> >  One would have to have some Lisp though that puts the display property
> >  on form-feeds.
> >
> > In this case I would move this code to Lisp instead of C.
>
> A new kind of display property must be implemented in C.  The rest of
> the code can be in Lisp.
>

I meant to make that form feed characters use the new display property.

>

[Message part 2 (text/html, inline)]

Message #35 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 07:39:27 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>>   77544 <at> debbugs.gnu.org
>> Date: Sat, 05 Apr 2025 12:13:26 -0600
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>>  One would have to have some Lisp though that puts the display property
>>  on form-feeds.
>> 
>>  Right. Maybe a minor mode?
>> 
>> I think a minor mode would be better.
>> 
>>  Or an optional feature of whitespace-mode?
>> 
>> I don't think whitespace-mode is related to this.
>
> The form-feed ^L character is one of whitespace characters.

And white-space-mode already displays spaces, tabs, and newlines
differently, AFAIR. Looks like a good fit.

Message #38 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 09:53:08 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Date: Sat, 5 Apr 2025 23:33:04 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>  > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>  > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>  >   77544 <at> debbugs.gnu.org
>  > Date: Sat, 05 Apr 2025 12:13:26 -0600
>  > 
>  >  Or an optional feature of whitespace-mode?
>  > 
>  > I don't think whitespace-mode is related to this.
> 
>  The form-feed ^L character is one of whitespace characters.
> 
> Right, but I don't think this should be whitespace-mode exclusive.  IMO this new minor mode can be used as
> alternative to make-separator-line (for example in shortdoc buffers) which looks ugly in both terminal and GUI
> frames.

Sure, but why is it a problem to make this part of whitespace-mode?
It already has a number of optional features, each one of which can
be turned on and off separately.

The advantage is that we don't need to have yet another minor mode,
yet another mode-line lighter, etc.  Also, some people already turn on
whitespace-mode in text modes.

So I think this is something to be considered seriously.

But we can delay this discussion until you have the feature
implemented.

Message #41 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 12:27:39 +0530

[சனி ஏப்ரல் 05, 2025] Elijah Gabe Pérez wrote:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Nothing to add to your comments ATM, but maybe an alternative idea: how
>> about solving this with a new type of display property for drawing a
>> horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
>> something to draw a line to the end of the display area? That would have
>> the advantage that it would be a relatively locally confined change and
>> would have no impact when not used, and hopefully little potential to
>> break unrelated things when not used.
>
> I like this idea.

Do we need a new display property when we have the :strike-through face
attribute?  The following achieves the same effect, albeit the newline
is required for the :extend attribute to work properly AFAIU:

    (font-lock-add-keywords 
     nil
     '(("\f\n" (0 (prog1 nil
                    (put-text-property (match-beginning 0) (1- (match-end 0))
                                       'display " ")
                    (put-text-property (match-beginning 0) (match-end 0)
                                       'face '(:strike-through t :extend t)))))))
    (push 'display font-lock-extra-managed-props)

Message #44 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 77544 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 09:12:55 +0200

Visuwesh <visuweshm <at> gmail.com> writes:

> [சனி ஏப்ரல் 05, 2025] Elijah Gabe Pérez wrote:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Nothing to add to your comments ATM, but maybe an alternative idea: how
>>> about solving this with a new type of display property for drawing a
>>> horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
>>> something to draw a line to the end of the display area? That would have
>>> the advantage that it would be a relatively locally confined change and
>>> would have no impact when not used, and hopefully little potential to
>>> break unrelated things when not used.
>>
>> I like this idea.
>
> Do we need a new display property when we have the :strike-through face
> attribute?  The following achieves the same effect, albeit the newline
> is required for the :extend attribute to work properly AFAIU:
>
>     (font-lock-add-keywords 
>      nil
>      '(("\f\n" (0 (prog1 nil
>                     (put-text-property (match-beginning 0) (1- (match-end 0))
>                                        'display " ")
>                     (put-text-property (match-beginning 0) (match-end 0)
>                                        'face '(:strike-through t :extend t)))))))
>     (push 'display font-lock-extra-managed-props)

Hm, that's right. And at least on my tty (iTerm2 on macOS)

  (display-supports-face-attributes-p '(:strike-through t))
   => t

and it actually works, too.

Message #47 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, eg642616 <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 10:31:13 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,  Eli
>  Zaretskii <eliz <at> gnu.org>,
>   77544 <at> debbugs.gnu.org
> Date: Sun, 06 Apr 2025 12:27:39 +0530
> 
> [சனி ஏப்ரல் 05, 2025] Elijah Gabe Pérez wrote:
> 
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >> Nothing to add to your comments ATM, but maybe an alternative idea: how
> >> about solving this with a new type of display property for drawing a
> >> horizontal line? Say `horizontal-line WIDTH' where WIDTH could be nil or
> >> something to draw a line to the end of the display area? That would have
> >> the advantage that it would be a relatively locally confined change and
> >> would have no impact when not used, and hopefully little potential to
> >> break unrelated things when not used.
> >
> > I like this idea.
> 
> Do we need a new display property when we have the :strike-through face
> attribute?  The following achieves the same effect, albeit the newline
> is required for the :extend attribute to work properly AFAIU:
> 
>     (font-lock-add-keywords 
>      nil
>      '(("\f\n" (0 (prog1 nil
>                     (put-text-property (match-beginning 0) (1- (match-end 0))
>                                        'display " ")
>                     (put-text-property (match-beginning 0) (match-end 0)
>                                        'face '(:strike-through t :extend t)))))))
>     (push 'display font-lock-extra-managed-props)

Thanks, but what does this do on TTY frames?  We'd want to show
dashes, I think.

Besides, we don't have any control on the thickness of the
strike-through line, something that would be a natural extension here.
And it sounds like a kludge to me, TBH.

Message #50 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, eg642616 <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 16:07:06 +0530

[ஞாயிறு ஏப்ரல் 06, 2025] Eli Zaretskii wrote:

>> Do we need a new display property when we have the :strike-through face
>> attribute?  The following achieves the same effect, albeit the newline
>> is required for the :extend attribute to work properly AFAIU:
>> 
>>     (font-lock-add-keywords 
>>      nil
>>      '(("\f\n" (0 (prog1 nil
>>                     (put-text-property (match-beginning 0) (1- (match-end 0))
>>                                        'display " ")
>>                     (put-text-property (match-beginning 0) (match-end 0)
>>                                        'face '(:strike-through t :extend t)))))))
>>     (push 'display font-lock-extra-managed-props)
>
> Thanks, but what does this do on TTY frames?  We'd want to show
> dashes, I think.

I see no difference from the line in show in a GUI frame, and in xterm.
However, I don't see a line at all in the Linux tty thingy.  The font
used in xterm does not seem to matter either.

> Besides, we don't have any control on the thickness of the
> strike-through line, something that would be a natural extension here.
> And it sounds like a kludge to me, TBH.

More styling for the horizontal line, similar to what have for
:underline, would be nice to have too.  And I agree, it is a bit of
hack.

Message #53 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, eg642616 <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 06 Apr 2025 13:58:50 +0300

> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: eg642616 <at> gmail.com,  gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org
> Date: Sun, 06 Apr 2025 16:07:06 +0530
> 
> [ஞாயிறு ஏப்ரல் 06, 2025] Eli Zaretskii wrote:
> 
> > Thanks, but what does this do on TTY frames?  We'd want to show
> > dashes, I think.
> 
> I see no difference from the line in show in a GUI frame, and in xterm.
> However, I don't see a line at all in the Linux tty thingy.  The font
> used in xterm does not seem to matter either.
> 
> > Besides, we don't have any control on the thickness of the
> > strike-through line, something that would be a natural extension here.
> > And it sounds like a kludge to me, TBH.
> 
> More styling for the horizontal line, similar to what have for
> :underline, would be nice to have too.  And I agree, it is a bit of
> hack.

I think a new kind of display property is a cleaner solution.  It will
also make it easier to extend the feature, e.g., if we want the visual
appearance be more like what word processors show for a "page break".

Message #56 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 6 Apr 2025 07:27:01 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > Date: Sat, 5 Apr 2025 23:33:04 -0600
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >  > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> >  > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
> >  >   77544 <at> debbugs.gnu.org
> >  > Date: Sat, 05 Apr 2025 12:13:26 -0600
> >  >
> >  >  Or an optional feature of whitespace-mode?
> >  >
> >  > I don't think whitespace-mode is related to this.
> >
> >  The form-feed ^L character is one of whitespace characters.
> >
> > Right, but I don't think this should be whitespace-mode exclusive.  IMO
> this new minor mode can be used as
> > alternative to make-separator-line (for example in shortdoc buffers)
> which looks ugly in both terminal and GUI
> > frames.
>
> Sure, but why is it a problem to make this part of whitespace-mode?
> It already has a number of optional features, each one of which can
> be turned on and off separately.
>
> The advantage is that we don't need to have yet another minor mode,
> yet another mode-line lighter, etc.  Also, some people already turn on
> whitespace-mode in text modes.
>


It makes sense, since ^L characters are often used in files.

>

[Message part 2 (text/html, inline)]

Message #59 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org,
 Visuwesh <visuweshm <at> gmail.com>
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Fri, 08 Aug 2025 23:09:03 -0600

[Message part 1 (text/plain, inline)]

Sorry for the delay, i tried to make the strike-through face property
support the same line styles as the underline, but i couldn't figure out
how, as it seems that strike-through is designed to support only 1
style.

My solution was to make a kind of hack to display the underline as
strike-through, and it worked.

Another solution was to reuse the code from display space type, for make
a new display property type (as suggested by Gerd), but I ended up
getting lost when I saw too many references to this in the source code,
so for now the hack was the only solution I could think of.

This should work well in both GUI and TUI frames.

In GUI, the line will be displayed as a double horizontal line (as
shown in the screenshot)

[Captura desde 2025-08-08 23-05-44.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

And in TUI, it will be displayed as a normal underline (or
strike-through if underline is not supported).

Optionally, I've added a new minor mode to enable this outside
whitespace-mode (an example of use in this would be in the NEWS file or
in *Compile-Log* buffers).

[0001-whitespace-mode-Prettify-page-delimiters-characters..patch (text/x-patch, attachment)]

[Message part 5 (text/plain, inline)]

-- 
- E.G via Gnus and Org.

Message #62 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 09 Aug 2025 12:35:01 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Visuwesh <visuweshm <at> gmail.com>,  gerd.moellmann <at> gmail.com,
>   77544 <at> debbugs.gnu.org
> Date: Fri, 08 Aug 2025 23:09:03 -0600
> 
> Sorry for the delay, i tried to make the strike-through face property
> support the same line styles as the underline, but i couldn't figure out
> how, as it seems that strike-through is designed to support only 1
> style.
> 
> My solution was to make a kind of hack to display the underline as
> strike-through, and it worked.

Why is it a problem to show a normal underline?

> Optionally, I've added a new minor mode to enable this outside
> whitespace-mode (an example of use in this would be in the NEWS file or
> in *Compile-Log* buffers).

I'm not sure it is justified to have a separate mode for this.

> +---
> +*** 'whitespace-mode' now can prettify page delimiters characters (^L).
> +If 'page-delimiters' is set in 'whitespace-style', or the new minor mode
> +'whitespace-page-delimiters-mode' is on, the page delimiters characters
                                                     ^^^^^^^^^^
"delimiter", singular.

> +(^L) are displayed as a pretty horizontal line that spans the entire
> +width of the window.  The new 'whitespace-page-delimiter' face, can be
                                                                 ^
That comma should be deleted.

> +used for customize the appearence
        ^^^^^^^^^^^^^
Either "to customize" or "for customizing".

I think we should also mention that font-lock must be ON for this to
work.  E.g., does it work in Fundamental mode?

> +;;;###autoload
> +(define-minor-mode whitespace-page-delimiters-mode
> +  "Display page delimiters characters as horizontal lines."
> +  :group 'whitespace
> +  (cond
> +   ((and whitespace-mode (not (memq 'page-delimiters whitespace-style)))
> +    (setq-local whitespace-style
> +                (cons 'page-delimiters whitespace-style))
> +    (whitespace-mode +1))
> +   (whitespace-page-delimiters-mode
> +    (font-lock-add-keywords nil whitespace--page-delimiters-keyword)
> +    (unless (memq 'display font-lock-extra-managed-props)
> +      (setq-local font-lock-extra-managed-props
> +                  (cons 'display font-lock-extra-managed-props)))
> +    (font-lock-flush))
> +   (t
> +    (font-lock-remove-keywords nil whitespace--page-delimiters-keyword)
> +    (font-lock-flush))))

Is it wise to support this minor mode outside of whitespace-mode?  Why
shouldn't this work only if whitespace-mode is ON?  It complicates the
implementation, and adds 'display' properties to font-lock-keywords,
but I don't quite see the justification.

Message #65 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 09 Aug 2025 18:25:36 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: Visuwesh <visuweshm <at> gmail.com>,  gerd.moellmann <at> gmail.com,
>>   77544 <at> debbugs.gnu.org
>> Date: Fri, 08 Aug 2025 23:09:03 -0600
>> 
>> Sorry for the delay, i tried to make the strike-through face property
>> support the same line styles as the underline, but i couldn't figure out
>> how, as it seems that strike-through is designed to support only 1
>> style.
>> 
>> My solution was to make a kind of hack to display the underline as
>> strike-through, and it worked.
>
> Why is it a problem to show a normal underline?

Actually it is more for stylistic reasons than anything else, many third
party packages that implement this functionality always use the
strike-through property, never underline (mainly to show it as a
horizontal rule), to mention a few: form-feed, form-feed-st,
page-break-lines, and org-modern.

Some users or themes may prefer to use the same styles that underline
now provides (for this horizontal rule), which however are not available
in strike-through, to maintain this consistency, if the face has the
underline property, it will be displayed as if it were a strike-through,
otherwise it will be displayed normally.

>> Optionally, I've added a new minor mode to enable this outside
>> whitespace-mode (an example of use in this would be in the NEWS file or
>> in *Compile-Log* buffers).
>
> I'm not sure it is justified to have a separate mode for this.

I don't see why not, whitespace.el have 'whitespace-newline-mode', which
is only used for toggle the newline visualization.

This avoids having to enable whitespace-mode (which can include spaces
and tabs marks in the buffer) to enable just this cosmetic.

>> +;;;###autoload
>> +(define-minor-mode whitespace-page-delimiters-mode
>> +  "Display page delimiters characters as horizontal lines."
>> +  :group 'whitespace
>> +  (cond
>> +   ((and whitespace-mode (not (memq 'page-delimiters whitespace-style)))
>> +    (setq-local whitespace-style
>> +                (cons 'page-delimiters whitespace-style))
>> +    (whitespace-mode +1))
>> +   (whitespace-page-delimiters-mode
>> +    (font-lock-add-keywords nil whitespace--page-delimiters-keyword)
>> +    (unless (memq 'display font-lock-extra-managed-props)
>> +      (setq-local font-lock-extra-managed-props
>> +                  (cons 'display font-lock-extra-managed-props)))
>> +    (font-lock-flush))
>> +   (t
>> +    (font-lock-remove-keywords nil whitespace--page-delimiters-keyword)
>> +    (font-lock-flush))))
>
> Is it wise to support this minor mode outside of whitespace-mode?  Why
> shouldn't this work only if whitespace-mode is ON?  It complicates the
> implementation, and adds 'display' properties to font-lock-keywords,
> but I don't quite see the justification.

A better alternative is to make this minor mode act as
'whitespace-newline-mode', to toggle the visibility of page delimiters
if whitespace-mode is activated, otherwise, activate whitespace-mode to
only display them.

I've updated the patch, so the minor should work in fundamental-mode and
toggle the page-delimiter visualization.

[0001-whitespace-mode-Prettify-page-delimiters-characters..patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
- E.G via Gnus and Org.

Message #68 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 10 Aug 2025 08:23:35 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> Date: Sat, 09 Aug 2025 18:25:36 -0600
> 
> >> My solution was to make a kind of hack to display the underline as
> >> strike-through, and it worked.
> >
> > Why is it a problem to show a normal underline?
> 
> Actually it is more for stylistic reasons than anything else, many third
> party packages that implement this functionality always use the
> strike-through property, never underline (mainly to show it as a
> horizontal rule), to mention a few: form-feed, form-feed-st,
> page-break-lines, and org-modern.
> 
> Some users or themes may prefer to use the same styles that underline
> now provides (for this horizontal rule), which however are not available
> in strike-through, to maintain this consistency, if the face has the
> underline property, it will be displayed as if it were a strike-through,
> otherwise it will be displayed normally.

I still ask why not show a normal underline? why do we need to install
kludges just because other packages do something?  (And this is even
before we test the kludge on all supported terminal types and see what
it yields.)  Emacs code should provide clean implementations, with as
few kludges as possible and only where nothing else will solve the
problem.  This is not that case, is it?

Did you try to use the same trick as we do in the definition of the
log-edit-headers-separator face?  It is known to work on all GUI
terminals, and looks quite pretty.

> >> Optionally, I've added a new minor mode to enable this outside
> >> whitespace-mode (an example of use in this would be in the NEWS file or
> >> in *Compile-Log* buffers).
> >
> > I'm not sure it is justified to have a separate mode for this.
> 
> I don't see why not, whitespace.el have 'whitespace-newline-mode', which
> is only used for toggle the newline visualization.

But whitespace-newline-mode can only be activated if whitespace-mode
is active, right?

> > Is it wise to support this minor mode outside of whitespace-mode?  Why
> > shouldn't this work only if whitespace-mode is ON?  It complicates the
> > implementation, and adds 'display' properties to font-lock-keywords,
> > but I don't quite see the justification.
> 
> A better alternative is to make this minor mode act as
> 'whitespace-newline-mode', to toggle the visibility of page delimiters
> if whitespace-mode is activated, otherwise, activate whitespace-mode to
> only display them.

Yes.

Message #71 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sun, 10 Aug 2025 22:11:15 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
>> Date: Sat, 09 Aug 2025 18:25:36 -0600
>> 
>> >> My solution was to make a kind of hack to display the underline as
>> >> strike-through, and it worked.
>> >
>> > Why is it a problem to show a normal underline?
>> 
>> Actually it is more for stylistic reasons than anything else, many third
>> party packages that implement this functionality always use the
>> strike-through property, never underline (mainly to show it as a
>> horizontal rule), to mention a few: form-feed, form-feed-st,
>> page-break-lines, and org-modern.
>> 
>> Some users or themes may prefer to use the same styles that underline
>> now provides (for this horizontal rule), which however are not available
>> in strike-through, to maintain this consistency, if the face has the
>> underline property, it will be displayed as if it were a strike-through,
>> otherwise it will be displayed normally.
>
> I still ask why not show a normal underline? why do we need to install
> kludges just because other packages do something?  (And this is even
> before we test the kludge on all supported terminal types and see what
> it yields.)

The "hack" will only works if the Emacs session supports underline and
its styles, otherwise it will use strike-through or only highlight the
line.

I've tested it on my tty, and since there doesn't support underline and
strike-through, it just highlight the line.

> Emacs code should provide clean implementations, with as
> few kludges as possible and only where nothing else will solve the
> problem.  This is not that case, is it?

This was just temporary, as I ran out of ideas (and time) to implement
this feature in C.

I removed the hack in this new patch, it should use underline (if supported),
otherwise it will use strike-through or highlight the line.

[0001-whitespace-mode-Prettify-page-delimiters-characters..patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

> Did you try to use the same trick as we do in the definition of the
> log-edit-headers-separator face?  It is known to work on all GUI
> terminals, and looks quite pretty.

Yes, I've tried it, but it doesn't work if 'display-line-numbers-mode'
is enabled.

>> >> Optionally, I've added a new minor mode to enable this outside
>> >> whitespace-mode (an example of use in this would be in the NEWS file or
>> >> in *Compile-Log* buffers).
>> >
>> > I'm not sure it is justified to have a separate mode for this.
>> 
>> I don't see why not, whitespace.el have 'whitespace-newline-mode', which
>> is only used for toggle the newline visualization.
>
> But whitespace-newline-mode can only be activated if whitespace-mode
> is active, right?

No, As far as I have tested, 'whitespace-newline-mode' can be activated
anywhere (even if whitespace-mode is not enabled).

-- 
- E.G via Gnus and Org.

Message #74 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Mon, 11 Aug 2025 15:27:59 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> Date: Sun, 10 Aug 2025 22:11:15 -0600
> 
> > Did you try to use the same trick as we do in the definition of the
> > log-edit-headers-separator face?  It is known to work on all GUI
> > terminals, and looks quite pretty.
> 
> Yes, I've tried it, but it doesn't work if 'display-line-numbers-mode'
> is enabled.

??? Doesn't work in what way?  I just tried it, and didn't see any
problems.

> >> >> Optionally, I've added a new minor mode to enable this outside
> >> >> whitespace-mode (an example of use in this would be in the NEWS file or
> >> >> in *Compile-Log* buffers).
> >> >
> >> > I'm not sure it is justified to have a separate mode for this.
> >> 
> >> I don't see why not, whitespace.el have 'whitespace-newline-mode', which
> >> is only used for toggle the newline visualization.
> >
> > But whitespace-newline-mode can only be activated if whitespace-mode
> > is active, right?
> 
> No, As far as I have tested, 'whitespace-newline-mode' can be activated
> anywhere (even if whitespace-mode is not enabled).

And it activates whitespace-mode if you do that, right?

Message #77 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Mon, 11 Aug 2025 20:49:48 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
>> Date: Sun, 10 Aug 2025 22:11:15 -0600
>> 
>> > Did you try to use the same trick as we do in the definition of the
>> > log-edit-headers-separator face?  It is known to work on all GUI
>> > terminals, and looks quite pretty.
>> 
>> Yes, I've tried it, but it doesn't work if 'display-line-numbers-mode'
>> is enabled.
>
> ??? Doesn't work in what way?  I just tried it, and didn't see any
> problems.

'log-edit-headers-separator' uses the height (exactly at 0.1) for
display it as an line, (instead of using underline or strike-through),
however this effect will not work if 'display-line-numbers-mode' is
activated.

On the other hand, 'whitespace-page-delimiter' uses underline (although
it also uses the height at 0.1, but that's only for when
display-line-numbers-mode is enabled).

>> >> >> Optionally, I've added a new minor mode to enable this outside
>> >> >> whitespace-mode (an example of use in this would be in the NEWS file or
>> >> >> in *Compile-Log* buffers).
>> >> >
>> >> > I'm not sure it is justified to have a separate mode for this.
>> >> 
>> >> I don't see why not, whitespace.el have 'whitespace-newline-mode', which
>> >> is only used for toggle the newline visualization.
>> >
>> > But whitespace-newline-mode can only be activated if whitespace-mode
>> > is active, right?
>> 
>> No, As far as I have tested, 'whitespace-newline-mode' can be activated
>> anywhere (even if whitespace-mode is not enabled).
>
> And it activates whitespace-mode if you do that, right?

Yes.

-- 
- E.G via Gnus and Org.

Message #80 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Mon, 11 Aug 2025 20:53:44 -0600

Elijah Gabe Pérez <eg642616 <at> gmail.com> writes:

> On the other hand, 'whitespace-page-delimiter' uses underline (although
> it also uses the height at 0.1, but that's only for when
> display-line-numbers-mode is enabled).
                            ^^ * is not
                            sorry i forgot to type the "not" here.

-- 
- E.G via Gnus and Org.

Message #83 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Tue, 12 Aug 2025 14:52:30 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> Date: Mon, 11 Aug 2025 20:49:48 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> >> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> >> Date: Sun, 10 Aug 2025 22:11:15 -0600
> >> 
> >> > Did you try to use the same trick as we do in the definition of the
> >> > log-edit-headers-separator face?  It is known to work on all GUI
> >> > terminals, and looks quite pretty.
> >> 
> >> Yes, I've tried it, but it doesn't work if 'display-line-numbers-mode'
> >> is enabled.
> >
> > ??? Doesn't work in what way?  I just tried it, and didn't see any
> > problems.
> 
> 'log-edit-headers-separator' uses the height (exactly at 0.1) for
> display it as an line, (instead of using underline or strike-through),
> however this effect will not work if 'display-line-numbers-mode' is
> activated.

It did work for me.  Can you show a recipe?

> On the other hand, 'whitespace-page-delimiter' uses underline (although
> it also uses the height at 0.1, but that's only for when
> display-line-numbers-mode is enabled).

Sorry, I don't follow.  What did you want to say here?

My point is that log-edit-headers-separator is a way to show a visual
separator on GUI frames, so instead of inventing new visuals, it might
be better to use existing and known ones.

> >> >> >> Optionally, I've added a new minor mode to enable this outside
> >> >> >> whitespace-mode (an example of use in this would be in the NEWS file or
> >> >> >> in *Compile-Log* buffers).
> >> >> >
> >> >> > I'm not sure it is justified to have a separate mode for this.
> >> >> 
> >> >> I don't see why not, whitespace.el have 'whitespace-newline-mode', which
> >> >> is only used for toggle the newline visualization.
> >> >
> >> > But whitespace-newline-mode can only be activated if whitespace-mode
> >> > is active, right?
> >> 
> >> No, As far as I have tested, 'whitespace-newline-mode' can be activated
> >> anywhere (even if whitespace-mode is not enabled).
> >
> > And it activates whitespace-mode if you do that, right?
> 
> Yes.

That's what I meant: we should not try to make
whitespace-page-delimiter work without whitespace-mode (if needed,
turn it on when whitespace-page-delimiter is activated).

Message #86 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: "Elijah G." <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Tue, 12 Aug 2025 12:47:16 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org,
>> visuweshm <at> gmail.com
>> Date: Mon, 11 Aug 2025 20:49:48 -0600
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> >> Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org,
>> >> visuweshm <at> gmail.com
>> >> Date: Sun, 10 Aug 2025 22:11:15 -0600
>> >> 
>> >> > Did you try to use the same trick as we do in the definition of
>> >> > the
>> >> > log-edit-headers-separator face?  It is known to work on all
>> >> > GUI
>> >> > terminals, and looks quite pretty.
>> >> 
>> >> Yes, I've tried it, but it doesn't work if
>> >> 'display-line-numbers-mode'
>> >> is enabled.
>> >
>> > ??? Doesn't work in what way?  I just tried it, and didn't see any
>> > problems.
>> 
>> 'log-edit-headers-separator' uses the height (exactly at 0.1) for
>> display it as an line, (instead of using underline or
>> strike-through),
>> however this effect will not work if 'display-line-numbers-mode' is
>> activated.
>
> It did work for me.  Can you show a recipe?

1. emacs -q
2. C-h n
3. M-x whitespace-page-delimiters-mode

You can notice how the line shrinks.

4. M-x display-line-numbers-mode

Shrinking doesn't work here.

However, this is a harmless and not so relevant visual detail, so there
would be no problem.

> My point is that log-edit-headers-separator is a way to show a visual
> separator on GUI frames, so instead of inventing new visuals, it might
> be better to use existing and known ones.

I agree, in the patch this is already solved.

-- 
- E.G via GNU Emacs Android port.

Message #89 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Elijah G." <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Tue, 12 Aug 2025 21:50:58 +0300

> From: "Elijah G." <eg642616 <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> Date: Tue, 12 Aug 2025 12:47:16 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >> Yes, I've tried it, but it doesn't work if
> >> >> 'display-line-numbers-mode'
> >> >> is enabled.
> >> >
> >> > ??? Doesn't work in what way?  I just tried it, and didn't see any
> >> > problems.
> >> 
> >> 'log-edit-headers-separator' uses the height (exactly at 0.1) for
> >> display it as an line, (instead of using underline or
> >> strike-through),
> >> however this effect will not work if 'display-line-numbers-mode' is
> >> activated.
> >
> > It did work for me.  Can you show a recipe?
> 
> 1. emacs -q
> 2. C-h n
> 3. M-x whitespace-page-delimiters-mode
> 
> You can notice how the line shrinks.
> 
> 4. M-x display-line-numbers-mode
> 
> Shrinking doesn't work here.

I tried the same in a buffer under log-edit mode (since your patch is
not yet installed, right?), and there's no problem there.  Can you try
with the separator as itr is used in log-edit mode?

> > My point is that log-edit-headers-separator is a way to show a visual
> > separator on GUI frames, so instead of inventing new visuals, it might
> > be better to use existing and known ones.
> 
> I agree, in the patch this is already solved.

Thanks.

Message #92 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Tue, 12 Aug 2025 19:32:39 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 
>> 1. emacs -q
>> 2. C-h n
>> 3. M-x whitespace-page-delimiters-mode
>> 
>> You can notice how the line shrinks.
>> 
>> 4. M-x display-line-numbers-mode
>> 
>> Shrinking doesn't work here.
>
> I tried the same in a buffer under log-edit mode (since your patch is
> not yet installed, right?),

Yes.

> and there's no problem there.  Can you try
> with the separator as itr is used in log-edit mode?

Sure.

This is now how it will look if display-line-numbers-mode is enabled:

[Captura desde 2025-08-12 19-26-07.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

Updated patch:

[0001-whitespace-mode-Prettify-page-delimiters-characters..patch (text/x-patch, attachment)]

[Message part 5 (text/plain, inline)]

-- 
- E.G via Gnus and Org.

Message #95 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Wed, 13 Aug 2025 14:59:40 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> Date: Tue, 12 Aug 2025 19:32:39 -0600
> 
> >> 4. M-x display-line-numbers-mode
> >> 
> >> Shrinking doesn't work here.
> >
> > I tried the same in a buffer under log-edit mode (since your patch is
> > not yet installed, right?),
> 
> Yes.
> 
> > and there's no problem there.  Can you try
> > with the separator as itr is used in log-edit mode?
> 
> Sure.
> 
> This is now how it will look if display-line-numbers-mode is enabled:

This looks like I'd expect.  Or do you see some problems with this?

> Updated patch:

Thanks.

> +(define-minor-mode whitespace-page-delimiters-mode
> +  "Display page delimiters characters as horizontal lines.
> +
> +Use `whitespace-page-delimiters-mode' only for PAGE DELIMITER
> +character visualization exclusively.  For other visualizations,
> +including PAGE DELIMITER visualization together with (HARD)
> +SPACEs and/or TABs, please, use `whitespace-mode'."

"only ... exclusively" sounds like one of them should be removed.

But I'm not sure what you wanted to say by that paragraph.  Can you
elaborate?

Message #98 received at 77544 <at> debbugs.gnu.org (full text, mbox):

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 77544 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Wed, 13 Aug 2025 11:44:37 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This is now how it will look if display-line-numbers-mode is enabled:
>
> This looks like I'd expect.  Or do you see some problems with this?

I have no problem, IMO this looks more an actual rule.

>> Updated patch:
>
> Thanks.
>
>> +(define-minor-mode whitespace-page-delimiters-mode
>> +  "Display page delimiters characters as horizontal lines.
>> +
>> +Use `whitespace-page-delimiters-mode' only for PAGE DELIMITER
>> +character visualization exclusively.  For other visualizations,
>> +including PAGE DELIMITER visualization together with (HARD)
>> +SPACEs and/or TABs, please, use `whitespace-mode'."
>
> "only ... exclusively" sounds like one of them should be removed.
>
> But I'm not sure what you wanted to say by that paragraph.  Can you
> elaborate?

Well, that part was copied from 'whitespace-newline-mode' docstring.

I've removed that part, so it should not be confusing.

[0001-whitespace-mode-New-style-to-prettify-page-delimiter.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
- E.G via Gnus and Org.

Message #103 received at 77544-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 77544-done <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: Re: bug#77544: (WIP) [PATCH] Prettify page separators.
Date: Sat, 16 Aug 2025 14:43:41 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: gerd.moellmann <at> gmail.com,  77544 <at> debbugs.gnu.org,  visuweshm <at> gmail.com
> Date: Wed, 13 Aug 2025 11:44:37 -0600
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> This is now how it will look if display-line-numbers-mode is enabled:
> >
> > This looks like I'd expect.  Or do you see some problems with this?
> 
> I have no problem, IMO this looks more an actual rule.
> 
> >> Updated patch:
> >
> > Thanks.
> >
> >> +(define-minor-mode whitespace-page-delimiters-mode
> >> +  "Display page delimiters characters as horizontal lines.
> >> +
> >> +Use `whitespace-page-delimiters-mode' only for PAGE DELIMITER
> >> +character visualization exclusively.  For other visualizations,
> >> +including PAGE DELIMITER visualization together with (HARD)
> >> +SPACEs and/or TABs, please, use `whitespace-mode'."
> >
> > "only ... exclusively" sounds like one of them should be removed.
> >
> > But I'm not sure what you wanted to say by that paragraph.  Can you
> > elaborate?
> 
> Well, that part was copied from 'whitespace-newline-mode' docstring.
> 
> I've removed that part, so it should not be confusing.

Thanks, now installed on the master branch, and closing the bug.

Please note that I needed to make some minor followup changes; try to
follow our conventions closer in the future.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.