GNU bug report logs - #78561
[PATCH] Add semantic linefeed support for paragraph filling

Previous Next

Full log

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

From: Roi Martin <jroi.martin <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mbork <at> mbork.pl, monnier <at> iro.umontreal.ca, 78561 <at> debbugs.gnu.org
Subject: Re: bug#78561: [PATCH] Add semantic linefeed support for paragraph
 filling
Date: Sat, 24 May 2025 15:38:40 +0200

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!

Previous Next

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