Re: [PATCH groff] tmac/hyphenex.en: add patterns for sequestrate & its derivates

[onf]

Hi Branden,

On Tue Dec 17, 2024 at 8:29 PM CET, G. Branden Robinson wrote:
> [...]
> (Did you hear that the Siberian traps appear to be roaring to life?[1]
> Many of us under the age of 60 can look forward to dying of heat stroke.)

Not really, but I know there are many places where the permafrost is melting,
so it doesn't surprise me. Frankly I don't read such news much; the little
I read every now and then is sad more than enough. I guess what's worst is
that all the purported solutions just result in more pollution and
environmental destruction without really solving anything (except for
income for those pushing them, obviously).

> > I am not sure about "sequestrated" and especially about
> > "sequestrating",
>
> I'm dubious about "sequestrate" itself, and therefore even more so of
> these derived forms.  One or two other cases exist of UK English getting
> carried away with reduplicative affixes on verbs, but I can't summon any
> to mind right now.  More common is the pointless suffixing of "-al" to
> "make" an adjective out of a word ending in "-ic" that _already is_ an
> adjective, like "ironical".  UK English just loves this form of
> morphologic excess.  I blame proximity to France.

It's funny because I would expect such stuff to come from American English
given how many of its speakers can't even distinguish between "its" and
"it's" or even "your" and "you're" :)

With that said, not being a native speaker, if I had to turn "sequestration"
into a verb, I would say "sequestrate" too and it would sound right to me...

> > I have modified your script into the following to be in line with the
> > way I set up hyphenation:
> >   #!/bin/sh
> >   printf '.mso %s.tmac\n.ll 1Z\n\\&%s\n' "$1" "$2" |
>
> One _Z_?  What _is_ this unit?  And why isn't the formatter complaining
> about it?

Oh well, that's what I get for trying to write something 'smart'
from memory. I was trying to get the `z` unit, but what I really
meant to say was this:
  .ll \n[.H]u

Anyway, you're right: groff complains if I say `1z`, but not when I say `1Z`.

> >     nroff -ww -Wbreak |
> >     sed -E '/^$/d' |
>
> `-E` is, I think, unnecessary here, since `^` and `$` as zero-width
> anchoring atoms are both valid POSIX BREs, not reserved to EREs.  FYI.

Frankly, I don't care. I have a habit of using -E on anything that doesn't
default to ERE, because the last thing I want is accidentally breaking a
working script by changing some regex in a way that makes it no longer work
with BRE and forgetting to add the -E flag.

In my mind, I always want ERE behavior, so I give it the -E flag.
Then I don't have to remember all the differences between the two
just to be able to tell when I need to add the flag. This can be
especially frustrating when GNU extends BRE to include ERE features
such as the `+` quantifier.

> > It hyphenates correctly, too:
> >   se‐ques‐tra‐tion
> > 
> > However, I have a file where hyphentation is setup like this:
> >   .mso en.tmac
> >   .de HY
> >   . hy 4
> >   ..
> > 
> > (the macro HY is used after .nh to re-enable hyphenation.)
>
> [...]
>
> > But when I put:
> >   .hw se-ques-tra-tion
> > after the above requests at the top of the document, it does.
> > 
> > I have no idea what might cause this behavior. Running groff with
> > -ww does not reveal anything hyphenation-related.
>
> I think something might be misconfigured in your installation.  :(

Yeah, my macros. (:

To expand on the very brief explanation I provided in my previous reply,
I had this:
  .so mac.tmac
  .mso en.tmac
  .de HY
  . hy 4
  ..

The mac.tmac file contains my version of the Mk macros, which setup
hyphenation parameters for Czech. The following lines override those
parameters with English ones.

Well, except Mk has this great property of initializing itself only
after you use one of its macros, so that the Czech hyphenation
parameters which I configured in Mk's init were loaded AFTER the
English ones, not before.

I fixed it for now by manually initializing Mk just after loading it.
I will likely get rid of this initialization behavior altogether in
the future.

~ onf