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

Previous Next

To reply to this bug, email your comments to 77544 AT debbugs.gnu.org.

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)]

Previous Next

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