GNU bug report logs -
#78561
[PATCH] Add semantic linefeed support for paragraph filling
Previous Next
Reported by: Roi Martin <jroi.martin <at> gmail.com>
Date: Fri, 23 May 2025 09:59:02 UTC
Severity: normal
Tags: patch
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 78561 in the body.
You can then email your comments to 78561 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
mbork <at> mbork.pl, bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Fri, 23 May 2025 09:59:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Roi Martin <jroi.martin <at> gmail.com>:
New bug report received and forwarded. Copy sent to
mbork <at> mbork.pl, bug-gnu-emacs <at> gnu.org.
(Fri, 23 May 2025 09:59:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
This patch adds semantic linefeed support for paragraph filling. The
functionality has been discussed in the emacs-devel mailing list in the
following threads:
- Fill paragraph using semantic linefeeds: https://lists.gnu.org/archive/html/emacs-devel/2025-03/msg00035.html
- [GNU ELPA] New package: semlf: https://lists.gnu.org/archive/html/emacs-devel/2025-03/msg00702.html
In the second thread we agreed on sending a patch to core instead of
adding a new package to GNU ELPA.
Given that this is a first version, I have not added any reference to
the manuals. If you think it makes sense, please let me know and I'll
modify the patch accordingly.
What follows is a detailed explanation of the term semantic linefeeds,
so we have all the information in one single place.
The term "semantic linefeeds" or "semantic line breaks" refers to a set
of conventions for using insensitive vertical whitespace to structure
prose along semantic boundaries.
The concept was first introduced by Brian Kernighan in "UNIX for
Beginners" [1] in October 1974.
Hints for Preparing Documents
Most documents go through several versions (always more than you
expected) before they are finally finished. Accordingly, you should
do whatever possible to make the job of changing them easy.
First, when you do the purely mechanical operations of typing, type so
subsequent editing will be easy. Start each sentence on a new line.
Make lines short, and break lines at natural places, such as after
commas and semicolons, rather than randomly. Since most people change
documents by rewriting phrases and adding, deleting and rearranging
sentences, these precautions simplify any editing you have to do
later.
Semantic linefeeds are usually used with markup languages that are not
sensitive to newlines when exported to a different format (e.g. Org,
Texinfo, Markdown).
Let's say that we have the following paragraph in an Org document:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor. Incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat.
After filling the paragraph using semantic linefeeds, the result is:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor.
Incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
ut aliquip ex ea commodo consequat.
However, when exported, in both cases the result is:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor. Incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat.
So, what are the benefits?
One of the greatest benefits is that semantic linefeeds are "diff
friendly".
For example,
-Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
-tempor. Incididunt ut labore et dolore magna aliqua. Ut enim ad minim
-veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
-commodo consequat.
+Lorem ipsum dolor sit amet, XXXXX consectetur adipiscing elit, sed do
+eiusmod tempor. Incididunt ut labore et dolore magna aliqua. Ut enim
+ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
+aliquip ex ea commodo consequat.
Versus,
-Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
-tempor.
+Lorem ipsum dolor sit amet, XXXXX consectetur adipiscing elit, sed do
+eiusmod tempor.
Incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
ut aliquip ex ea commodo consequat.
Semantic linefeeds make easier to spot that the word "XXXXX" was added
in the first line.
Also, they are convenient during code reviews. Shorter diffs and
separating "ideas" with newlines allow to be more accurate when adding
comments.
The site "Semantic Line Breaks" [2] by Mattt and the blog post "Semantic
Linefeeds" [3] by Brandon Rhodes are both excellent references.
[1] https://web.archive.org/web/20130108163017if_/http://miffy.tom-yam.or.jp:80/2238/ref/beg.pdf
[2] https://sembr.org/
[3] https://rhodesmill.org/brandon/2012/one-sentence-per-line/
[0001-Add-semantic-linefeed-support-for-paragraph-filling.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Fri, 23 May 2025 11:12:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> Cc: Marcin Borkowski <mbork <at> mbork.pl>
> From: Roi Martin <jroi.martin <at> gmail.com>
> Date: Fri, 23 May 2025 11:58:02 +0200
>
> This patch adds semantic linefeed support for paragraph filling. The
> functionality has been discussed in the emacs-devel mailing list in the
> following threads:
>
> - Fill paragraph using semantic linefeeds: https://lists.gnu.org/archive/html/emacs-devel/2025-03/msg00035.html
> - [GNU ELPA] New package: semlf: https://lists.gnu.org/archive/html/emacs-devel/2025-03/msg00702.html
>
> In the second thread we agreed on sending a patch to core instead of
> adding a new package to GNU ELPA.
>
> Given that this is a first version, I have not added any reference to
> the manuals. If you think it makes sense, please let me know and I'll
> modify the patch accordingly.
>
> What follows is a detailed explanation of the term semantic linefeeds,
> so we have all the information in one single place.
>
> The term "semantic linefeeds" or "semantic line breaks" refers to a set
> of conventions for using insensitive vertical whitespace to structure
> prose along semantic boundaries.
>
> The concept was first introduced by Brian Kernighan in "UNIX for
> Beginners" [1] in October 1974.
>
> Hints for Preparing Documents
>
> Most documents go through several versions (always more than you
> expected) before they are finally finished. Accordingly, you should
> do whatever possible to make the job of changing them easy.
>
> First, when you do the purely mechanical operations of typing, type so
> subsequent editing will be easy. Start each sentence on a new line.
> Make lines short, and break lines at natural places, such as after
> commas and semicolons, rather than randomly. Since most people change
> documents by rewriting phrases and adding, deleting and rearranging
> sentences, these precautions simplify any editing you have to do
> later.
>
> Semantic linefeeds are usually used with markup languages that are not
> sensitive to newlines when exported to a different format (e.g. Org,
> Texinfo, Markdown).
>
> Let's say that we have the following paragraph in an Org document:
>
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> tempor. Incididunt ut labore et dolore magna aliqua. Ut enim ad minim
> veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
> commodo consequat.
>
> After filling the paragraph using semantic linefeeds, the result is:
>
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> tempor.
> Incididunt ut labore et dolore magna aliqua.
> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
> ut aliquip ex ea commodo consequat.
>
> However, when exported, in both cases the result is:
>
> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> tempor. Incididunt ut labore et dolore magna aliqua. Ut enim ad minim
> veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
> commodo consequat.
>
> So, what are the benefits?
>
> One of the greatest benefits is that semantic linefeeds are "diff
> friendly".
>
> For example,
>
> -Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> -tempor. Incididunt ut labore et dolore magna aliqua. Ut enim ad minim
> -veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
> -commodo consequat.
> +Lorem ipsum dolor sit amet, XXXXX consectetur adipiscing elit, sed do
> +eiusmod tempor. Incididunt ut labore et dolore magna aliqua. Ut enim
> +ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
> +aliquip ex ea commodo consequat.
>
> Versus,
>
> -Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
> -tempor.
> +Lorem ipsum dolor sit amet, XXXXX consectetur adipiscing elit, sed do
> +eiusmod tempor.
> Incididunt ut labore et dolore magna aliqua.
> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi
> ut aliquip ex ea commodo consequat.
>
> Semantic linefeeds make easier to spot that the word "XXXXX" was added
> in the first line.
>
> Also, they are convenient during code reviews. Shorter diffs and
> separating "ideas" with newlines allow to be more accurate when adding
> comments.
>
> The site "Semantic Line Breaks" [2] by Mattt and the blog post "Semantic
> Linefeeds" [3] by Brandon Rhodes are both excellent references.
>
> [1] https://web.archive.org/web/20130108163017if_/http://miffy.tom-yam.or.jp:80/2238/ref/beg.pdf
> [2] https://sembr.org/
> [3] https://rhodesmill.org/brandon/2012/one-sentence-per-line/
Thanks.
> +(defun fill-paragraph-semlf (&optional justify)
> + "Fill paragraph at or after point using semantic linefeeds.
> +
> +This function ensures that a newline character follows every
> +sentence, as punctuated by a period (.), exclamation mark (!), or
> +question mark (?).
This explanation of what is "semantic linefeeds" is a good starting
point, but it is not enough. For starters, "ensures" hints but
doesn't say explicitly that if there's no newline there, it is
inserted. Also, I think a URL to at least one site explaining what
"semantic linefeeds" are should be in the doc string.
> + (when (and (> (point) (line-beginning-position))
> + (< (point) (line-end-position)))
> + (delete-horizontal-space)
> + (newline)
Are you sure 'newline' is the right function to call here? It doesn't
just insert the newline character, at least not in all the cases.
Perhaps inserting a literal newline character is better?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Fri, 23 May 2025 15:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> Given that this is a first version, I have not added any reference to
> the manuals. If you think it makes sense, please let me know and I'll
> modify the patch accordingly.
Maybe a short version of the explanation you give below would be good to
have in the manual (tho Eli suggests a URL instead, so maybe that's
good enough?).
> +(defun fill-paragraph-semlf (&optional justify)
> + "Fill paragraph at or after point using semantic linefeeds.
> +
> +This function ensures that a newline character follows every
> +sentence, as punctuated by a period (.), exclamation mark (!), or
> +question mark (?).
This seems inaccurate: it just uses whichever definition of sentence is
used by `forward-sentence`, so it may ignore some of those chars or pay
attention to others.
> +If JUSTIFY is non-nil (interactively, with prefix argument), justify as
> +well. If `sentence-end-double-space' is non-nil, then period followed
> +by one space does not end a sentence, so don't break a line there. The
> +variable `fill-column' controls the width for filling."
I'd move the "The" to the last line. 🙂
> + (interactive "P")
> + (save-excursion
> + (let ((end (progn
> + (fill-forward-paragraph 1)
> + (backward-word)
> + (end-of-line)
> + (point)))
> + (start (progn
> + (fill-forward-paragraph -1)
> + (forward-word)
> + (beginning-of-line)
> + (point)))
> + pfx)
> + (with-restriction start end
> + (let ((fill-column (point-max)))
> + (setq pfx (or (fill-region-as-paragraph (point-min) (point-max)) "")))
> + (goto-char (point-min))
> + (while (not (eobp))
> + (let ((fill-prefix pfx))
> + (fill-region-as-paragraph (point)
> + (progn (forward-sentence) (point))
> + justify))
> + (when (and (> (point) (line-beginning-position))
> + (< (point) (line-end-position)))
> + (delete-horizontal-space)
> + (newline)
> + (insert pfx))))))
> + t)
Please try and separate it into a `fill-region-semlf` function and then
another one which applies it to a paragraph, so that it can also be used
to fill a specific user-specified region (or the whole buffer).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 24 May 2025 12:16:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> +(defun fill-paragraph-semlf (&optional justify)
>> + "Fill paragraph at or after point using semantic linefeeds.
>> +
>> +This function ensures that a newline character follows every
>> +sentence, as punctuated by a period (.), exclamation mark (!), or
>> +question mark (?).
>
> This explanation of what is "semantic linefeeds" is a good starting
> point, but it is not enough. For starters, "ensures" hints but
> doesn't say explicitly that if there's no newline there, it is
> inserted. Also, I think a URL to at least one site explaining what
> "semantic linefeeds" are should be in the doc string.
I would prefer to avoid depending on external URLs to explain the
concept. I'd link to an external reference if, for instance, this
feature was backed by an standard located in a well-known site
(e.g. IETF RFCs). In this case, the concept is quite simple and I agree
with Stefan in that we can provide our own interpretation in the manual
and link to the Info node from the doc string. If you prefer to avoid
changing the manual until this is well tested, then we can provide a
more detailed explanation in the doc string itself. What do you think?
>> + (when (and (> (point) (line-beginning-position))
>> + (< (point) (line-end-position)))
>> + (delete-horizontal-space)
>> + (newline)
>
> Are you sure 'newline' is the right function to call here? It doesn't
> just insert the newline character, at least not in all the cases.
> Perhaps inserting a literal newline character is better?
The reason behind using 'newline' is to support documents that follow
other conventions to represent newlines (e.g. '\r\n' or '\r'). Does it
make sense? Is this the right approach?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 24 May 2025 13:03:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Roi Martin <jroi.martin <at> gmail.com>
> Cc: 78561 <at> debbugs.gnu.org, mbork <at> mbork.pl, monnier <at> iro.umontreal.ca
> Date: Sat, 24 May 2025 14:15:37 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > This explanation of what is "semantic linefeeds" is a good starting
> > point, but it is not enough. For starters, "ensures" hints but
> > doesn't say explicitly that if there's no newline there, it is
> > inserted. Also, I think a URL to at least one site explaining what
> > "semantic linefeeds" are should be in the doc string.
>
> I would prefer to avoid depending on external URLs to explain the
> concept.
Since the concept came from outside, why not?
> I'd link to an external reference if, for instance, this
> feature was backed by an standard located in a well-known site
> (e.g. IETF RFCs). In this case, the concept is quite simple and I agree
> with Stefan in that we can provide our own interpretation in the manual
> and link to the Info node from the doc string.
There's no contradiction: we could describe this in our documentation
and also mention the external references. We do that, for example,
for Unicode-related features.
> >> + (when (and (> (point) (line-beginning-position))
> >> + (< (point) (line-end-position)))
> >> + (delete-horizontal-space)
> >> + (newline)
> >
> > Are you sure 'newline' is the right function to call here? It doesn't
> > just insert the newline character, at least not in all the cases.
> > Perhaps inserting a literal newline character is better?
>
> The reason behind using 'newline' is to support documents that follow
> other conventions to represent newlines (e.g. '\r\n' or '\r'). Does it
> make sense? Is this the right approach?
In Emacs, there's only one "newline convention", the one that uses the
newline (LFD) character. The different en d-of-line conventions are
supported during I/O: we "encode" newlines as CR-LF pair for Windows,
for example, when saving buffers to files, and "decode" CR-LF back
into a single newline when reading files into buffers.
By contrast, the 'newline' function does other things, in addition to
inserting the newline character; see its documentation for the
details. It seems to me that some of those additional actions is not
something this feature will want, because this feature is _only_ about
where to break text into physical lines.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 24 May 2025 13:39:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Roi Martin <jroi.martin <at> gmail.com>
>> Cc: 78561 <at> debbugs.gnu.org, mbork <at> mbork.pl, monnier <at> iro.umontreal.ca
>> Date: Sat, 24 May 2025 14:15:37 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > This explanation of what is "semantic linefeeds" is a good starting
>> > point, but it is not enough. For starters, "ensures" hints but
>> > doesn't say explicitly that if there's no newline there, it is
>> > inserted. Also, I think a URL to at least one site explaining what
>> > "semantic linefeeds" are should be in the doc string.
>>
>> I would prefer to avoid depending on external URLs to explain the
>> concept.
>
> Since the concept came from outside, why not?
>
>> I'd link to an external reference if, for instance, this
>> feature was backed by an standard located in a well-known site
>> (e.g. IETF RFCs). In this case, the concept is quite simple and I agree
>> with Stefan in that we can provide our own interpretation in the manual
>> and link to the Info node from the doc string.
>
> There's no contradiction: we could describe this in our documentation
> and also mention the external references. We do that, for example,
> for Unicode-related features.
OK. I'll update the patch accordingly.
>> >> + (when (and (> (point) (line-beginning-position))
>> >> + (< (point) (line-end-position)))
>> >> + (delete-horizontal-space)
>> >> + (newline)
>> >
>> > Are you sure 'newline' is the right function to call here? It doesn't
>> > just insert the newline character, at least not in all the cases.
>> > Perhaps inserting a literal newline character is better?
>>
>> The reason behind using 'newline' is to support documents that follow
>> other conventions to represent newlines (e.g. '\r\n' or '\r'). Does it
>> make sense? Is this the right approach?
>
> In Emacs, there's only one "newline convention", the one that uses the
> newline (LFD) character. The different en d-of-line conventions are
> supported during I/O: we "encode" newlines as CR-LF pair for Windows,
> for example, when saving buffers to files, and "decode" CR-LF back
> into a single newline when reading files into buffers.
Got it. Thanks a lot for the explanation. That simplifies things a
lot.
> By contrast, the 'newline' function does other things, in addition to
> inserting the newline character; see its documentation for the
> details. It seems to me that some of those additional actions is not
> something this feature will want, because this feature is _only_ about
> where to break text into physical lines.
You are right. I replaced it with
(insert "\n")
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 25 May 2025 18:48:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78561 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Given that this is a first version, I have not added any reference to
>> the manuals. If you think it makes sense, please let me know and I'll
>> modify the patch accordingly.
>
> Maybe a short version of the explanation you give below would be good to
> have in the manual (tho Eli suggests a URL instead, so maybe that's
> good enough?).
>
>> +(defun fill-paragraph-semlf (&optional justify)
>> + "Fill paragraph at or after point using semantic linefeeds.
>> +
>> +This function ensures that a newline character follows every
>> +sentence, as punctuated by a period (.), exclamation mark (!), or
>> +question mark (?).
>
> This seems inaccurate: it just uses whichever definition of sentence is
> used by `forward-sentence`, so it may ignore some of those chars or pay
> attention to others.
I have updated the patch with a more precise definition. Also, I added
links to the sources I referenced for semantic linefeeds.
>> +If JUSTIFY is non-nil (interactively, with prefix argument), justify as
>> +well. If `sentence-end-double-space' is non-nil, then period followed
>> +by one space does not end a sentence, so don't break a line there. The
>> +variable `fill-column' controls the width for filling."
>
> I'd move the "The" to the last line. 🙂
Fixed :)
>> + (interactive "P")
>> + (save-excursion
>> + (let ((end (progn
>> + (fill-forward-paragraph 1)
>> + (backward-word)
>> + (end-of-line)
>> + (point)))
>> + (start (progn
>> + (fill-forward-paragraph -1)
>> + (forward-word)
>> + (beginning-of-line)
>> + (point)))
>> + pfx)
>> + (with-restriction start end
>> + (let ((fill-column (point-max)))
>> + (setq pfx (or (fill-region-as-paragraph (point-min) (point-max)) "")))
>> + (goto-char (point-min))
>> + (while (not (eobp))
>> + (let ((fill-prefix pfx))
>> + (fill-region-as-paragraph (point)
>> + (progn (forward-sentence) (point))
>> + justify))
>> + (when (and (> (point) (line-beginning-position))
>> + (< (point) (line-end-position)))
>> + (delete-horizontal-space)
>> + (newline)
>> + (insert pfx))))))
>> + t)
>
> Please try and separate it into a `fill-region-semlf` function and then
> another one which applies it to a paragraph, so that it can also be used
> to fill a specific user-specified region (or the whole buffer).
I'm not sure about this one. The idea is that `fill-paragraph-semlf'
can be assigned as a value for `fill-paragraph-function' (I also
included a mention to this in the doc string) or it ca be called
directly. The thing is that `fill-paragraph' docs say:
The REGION argument is non-nil if called interactively; in that
case, if Transient Mark mode is enabled and the mark is active,
call `fill-region' to fill each of the paragraphs in the active
region, instead of just filling the current paragraph.
And `fill-paragraph-function' docs say:
Note: This only affects ‘fill-paragraph’ and not ‘fill-region’
nor ‘auto-fill-mode’
So, if I'm not wrong, filling regions and paragraphs is different in the
current design.
I agree that it would be useful to apply `fill-paragraph-semlf' on a
region or the whole buffer. But, the same could be said about any other
`fill-paragraph-function'. So, do we really want a specific
`fill-region-semlf' function?
I attach a new version of the patch.
Thanks!
[0001-Add-semantic-linefeed-support-for-paragraph-filling.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 26 May 2025 16:22:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> Please try and separate it into a `fill-region-semlf` function and then
>> another one which applies it to a paragraph, so that it can also be used
>> to fill a specific user-specified region (or the whole buffer).
> I'm not sure about this one. The idea is that `fill-paragraph-semlf'
> can be assigned as a value for `fill-paragraph-function' (I also
> included a mention to this in the doc string) or it can be called
> directly. The thing is that `fill-paragraph' docs say:
Sadly, we don't currently have anything like a `fill-region-function`,
but that's "a bug, not a feature", so we should write new code such that
this misfeature is easier rather than harder to fix in the future.
> I agree that it would be useful to apply `fill-paragraph-semlf' on
> a region or the whole buffer. But, the same could be said about any
> other `fill-paragraph-function'.
Yes, I've had this in my TODO for many years. 🙁
> So, do we really want a specific `fill-region-semlf' function?
Actually, I think I want a `fill-region-as-paragraph-semlf'.
And maybe then some way to tell the `fill.el` code to use that instead
of the default `fill-region-as-paragraph`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 27 May 2025 15:48:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> Please try and separate it into a `fill-region-semlf` function and then
>>> another one which applies it to a paragraph, so that it can also be used
>>> to fill a specific user-specified region (or the whole buffer).
>> I'm not sure about this one. The idea is that `fill-paragraph-semlf'
>> can be assigned as a value for `fill-paragraph-function' (I also
>> included a mention to this in the doc string) or it can be called
>> directly. The thing is that `fill-paragraph' docs say:
>
> Sadly, we don't currently have anything like a `fill-region-function`,
> but that's "a bug, not a feature", so we should write new code such that
> this misfeature is easier rather than harder to fix in the future.
>
>> I agree that it would be useful to apply `fill-paragraph-semlf' on
>> a region or the whole buffer. But, the same could be said about any
>> other `fill-paragraph-function'.
>
> Yes, I've had this in my TODO for many years. 🙁
I'll try to implement it :)
>> So, do we really want a specific `fill-region-semlf' function?
>
> Actually, I think I want a `fill-region-as-paragraph-semlf'.
> And maybe then some way to tell the `fill.el` code to use that instead
> of the default `fill-region-as-paragraph`.
OK, so here is my plan:
First, I'll give a closer look to all the "fill" functions that Emacs
currently provides to understand how every thing fits together and what
is and what is not already supported.
Then, I'll send a new patch to support applying a
`fill-paragraph-function' on a region "as-paragraph" (similar to the
behavior of `fill-region-as-paragraph') and "per-paragraph" (similar to
executing `fill-paragraph' for each paragraph within the region).
Finally, if needed, I can update this patch.
Does it make sense?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 27 May 2025 16:37:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> Yes, I've had this in my TODO for many years. 🙁
> I'll try to implement it :)
For some definition of "it".
>>> So, do we really want a specific `fill-region-semlf' function?
>> Actually, I think I want a `fill-region-as-paragraph-semlf'.
>> And maybe then some way to tell the `fill.el` code to use that instead
>> of the default `fill-region-as-paragraph`.
> OK, so here is my plan:
That plan has a much larger scope than semantic linefeed, so
I recommend you first finish the current patch and take on that
plan afterwards.
What I'm asking is a fairly small refactoring of the code you sent,
I think.
> First, I'll give a closer look to all the "fill" functions that Emacs
> currently provides to understand how every thing fits together and what
> is and what is not already supported.
Sounds good. I can give you a quick summary of what I know.
`fill-paragraph-function`s usually serve as either:
- Some way for the major mode to teach the fill code how to stay within
a major-mode-specific notion of paragraph (e.g. fill within comments
or within strings). This use has made somewhat obsolete by
`fill-paragraph-forward-function` but it's still pretty common.
- Some way for the major mode to teach the fill code about special
line-wrapping conventions (e.g. add a trailing \ on the previous line
to fill C strings, add a leading SPC or TAB to fill rfc822 headers,
..) or to fine tune (adaptive-)fill-prefix.
- Actually change where we break lines for example to fill code in
a "smart" way (like `smie-auto-fill` does).
- It can also be used to prevent filling in some parts
(e.g. titles/headlines).
> Then, I'll send a new patch to support applying a
> `fill-paragraph-function' on a region "as-paragraph" (similar to the
> behavior of `fill-region-as-paragraph') and "per-paragraph" (similar to
> executing `fill-paragraph' for each paragraph within the region).
I think in general these are impossible because we don't know what the
`fill-paragraph-function` actually does. My TODO is instead to provide
different hooks for the above different uses (some hooks already exist
such as `comment-line-break-function` but often they need to be
generalized) to try and make `fill-paragraph-function` effectively
obsolete (without necessarily marking it officially as obsolete).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Wed, 28 May 2025 15:45:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 78561 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I recommend you first finish the current patch and take on that
> plan afterwards.
> What I'm asking is a fairly small refactoring of the code you sent,
> I think.
Please, find attached a new version of the patch.
It contains the following changes:
- Add a new function named `fill-region-as-paragraph-semlf', which fills
a region using semantic linefeeds as if it were a single paragraph.
Its behavior is analogous to `fill-region-as-paragraph'.
- Update the `fill-paragraph-semlf' function to use
`fill-region-as-paragraph-semlf' internally.
- Remove the mention about using `fill-paragraph-semlf' as
`fill-paragraph-function' from docs, given that the long term plan is
to obsolete this.
- Add test for `fill-region-as-paragraph-semlf'.
Thanks a lot for all the explanations. I hope this new version is
closer to what you had in mind.
Roi
[0001-Add-semantic-linefeed-support-for-paragraph-filling.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 31 May 2025 17:41:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> I recommend you first finish the current patch and take on that
>> plan afterwards.
>> What I'm asking is a fairly small refactoring of the code you sent,
>> I think.
>
> Please, find attached a new version of the patch.
Looks good to me. Eli?
> - Remove the mention about using `fill-paragraph-semlf' as
> `fill-paragraph-function' from docs, given that the long term plan is
> to obsolete this.
Well, it's been in my TODO for ages, so maybe we shouldn't assume this
long term plan will materialize soon.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 01 Jun 2025 04:49:06 GMT)
Full text and
rfc822 format available.
Message #41 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 78561 <at> debbugs.gnu.org, Marcin Borkowski
> <mbork <at> mbork.pl>
> Date: Sat, 31 May 2025 13:39:52 -0400
>
> >> I recommend you first finish the current patch and take on that
> >> plan afterwards.
> >> What I'm asking is a fairly small refactoring of the code you sent,
> >> I think.
> >
> > Please, find attached a new version of the patch.
>
> Looks good to me. Eli?
It's okay, but please make sure there are two spaces between
sentences, not one. There are quite a few cases in the patch where
this is not so.
Also, the commit log message should mention the bug number.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 02 Jun 2025 13:07:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 78561 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> It's okay, but please make sure there are two spaces between
> sentences, not one. There are quite a few cases in the patch where
> this is not so.
Fixed in doc strings. The rest of cases correspond to test data where
we want to verify that `sentence-end-double-space' is respected.
> Also, the commit log message should mention the bug number.
Fixed.
RMS replied to me with a review, where he mentioned that this feature
would be more convenient if it were a minor mode. Eli, Stefan, what do
you think? If it makes sense, we can add it in a future patch.
Also, with regard to the paragraph:
For more details about semantic linefeeds, see `https://sembr.org/' and
`https://rhodesmill.org/brandon/2012/one-sentence-per-line/'."
He raised the following concern:
> This sort of information doesn't belong in an Emacs doc string.
> If some of it isimportant for using this feature right, we
> should state the point in this and other doc strings, or in
> the Emacs Manual, That way we can propagate it and update it.
> If information is "if you'd like to know more", not necessary for peopke
> to read to know how to use the feature, then we can refer to it on a web page.
> But we need to have reason to be confident that page will exist for many
> years, serving the same purpose, in a way we would not be ashamed to link to.
>
> Otherwise, depending on it is asking for trouble.
>
> How much material is importaht to link to for this purpose?
As I previously said, I think it should be fine to add a short
explanation in the doc string or in the manual instead of linking with
external sites that are subject to change or be deleted in the future.
I've attached a new version of the patch. It includes the following
changes compared to the previous version:
- Separate sentences in doc strings using two spaces.
- Add bug number to commit log message.
- Slightly reword doc strings, following a suggestion from RMS.
- Add test to check that it is possible to "revert" semlf-filling by
refilling the paragraph, following a suggestion from RMS.
Roi
[0001-Add-semantic-linefeed-support-for-paragraph-filling.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 02 Jun 2025 19:14:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> RMS replied to me with a review, where he mentioned that this feature
> would be more convenient if it were a minor mode. Eli, Stefan, what do
> you think? If it makes sense, we can add it in a future patch.
Yes, it goes in the same direction of my TODO of adding more hooks to
control various aspects of filling. (One of) Those hooks should make it
easy to write such a minor mode.
> I've attached a new version of the patch. It includes the following
> changes compared to the previous version:
LGTM.
Side comment, tho: it would be good to get rid of the `with-restriction`
so that the code can see the surrounding text. In the past such
restrictions in `fill.el` have posed problems for example when we want
to refill code in a way that obeys indentation rules or that
needs to distinguish filling within strings vs filling within comments.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 03 Jun 2025 06:46:03 GMT)
Full text and
rfc822 format available.
Message #50 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> Side comment, tho: it would be good to get rid of the `with-restriction`
> so that the code can see the surrounding text. In the past such
> restrictions in `fill.el` have posed problems for example when we want
> to refill code in a way that obeys indentation rules or that
> needs to distinguish filling within strings vs filling within comments.
The latest version is far from perfect but works well for the most
common use cases. The included tests can given you an idea of the
current state. Are you OK with tackling the `with-restriction'
improvement in a future patch?
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 03 Jun 2025 17:26:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> Are you OK with tackling the `with-restriction'
> improvement in a future patch?
Yes.
Stefan
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 14 Jun 2025 13:44:07 GMT)
Full text and
rfc822 format available.
Notification sent
to
Roi Martin <jroi.martin <at> gmail.com>:
bug acknowledged by developer.
(Sat, 14 Jun 2025 13:44:08 GMT)
Full text and
rfc822 format available.
Message #58 received at 78561-done <at> debbugs.gnu.org (full text, mbox):
> From: Roi Martin <jroi.martin <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rms <at> gnu.org, 78561 <at> debbugs.gnu.org,
> mbork <at> mbork.pl
> Date: Tue, 03 Jun 2025 08:45:17 +0200
>
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> > Side comment, tho: it would be good to get rid of the `with-restriction`
> > so that the code can see the surrounding text. In the past such
> > restrictions in `fill.el` have posed problems for example when we want
> > to refill code in a way that obeys indentation rules or that
> > needs to distinguish filling within strings vs filling within comments.
>
> The latest version is far from perfect but works well for the most
> common use cases. The included tests can given you an idea of the
> current state. Are you OK with tackling the `with-restriction'
> improvement in a future patch?
Thanks, I've now installed this on the master branch, and I'm
therefore closing the bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 06:51:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> The latest version is far from perfect but works well for the most
>> common use cases.
>
> Thanks, I've now installed this on the master branch, and I'm
> therefore closing the bug.
Sorry if I missed something, but I tried to use this feature
and can't find in etc/NEWS whether to set this
(setq-local fill-paragraph-function 'fill-paragraph-semlf)
or this
(setq-local fill-paragraph-function 'fill-region-as-paragraph-semlf)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 07:37:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: eliz <at> gnu.org, jroi.martin <at> gmail.com
> Date: Sun, 15 Jun 2025 09:39:24 +0300
>
> >> The latest version is far from perfect but works well for the most
> >> common use cases.
> >
> > Thanks, I've now installed this on the master branch, and I'm
> > therefore closing the bug.
>
> Sorry if I missed something, but I tried to use this feature
> and can't find in etc/NEWS whether to set this
>
> (setq-local fill-paragraph-function 'fill-paragraph-semlf)
>
> or this
>
> (setq-local fill-paragraph-function 'fill-region-as-paragraph-semlf)
Neither, AFAIU? Those two are commands, not fill-paragraph functions.
They don't implement the protocol defined for fill-paragraph
functions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 07:50:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> (setq-local fill-paragraph-function 'fill-paragraph-semlf)
>
> or this
>
> (setq-local fill-paragraph-function 'fill-region-as-paragraph-semlf)
BTW, when the discussion started, few knew what "semantic line breaks"
were. The new function names shorten the term to "semlf". I tried to
search the Internet for "semlf" and I found only this thread and the
Emacs package discussed here. Is there a good reason for shortening
`semantic-line-breaks' to `semlf' here?
Rudy
--
"The whole science is nothing more than a refinement of everyday
thinking." --- Albert Einstein, 1879-1955
Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 08:09:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: eliz <at> gnu.org, jroi.martin <at> gmail.com
> Date: Sun, 15 Jun 2025 09:49:30 +0200
>
> BTW, when the discussion started, few knew what "semantic line breaks"
> were. The new function names shorten the term to "semlf". I tried to
> search the Internet for "semlf" and I found only this thread and the
> Emacs package discussed here. Is there a good reason for shortening
> `semantic-line-breaks' to `semlf' here?
Apart of its being significantly shorter? No reason, I suppose. But
fill-region-as-paragraph-semantic-line-breaks is IMO too long for a
command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 09:02:03 GMT)
Full text and
rfc822 format available.
Message #73 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Sorry if I missed something, but I tried to use this feature
> and can't find in etc/NEWS whether to set this
One option is setting a key binding, like this:
(keymap-global-set "C-c q" #'fill-paragraph-semlf)
Then you can invoke the command placing the cursor within a paragraph
and using 'C-c q' (or 'M-x fill-paragraph-semlf').
> (setq-local fill-paragraph-function 'fill-paragraph-semlf)
This works. However, the behavior of the usual key binding 'M-q'
depends on the major-mode that is enabled. For instance, `org-mode'
binds 'M-q' to `org-fill-paragraph' and won't invoke
'fill-paragraph-semlf. But placing the cursor within a paragraph a
invoking `fill-paragraph' works. On the flip side, other modes
(e.g. `outline-mode' or `texinfo-mode') don't do that and you can use
'M-q' to invoke `fill-paragraph' and, thus, `fill-paragraph-semlf'
normally.
How to fix this needs further discussion. Eli, Stefan any
recommendation?
Personally, for now, I'm setting a specific key binding to invoke
`fill-paragraph-semlf'.
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 09:14:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> (setq-local fill-paragraph-function 'fill-paragraph-semlf)
>>
>> or this
>>
>> (setq-local fill-paragraph-function 'fill-region-as-paragraph-semlf)
>
> Neither, AFAIU? Those two are commands, not fill-paragraph functions.
> They don't implement the protocol defined for fill-paragraph
> functions.
It should be possible to use `fill-paragraph-semlf' as
`fill-paragraph-function'.
It takes a JUSTIFY argument, which is required by:
(funcall function justify)
in the specific case in `fill-paragraph' ("2. Try
fill-paragraph-function.").
;; 2. Try fill-paragraph-function.
(and (not (eq fill-paragraph-function t))
(or fill-paragraph-function
(and (minibufferp (current-buffer))
(= 1 (point-min))))
(let ((function (or fill-paragraph-function
;; In the minibuffer, don't count
;; the width of the prompt.
'fill-minibuffer-function))
;; If fill-paragraph-function is set, it probably
;; takes care of comments and stuff. If not, it
;; will have to set fill-paragraph-handle-comment
;; back to t explicitly or return nil.
(fill-paragraph-handle-comment nil)
(fill-paragraph-function t))
(funcall function justify)))
It also returns a non-nil value to avoid executing the following cases
in `fill-paragraph'.
Is there anything missing?
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 09:30:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Roi Martin <jroi.martin <at> gmail.com>
> Cc: 78561 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2025 11:12:49 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Neither, AFAIU? Those two are commands, not fill-paragraph functions.
> > They don't implement the protocol defined for fill-paragraph
> > functions.
>
> It should be possible to use `fill-paragraph-semlf' as
> `fill-paragraph-function'.
>
> It takes a JUSTIFY argument, which is required by:
>
> (funcall function justify)
>
> in the specific case in `fill-paragraph' ("2. Try
> fill-paragraph-function.").
>
> ;; 2. Try fill-paragraph-function.
> (and (not (eq fill-paragraph-function t))
> (or fill-paragraph-function
> (and (minibufferp (current-buffer))
> (= 1 (point-min))))
> (let ((function (or fill-paragraph-function
> ;; In the minibuffer, don't count
> ;; the width of the prompt.
> 'fill-minibuffer-function))
> ;; If fill-paragraph-function is set, it probably
> ;; takes care of comments and stuff. If not, it
> ;; will have to set fill-paragraph-handle-comment
> ;; back to t explicitly or return nil.
> (fill-paragraph-handle-comment nil)
> (fill-paragraph-function t))
> (funcall function justify)))
>
> It also returns a non-nil value to avoid executing the following cases
> in `fill-paragraph'.
>
> Is there anything missing?
The doc string of fill-paragraph-function says:
If the function returns nil, then ‘fill-paragraph’ does its normal work.
A value of t means explicitly "do nothing special".
By contrast, the doc string of fill-paragraph-semlf says:
Return the `fill-prefix' used for filling.
Maybe the doc string is inaccurate, but if it's accurate, then its
return value is not what's expected from fill-paragraph-function. Or
what did I miss?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 09:57:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Roi Martin <jroi.martin <at> gmail.com>
>> Cc: 78561 <at> debbugs.gnu.org
>> Date: Sun, 15 Jun 2025 11:12:49 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Neither, AFAIU? Those two are commands, not fill-paragraph functions.
>> > They don't implement the protocol defined for fill-paragraph
>> > functions.
>>
>> It should be possible to use `fill-paragraph-semlf' as
>> `fill-paragraph-function'.
>>
>> It takes a JUSTIFY argument, which is required by:
>>
>> (funcall function justify)
>>
>> in the specific case in `fill-paragraph' ("2. Try
>> fill-paragraph-function.").
>>
>> ;; 2. Try fill-paragraph-function.
>> (and (not (eq fill-paragraph-function t))
>> (or fill-paragraph-function
>> (and (minibufferp (current-buffer))
>> (= 1 (point-min))))
>> (let ((function (or fill-paragraph-function
>> ;; In the minibuffer, don't count
>> ;; the width of the prompt.
>> 'fill-minibuffer-function))
>> ;; If fill-paragraph-function is set, it probably
>> ;; takes care of comments and stuff. If not, it
>> ;; will have to set fill-paragraph-handle-comment
>> ;; back to t explicitly or return nil.
>> (fill-paragraph-handle-comment nil)
>> (fill-paragraph-function t))
>> (funcall function justify)))
>>
>> It also returns a non-nil value to avoid executing the following cases
>> in `fill-paragraph'.
>>
>> Is there anything missing?
>
> The doc string of fill-paragraph-function says:
>
> If the function returns nil, then ‘fill-paragraph’ does its normal work.
> A value of t means explicitly "do nothing special".
>
> By contrast, the doc string of fill-paragraph-semlf says:
>
> Return the `fill-prefix' used for filling.
>
> Maybe the doc string is inaccurate, but if it's accurate, then its
> return value is not what's expected from fill-paragraph-function. Or
> what did I miss?
No, you are right.
I decided to return `fill-prefix' in `fill-paragraph-semlf' because it
seemed to have the same effect as returning t, based on the code I
attached previously. Also, returning `fill-paragraph' seemed more
useful. But, you are right, the contract mentions nil and t explicitly.
Then, what's better? Should we remove the following paragraph from the
doc string of `fill-paragraph-semlf'?
You can use this function as the value of ‘fill-paragraph-function’, so
‘fill-paragraph’ and other filling commands will use it.
Or should we return t in `fill-paragraph-semlf'?
Also, what does "do nothing special" mean exactly?
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 10:25:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Roi Martin <jroi.martin <at> gmail.com>
> Cc: juri <at> linkov.net, 78561 <at> debbugs.gnu.org
> Date: Sun, 15 Jun 2025 11:56:06 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Roi Martin <jroi.martin <at> gmail.com>
> >> Cc: 78561 <at> debbugs.gnu.org
> >> Date: Sun, 15 Jun 2025 11:12:49 +0200
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > Neither, AFAIU? Those two are commands, not fill-paragraph functions.
> >> > They don't implement the protocol defined for fill-paragraph
> >> > functions.
> >>
> >> It should be possible to use `fill-paragraph-semlf' as
> >> `fill-paragraph-function'.
> >>
> >> It takes a JUSTIFY argument, which is required by:
> >>
> >> (funcall function justify)
> >>
> >> in the specific case in `fill-paragraph' ("2. Try
> >> fill-paragraph-function.").
> >>
> >> ;; 2. Try fill-paragraph-function.
> >> (and (not (eq fill-paragraph-function t))
> >> (or fill-paragraph-function
> >> (and (minibufferp (current-buffer))
> >> (= 1 (point-min))))
> >> (let ((function (or fill-paragraph-function
> >> ;; In the minibuffer, don't count
> >> ;; the width of the prompt.
> >> 'fill-minibuffer-function))
> >> ;; If fill-paragraph-function is set, it probably
> >> ;; takes care of comments and stuff. If not, it
> >> ;; will have to set fill-paragraph-handle-comment
> >> ;; back to t explicitly or return nil.
> >> (fill-paragraph-handle-comment nil)
> >> (fill-paragraph-function t))
> >> (funcall function justify)))
> >>
> >> It also returns a non-nil value to avoid executing the following cases
> >> in `fill-paragraph'.
> >>
> >> Is there anything missing?
> >
> > The doc string of fill-paragraph-function says:
> >
> > If the function returns nil, then ‘fill-paragraph’ does its normal work.
> > A value of t means explicitly "do nothing special".
> >
> > By contrast, the doc string of fill-paragraph-semlf says:
> >
> > Return the `fill-prefix' used for filling.
> >
> > Maybe the doc string is inaccurate, but if it's accurate, then its
> > return value is not what's expected from fill-paragraph-function. Or
> > what did I miss?
>
> No, you are right.
>
> I decided to return `fill-prefix' in `fill-paragraph-semlf' because it
> seemed to have the same effect as returning t, based on the code I
> attached previously. Also, returning `fill-paragraph' seemed more
> useful. But, you are right, the contract mentions nil and t explicitly.
>
> Then, what's better? Should we remove the following paragraph from the
> doc string of `fill-paragraph-semlf'?
>
> You can use this function as the value of ‘fill-paragraph-function’, so
> ‘fill-paragraph’ and other filling commands will use it.
>
> Or should we return t in `fill-paragraph-semlf'?
I don't know. Is returning fill-prefix useful in some important cases?
> Also, what does "do nothing special" mean exactly?
It means the fill-paragraph-function did all there is to do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 15 Jun 2025 16:30:03 GMT)
Full text and
rfc822 format available.
Message #88 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> One option is setting a key binding, like this:
>
> (keymap-global-set "C-c q" #'fill-paragraph-semlf)
>
> Then you can invoke the command placing the cursor within a paragraph
> and using 'C-c q' (or 'M-x fill-paragraph-semlf').
Unfortunately, additional keybindings is too much baggage to bear:
more keys to remember and type, etc.
>> (setq-local fill-paragraph-function 'fill-paragraph-semlf)
>
> This works. However, the behavior of the usual key binding 'M-q'
> depends on the major-mode that is enabled. For instance, `org-mode'
> binds 'M-q' to `org-fill-paragraph' and won't invoke
> 'fill-paragraph-semlf. But placing the cursor within a paragraph a
> invoking `fill-paragraph' works. On the flip side, other modes
> (e.g. `outline-mode' or `texinfo-mode') don't do that and you can use
> 'M-q' to invoke `fill-paragraph' and, thus, `fill-paragraph-semlf'
> normally.
I tried to add to .dir-locals.el:
((org-mode . ((fill-paragraph-function . fill-paragraph-semlf))))
and it works nicely. With one exception that it fails on the active region.
But we could add a new variable, e.g. 'fill-region-function'
that will be possible to customize to 'fill-region-as-paragraph-semlf'.
Although it's strange that 'fill-region-as-paragraph-semlf'
doesn't keep empty lines between paragraphs like 'fill-region' does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 10:16:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Then, what's better? Should we remove the following paragraph from the
>> doc string of `fill-paragraph-semlf'?
>>
>> You can use this function as the value of ‘fill-paragraph-function’, so
>> ‘fill-paragraph’ and other filling commands will use it.
>>
>> Or should we return t in `fill-paragraph-semlf'?
>
> I don't know. Is returning fill-prefix useful in some important cases?
That's hard to say until we decide how to "wire" the semantic-linefeed
functions with the generic functions already provided by fill.el. For
instance, coming back to some of the comments done by Stefan,
- How do we fill the paragraphs within the active region? Should we add
a new `fill-region-function' variable and provide a
`fill-region-semlf' function? Should we have a way to tell fill.el to
use a custom `fill-region-as-paragraph' function?
- How do we change how major modes fill a paragraph or a region? For
instance, in the case of org-mode, how do we combine org-mode's
fill-paragraph logic with semantic linefeeds? Should the major mode
be in charge of providing this feature leveraging the existing
semantic-linefeed functions? Should the user change a set of hooks?
What if the major mode already sets this hooks?
Besides that, `fill-paragraph-semlf' calls `fill-forward-paragraph'
internally, so it already takes into account what the major mode defines
as paragraph. And, `fill-region-as-paragraph-semlf' calls
`fill-region-as-paragraph' internally, so if we add a hook to customize
this function, it would take that into account.
I guess the safest call for now is to provide `fill-paragraph-semlf' and
`fill-region-as-paragraph-semlf' as commands that users or major modes
can call directly. What these functions return should make sense in
isolation and, once we know how we want to wire everything together, we
can adapt them to the defined protocols providing wrappers or using
lambdas. For instance,
(defun fill-paragraph-function-semlf (&optional justify)
"Fill paragraph at or after point using semantic linefeeds.
This is a suitable value for `fill-paragraph-function'.
For more details about semantic linefeeds, see `fill-paragraph-semlf'."
(fill-paragraph-semlf justify)
t)
That `fill-paragraph-semlf' returns the `fill-prefix' used to fill the
paragraph seems sound if we expect this function to be used by other
filling functions and matches the behavior of `fill-region-as-paragraph'
and `fill-paragraph' (when `fill-paragraph-function' is nil).
What do you think? Sorry, but I'm still wrapping my head around all the
nuances of the filling code and how major modes make use of it.
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 10:33:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> I tried to add to .dir-locals.el:
>
> ((org-mode . ((fill-paragraph-function . fill-paragraph-semlf))))
>
> and it works nicely.
That's interesting. If I create an org-mode buffer and set
`fill-paragraph-function' with:
(setq-local fill-paragraph-function #'fill-paragraph-semlf)
Invoking `org-fill-paragraph' (bound to 'M-q') does not fill the
paragraph using semantic linefeeds. However, `fill-paragraph' does.
I'll have to dig more into it.
> With one exception that it fails on the active region.
>
> But we could add a new variable, e.g. 'fill-region-function'
> that will be possible to customize to 'fill-region-as-paragraph-semlf'.
Check these sub-threads,
https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-05/msg01088.html
https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-06/msg00920.html
Maybe it is time to move the discussion to emacs-devel?
> Although it's strange that 'fill-region-as-paragraph-semlf'
> doesn't keep empty lines between paragraphs like 'fill-region' does.
`fill-region-as-paragraph-semlf' is analogous to
`fill-region-as-paragraph', so it removes any paragraph breaks in the
region and extra newlines at the end, and fills lines within the region.
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 10:53:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> From: Roi Martin <jroi.martin <at> gmail.com>
> Cc: juri <at> linkov.net, 78561 <at> debbugs.gnu.org
> Date: Mon, 16 Jun 2025 12:14:46 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Then, what's better? Should we remove the following paragraph from the
> >> doc string of `fill-paragraph-semlf'?
> >>
> >> You can use this function as the value of ‘fill-paragraph-function’, so
> >> ‘fill-paragraph’ and other filling commands will use it.
> >>
> >> Or should we return t in `fill-paragraph-semlf'?
> >
> > I don't know. Is returning fill-prefix useful in some important cases?
>
> That's hard to say until we decide how to "wire" the semantic-linefeed
> functions with the generic functions already provided by fill.el. For
> instance, coming back to some of the comments done by Stefan,
>
> - How do we fill the paragraphs within the active region? Should we add
> a new `fill-region-function' variable and provide a
> `fill-region-semlf' function? Should we have a way to tell fill.el to
> use a custom `fill-region-as-paragraph' function?
> - How do we change how major modes fill a paragraph or a region? For
> instance, in the case of org-mode, how do we combine org-mode's
> fill-paragraph logic with semantic linefeeds? Should the major mode
> be in charge of providing this feature leveraging the existing
> semantic-linefeed functions? Should the user change a set of hooks?
> What if the major mode already sets this hooks?
The active region case should be supported, IMO. As for other modes,
what modes could usefully make use of this kind of region-filling?
Org mode might be the only one, but in that case it's something for
Org developers to chime in; I added Ihor to the discussion.
> Besides that, `fill-paragraph-semlf' calls `fill-forward-paragraph'
> internally, so it already takes into account what the major mode defines
> as paragraph. And, `fill-region-as-paragraph-semlf' calls
> `fill-region-as-paragraph' internally, so if we add a hook to customize
> this function, it would take that into account.
Right.
> I guess the safest call for now is to provide `fill-paragraph-semlf' and
> `fill-region-as-paragraph-semlf' as commands that users or major modes
> can call directly.
That's what we currently do, right?
> What do you think? Sorry, but I'm still wrapping my head around all the
> nuances of the filling code and how major modes make use of it.
I'd love to hear Stefan and Ihor to chime in and express their views.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 11:05:03 GMT)
Full text and
rfc822 format available.
Message #100 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> As for other modes, what modes could usefully make use of this kind of
> region-filling? Org mode might be the only one, but in that case it's
> something for Org developers to chime in; I added Ihor to the
> discussion.
I would include all those languages that are not sensitive to newlines
when exported to a different format. For instance, Org, Texinfo, LaTeX
or Markdown. Of course, there might be people that find this kind of
formatting useful when writing text in text-mode or outline-mode.
>> I guess the safest call for now is to provide `fill-paragraph-semlf' and
>> `fill-region-as-paragraph-semlf' as commands that users or major modes
>> can call directly.
>
> That's what we currently do, right?
Yes. But, if we decide to keep it like that, we need to remove the
reference to `fill-paragraph-function' from the doc string of
`fill-paragraph-semlf'. Once we take a decission, I'll send a new
patch.
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 13:17:06 GMT)
Full text and
rfc822 format available.
Message #103 received at submit <at> debbugs.gnu.org (full text, mbox):
Roi Martin <jroi.martin <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> As for other modes, what modes could usefully make use of this kind of
>> region-filling? Org mode might be the only one, but in that case it's
>> something for Org developers to chime in; I added Ihor to the
>> discussion.
>
> I would include all those languages that are not sensitive to newlines
> when exported to a different format. For instance, Org, Texinfo, LaTeX
> or Markdown.
Note that in Markdown, two space characters (#x20) at the end of a line
denote a line break, so such lines should not be filled. (I did not
check whether the code already considers this; apologies for the
superfluous message if it does.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 16:41:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> I tried to add to .dir-locals.el:
>>
>> ((org-mode . ((fill-paragraph-function . fill-paragraph-semlf))))
>>
>> and it works nicely.
>
> That's interesting. If I create an org-mode buffer and set
> `fill-paragraph-function' with:
>
> (setq-local fill-paragraph-function #'fill-paragraph-semlf)
>
> Invoking `org-fill-paragraph' (bound to 'M-q') does not fill the
> paragraph using semantic linefeeds. However, `fill-paragraph' does.
>
> I'll have to dig more into it.
Sorry, I added the following line to my config long ago,
and forgot about it:
;; Revert 'M-q' hijacked by org-mode:
(define-key org-mode-map (vector 'remap 'fill-paragraph) nil)
>> With one exception that it fails on the active region.
>>
>> But we could add a new variable, e.g. 'fill-region-function'
>> that will be possible to customize to 'fill-region-as-paragraph-semlf'.
>
> Check these sub-threads,
>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-05/msg01088.html
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-06/msg00920.html
>
> Maybe it is time to move the discussion to emacs-devel?
Probably better to create a new feature request on bug-gnu-emacs.
>> Although it's strange that 'fill-region-as-paragraph-semlf'
>> doesn't keep empty lines between paragraphs like 'fill-region' does.
>
> `fill-region-as-paragraph-semlf' is analogous to
> `fill-region-as-paragraph', so it removes any paragraph breaks in the
> region and extra newlines at the end, and fills lines within the region.
Then maybe we need another function `fill-region-semlf'.
I see that you already mentioned it earlier.
Another variant is to add a new argument `region' to `fill-paragraph-semlf'.
But the problem is that `fill-paragraph' doesn't forward its argument
`region' to `fill-paragraph-function', i.e. there is
(funcall function justify)
instead of
(funcall function justify region)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Mon, 16 Jun 2025 21:30:02 GMT)
Full text and
rfc822 format available.
Message #109 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> ;; Revert 'M-q' hijacked by org-mode:
> (define-key org-mode-map (vector 'remap 'fill-paragraph) nil)
Maybe it deserves a bug report? Looking at the code, I can't see a good
reason for this hijacking. Maybe it's just a left over from old code.
>> `fill-region-as-paragraph-semlf' is analogous to
>> `fill-region-as-paragraph', so it removes any paragraph breaks in the
>> region and extra newlines at the end, and fills lines within the region.
>
> Then maybe we need another function `fill-region-semlf'.
I expect it would make more sense to introduce
a `fill-region-as-paragraph-function`, so `fill-region` will DTRT after
you set that var to `fill-region-as-paragraph-semlf`. Instead of having
to reinvent/duplicate the code of `fill-region` in a new
`fill-region-semlf`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 17 Jun 2025 06:40:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> ;; Revert 'M-q' hijacked by org-mode:
>> (define-key org-mode-map (vector 'remap 'fill-paragraph) nil)
>
> Maybe it deserves a bug report? Looking at the code, I can't see a good
> reason for this hijacking. Maybe it's just a left over from old code.
Cc-ing Ihor for the definite answer, but I suppose 'org-fill-paragraph'
still exists because it needs the argument 'region', whereas 'fill-paragraph'
calls 'fill-paragraph-function' only with 'justify', not 'region'.
>>> `fill-region-as-paragraph-semlf' is analogous to
>>> `fill-region-as-paragraph', so it removes any paragraph breaks in the
>>> region and extra newlines at the end, and fills lines within the region.
>>
>> Then maybe we need another function `fill-region-semlf'.
>
> I expect it would make more sense to introduce
> a `fill-region-as-paragraph-function`, so `fill-region` will DTRT after
> you set that var to `fill-region-as-paragraph-semlf`. Instead of having
> to reinvent/duplicate the code of `fill-region` in a new
> `fill-region-semlf`.
AFAIS, they have a significant difference: `fill-region-as-paragraph`
merges all selected paragraphs into one paragraph, but `fill-region`
formats each paragraph separately, keeping separators (empty lines)
between them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 17 Jun 2025 06:50:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> I expect it would make more sense to introduce
>> a `fill-region-as-paragraph-function`, so `fill-region` will DTRT after
>> you set that var to `fill-region-as-paragraph-semlf`. Instead of having
>> to reinvent/duplicate the code of `fill-region` in a new
>> `fill-region-semlf`.
>
> AFAIS, they have a significant difference: `fill-region-as-paragraph`
> merges all selected paragraphs into one paragraph, but `fill-region`
> formats each paragraph separately, keeping separators (empty lines)
> between them.
If I'm not wrong, `fill-region' calls `fill-region-as-paragraph'
internally,
(defun fill-region (from to &optional justify nosqueeze to-eop)
;; ...
(setq fill-pfx
(fill-region-as-paragraph (point) end justify nosqueeze))
;; ...
fill-pfx))
And `fill-paragraph' calls `fill-region' if Transient Mark mode is
enabled and the mark is active.
So, the idea is to define a new variable
`fill-region-as-paragraph-function' so `fill-region' uses this variable
instead of calling `fill-region-as-paragraph' directly.
Stefan, I'll send a new patch to support this. I'll also modify
`fill-paragraph-semlf' to respect the `fill-paragraph-function' protocol
(i.e. return t).
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 17 Jun 2025 10:54:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Roi Martin <jroi.martin <at> gmail.com> writes:
> Stefan, I'll send a new patch to support this. I'll also modify
> `fill-paragraph-semlf' to respect the `fill-paragraph-function' protocol
> (i.e. return t).
I've created Bug#78816.
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Thu, 19 Jun 2025 06:42:04 GMT)
Full text and
rfc822 format available.
Message #121 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>>> ;; Revert 'M-q' hijacked by org-mode:
>>> (define-key org-mode-map (vector 'remap 'fill-paragraph) nil)
>>
>> Maybe it deserves a bug report? Looking at the code, I can't see a good
>> reason for this hijacking. Maybe it's just a left over from old code.
>
> Cc-ing Ihor for the definite answer, but I suppose 'org-fill-paragraph'
> still exists because it needs the argument 'region', whereas 'fill-paragraph'
> calls 'fill-paragraph-function' only with 'justify', not 'region'.
Yes. More specifically, when region is active, `fill-paragraph'
completely ignores `fill-paragraph-function' and directly calls
`fill-region' -> `fill-region-as-paragraph'. This behavior cannot be
customized by major modes, so Org has to override the whole
`fill-paragraph' to perform syntax-aware filling.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Thu, 19 Jun 2025 15:23:04 GMT)
Full text and
rfc822 format available.
Message #124 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> Yes. More specifically, when region is active, `fill-paragraph'
> completely ignores `fill-paragraph-function' and directly calls
> `fill-region' -> `fill-region-as-paragraph'. This behavior cannot be
> customized by major modes,
Some of the behavior can, via `fill-paragraph-forward-function`.
And with Roi's `fill-region-as-paragraph-function`, Emacs-31 should
allow customizing a bit more of the behavior.
It would be nice to make it customizable enough that Org doesn't need to
override the `M-q` binding.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 21 Jun 2025 05:05:04 GMT)
Full text and
rfc822 format available.
Message #127 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Yes. More specifically, when region is active, `fill-paragraph'
>> completely ignores `fill-paragraph-function' and directly calls
>> `fill-region' -> `fill-region-as-paragraph'. This behavior cannot be
>> customized by major modes,
>
> Some of the behavior can, via `fill-paragraph-forward-function`.
> And with Roi's `fill-region-as-paragraph-function`, Emacs-31 should
> allow customizing a bit more of the behavior.
>
> It would be nice to make it customizable enough that Org doesn't need to
> override the `M-q` binding.
I think that `fill-region-as-paragraph-function' is a step in the right
direction. What is left is handling `use-hard-newlines'. Currently, Org
mode ignores it as the concept of hard newlines is not compatible with
Org mode syntax and its notion of paragraphs. So, we probably need to
have a way to bypass that branch in `fill-paragraph' or find some way to
handle hard newlines that is compatible with Org mode and then Emacs
introduce a new customization for Org to plug into.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 21 Jun 2025 15:18:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> I think that `fill-region-as-paragraph-function' is a step in the right
> direction. What is left is handling `use-hard-newlines'. Currently, Org
> mode ignores it as the concept of hard newlines is not compatible with
> Org mode syntax and its notion of paragraphs. So, we probably need to
> have a way to bypass that branch in `fill-paragraph' or find some way to
> handle hard newlines that is compatible with Org mode and then Emacs
> introduce a new customization for Org to plug into.
I don't understand: `use-hard-newlines` is nil by default and org mode
doesn't seem to set it, so those users who set it ... get what they deserve?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 21 Jun 2025 18:50:04 GMT)
Full text and
rfc822 format available.
Message #133 received at submit <at> debbugs.gnu.org (full text, mbox):
My 2c here is that this seems rather basic and while the tests pass with
toy lorem-ipsum language it fails completely if abbreviations are used,
for example, running M-x fill-paragraph-semlf over:
#+begin_example
Hi there Chris! I see you've got your M.D. now so I suppose I should
call you Dr. Yoo. I hear you're also a newly appointed U.S. Rep., what
is that like? Good I hope.
#+end_example
Gets split to:
#+begin_example
Hi there Chris!
I see you've got your M.D.
now so I suppose I should call you Dr.
Yoo.
I hear you're also a newly appointed U.S.
Rep., what is that like?
Good I hope.
#+end_example
This is not correct, one would expect:
#+begin_example
Hi there Chris!
I see you've got your M.D. now so I suppose I should call you Dr. Yoo.
I hear you're also a newly appointed U.S. Rep., what is that like?
Good I hope.
#+end_example
I admit the example given here is intentionally (somewhat) contrived but
abbreviations like "Dr." are not uncommon and use of double-spaced
full-stops is absent from a majority of English which would probably
alleviate that problem.
I understand the work of finding a sentence here is done via
forward-sentence, perhaps inspiration from this prior art could help
find the end of sentences better:
(1) https://github.com/neurosnap/sentences
(2) https://github.com/diasks2/pragmatic_segmenter
I haven't looked into the exact techniques being used for those two
projects, and I am also unsure on how "serious" an "issue" this is
(hence just referring to it as 2c) but it would be an improvement to
correctly split (move forward by sentence) over natural language most of
the time I'd wager.
In any case still a good feature. One thing I had been planning to use
these kinds of things for is to semantically fill a large paragraph and
then more easily be able to rewrite or re-arrange thoughts (now they are
just one line per sentence). Once that's done, join lines back to a
paragraph and viola.
/Jordan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 21 Jun 2025 19:27:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 78561 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 22 Jun 2025 03:49:07 +0900
> From: Jordan Ellis Coppard <jc+o.emacs <at> wz.ht>
> Cc: bug-gnu-emacs <at> gnu.org
>
> My 2c here is that this seems rather basic and while the tests pass with
> toy lorem-ipsum language it fails completely if abbreviations are used,
> for example, running M-x fill-paragraph-semlf over:
>
> #+begin_example
> Hi there Chris! I see you've got your M.D. now so I suppose I should
> call you Dr. Yoo. I hear you're also a newly appointed U.S. Rep., what
> is that like? Good I hope.
> #+end_example
>
> Gets split to:
>
> #+begin_example
> Hi there Chris!
> I see you've got your M.D.
> now so I suppose I should call you Dr.
> Yoo.
> I hear you're also a newly appointed U.S.
> Rep., what is that like?
> Good I hope.
> #+end_example
>
> This is not correct, one would expect:
Do you have sentence-end-double-space set to nil? If yes, this is a
feature. If no, that's indeed a bug, since semantic linefeed should
not consider a single space after a period to be the end of a sentence
in that case.
Roi, could you take a look, please?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sat, 21 Jun 2025 19:58:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Do you have sentence-end-double-space set to nil? If yes, this is a
> feature. If no, that's indeed a bug, since semantic linefeed should
> not consider a single space after a period to be the end of a sentence
> in that case.
>
> Roi, could you take a look, please?
This is indeed related to the value of `sentence-end-double-space'.
When `sentence-end-double-space' is non-nil, `fill-paragraph-semlf'
produces:
Hi there Chris! I see you've got your M.D. now so I suppose I should
call you Dr. Yoo. I hear you're also a newly appointed U.S. Rep., what
is that like? Good I hope.
When `sentence-end-double-space' is nil, `fill-paragraph-semlf'
produces:
Hi there Chris!
I see you've got your M.D.
now so I suppose I should call you Dr.
Yoo.
I hear you're also a newly appointed U.S.
Rep., what is that like?
Good I hope.
Actually, there is a test for this. See
`fill-test-fill-paragraph-semlf-sentence-end-double-space'.
`fill-paragraph-semlf' uses `forward-sentence' internally to move
between sentences. So, IMHO dealing with more complex ways of finding
sentences is out of the scope of the semantic linefeed filling feature.
Roi
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Sun, 22 Jun 2025 06:46:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I think that `fill-region-as-paragraph-function' is a step in the right
>> direction. What is left is handling `use-hard-newlines'. Currently, Org
>> mode ignores it as the concept of hard newlines is not compatible with
>> Org mode syntax and its notion of paragraphs. So, we probably need to
>> have a way to bypass that branch in `fill-paragraph' or find some way to
>> handle hard newlines that is compatible with Org mode and then Emacs
>> introduce a new customization for Org to plug into.
>
> I don't understand: `use-hard-newlines` is nil by default and org mode
> doesn't seem to set it, so those users who set it ... get what they deserve?
"what they deserve" is not nice to users. There is some usefulness to a
proper Org-specific hard newline support. See
https://list.orgmode.org/orgmode/87pmftqkf1.fsf <at> gmail.com/
(specifically, item 2).
What i am asking about is providing some way in `fill-region' to control
how hard newlines are handled for major modes. Not just making it call
Roi's `fill-region-as-paragraph-function` instead of
`fill-region-as-paragraph'.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Tue, 24 Jun 2025 19:31:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>>> I think that `fill-region-as-paragraph-function' is a step in the right
>>> direction. What is left is handling `use-hard-newlines'. Currently, Org
>>> mode ignores it as the concept of hard newlines is not compatible with
>>> Org mode syntax and its notion of paragraphs. So, we probably need to
>>> have a way to bypass that branch in `fill-paragraph' or find some way to
>>> handle hard newlines that is compatible with Org mode and then Emacs
>>> introduce a new customization for Org to plug into.
>>
>> I don't understand: `use-hard-newlines` is nil by default and org mode
>> doesn't seem to set it, so those users who set it ... get what they deserve?
>
> "what they deserve" is not nice to users. There is some usefulness to a
> proper Org-specific hard newline support. See
> https://list.orgmode.org/orgmode/87pmftqkf1.fsf <at> gmail.com/
> (specifically, item 2).
I think I'm missing something. I'm probably thinking too simplistically.
In the first paragraph of yours above when you say "we probably need to
have a way to bypass that branch in `fill-paragraph'", I understand it
to mean that you need some way to tell the fill code to ignore
hard-newlines. And my reply was basically saying "well, there's
`use-hard-newline` for that".
If you want to pay attention to hard-newlines, yet also pay attention to
other "paragraph separator hints", then hopefully
`fill-paragraph-forward-function` can do the trick. E.g. I can't see
any reason why Org couldn't set `fill-paragraph-forward-function` to
a function which uses both regexps and the `hard` text-property to
determine paragraph boundaries.
[ I'm personally not convinced of the usefulness of hard-newlines by the
post above, but that OK: you don't need to convince me; I already
fully agree that the code should be flexible enough to let users use
hard-newlines (or any other trick they feel like using to indicate
that something should be treated as a paragraph boundary). I just
won't be one of those users. ]
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Fri, 27 Jun 2025 18:39:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 78561 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> If you want to pay attention to hard-newlines, yet also pay attention to
> other "paragraph separator hints", then hopefully
> `fill-paragraph-forward-function` can do the trick. E.g. I can't see
> any reason why Org couldn't set `fill-paragraph-forward-function` to
> a function which uses both regexps and the `hard` text-property to
> determine paragraph boundaries.
This is simple. fill-region has
(if use-hard-newlines
(progn ...)
(fill-forward-paragraph 1)
(setq end (min max (point)))
(fill-forward-paragraph -1))
So, `fill-forward-paragraph-function' is currently ignored when
use-hard-newlines is non-nil. With the proposed new
`fill-region-as-paragraph-function', it will still be ignored, AFAIU.
What I am asking is a way for major modes to customize boundaries even
when use-hard-newlines is non-nil.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78561; Package
emacs.
(Fri, 27 Jun 2025 20:28:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 78561 <at> debbugs.gnu.org (full text, mbox):
>> If you want to pay attention to hard-newlines, yet also pay attention to
>> other "paragraph separator hints", then hopefully
>> `fill-paragraph-forward-function` can do the trick. E.g. I can't see
>> any reason why Org couldn't set `fill-paragraph-forward-function` to
>> a function which uses both regexps and the `hard` text-property to
>> determine paragraph boundaries.
>
> This is simple. fill-region has
>
> (if use-hard-newlines
> (progn ...)
> (fill-forward-paragraph 1)
> (setq end (min max (point)))
> (fill-forward-paragraph -1))
>
> So, `fill-forward-paragraph-function' is currently ignored when
> use-hard-newlines is non-nil.
Duh, right.
> What I am asking is a way for major modes to customize boundaries even
> when use-hard-newlines is non-nil.
I have the impression that The Right Thing would be for `fill-region`
to always use `fill-forward-paragraph`, and then for the default value
of `fill-forward-paragraph` to check `use-hard-newlines`.
I haven't looked at the code to make sure The Right Thing is compatible
with The Real World, tho.
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 26 Jul 2025 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 17 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.