Subject: bug#78561: [PATCH] Add semantic linefeed support for paragraph filling

From: Eli Zaretskii <[email-masked]>
Date: Sat, 24 May 2025 16:02:15 +0300

> From: Roi Martin <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Date: Sat, 24 May 2025 14:15:37 +0200
> 
> Eli Zaretskii <[email-masked]> 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.