Re: Warn on mid-input line sentence endings

[Alejandro Colomar]

Hi Branden,

On 4/30/23 02:05, G. Branden Robinson wrote:
> I should clarify a couple of points here since I was feeling grumpy when
> I wrote the following, and that made me forget things.
> 
> At 2023-04-27T09:45:40-0500, G. Branden Robinson wrote:
>> We're re-covering some familiar ground here.
>>
>> I have a few points I'd like to make.
>>
>> 1.  "Semantic newlines" is a terrible term.
> 
> I should have said "_Warn on_ semantic newlines" is a terrible
> instruction/summary.

That's why I used the phrase (at least I tried to do it consistently
recently) "warn on S. N. violations".

> 
> They are what we _don't_ want to warn about upon encountering them.
> 
> If man-pages(7) or other people continue to call the practice of
> breaking *roff input lines after sentence-ending punctuation "semantic
> newlines", I have no complaint.  It could also be called "Kernighan
> breaking", in honor of an early popularizer of the practice.

You could use it for the warning name ;).

> 
>> 2.  Bjarni's comment '"groff" is not the right tool for such things,
>>     but "grep" is.' is thoroughly wrong-headed and Ingo was right to
>>     reject it with great force.  Here a few reasons why.  I don't
>>     think any of B through D are relevant to mandoc(1) since it
>>     doesn't support the features in question (as far as I know).
>>
>>     A.  The formatter decides where sentence boundaries are based on
>>     its input.
>>
>>     B.  Use of the `cflags' request can change the characters that
>>     have sentence-ending semantics.  grep(1) cannot know this.
>>
>>     C.  Sentence-ending characters are subject to character
>>     translation (the `tr` request).  grep(1) cannot know this.
>>
>>     D.  The user/document could define a special character that is a
>>     sentence-ending character (with `char` and `cflags`).  grep(1)
>>     cannot know this.
> 
>       E.  Because '.', '?', and '!' are valid characters in *roff
>       identifiers, grep(1) can be fooled by special character, register,
>       or string interpolations in the input if their identifiers use
>       those characters.
> 
> Example:
> 
> I can't believe \*(I.  ate the whole thing.
> 
> It is only valid to detect the end of a sentence here if the (recursive)
> _expansion_ of the `I.` string ends with a sentence-ending punctuation
> character.
> 
> Further, since string interpolations can result in further string
> interpolations, a finite-state automaton will not suffice to analyze
> this input.  You need a stack machine.  (IIRC, a stack machine
> recognizes "recursively enumerable" languages.)
> 
> This is categorically not what regular expressions can cope with,
> formally.

Well, formally yes.  And a regex can't find C function definitions in a
source tree; at least if you try to fool it by writing the most horrible
code in the universe.  But I wrote a relatively small script[1] that
finds a lot of C code with pcre2grep(1), and works most of the time.  It
has limitations; some of which can be fixed by improving the regexes
(read: making them even more unreadable); some others are likely
impossible to fix with a regex.  The biggest limitation I think I've met
is K&R-style functions: I don't think a regex can cope with them.

I believe a regex-based script can be good enough for some purposes,
even if it's not perfect.

Cheers,
Alex

[1]:  <http://www.alejandro-colomar.es/src/alx/alx/grepc.git/tree/bin/grepc>

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

OpenPGP_signature
Description: OpenPGP digital signature