GNU bug report logs -
#78561
[PATCH] Add semantic linefeed support for paragraph filling
Previous Next
Full log
View this message in rfc822 format
> 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.
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.