Documentation (man/flac.md); fix typo

[Lee-Carre]

Section: Apodization functions § partial_tukey

From:

The use of this is that different parts of a block are ignored as the might contain transients which are hard to predict anyway. […]

to (emphasis added only in this summary, not in the source):

The use of this is that different parts of a block are ignored as they might contain transients which are hard to predict anyway. […]

---

FYI: I'm a Git newbie, so hopefully I've done this correctly.

[ktmf01]

Thanks!

FYI: I'm a Git newbie, so hopefully I've done this correctly.

Looks good to me. One thing I will fix for now which you could improve next time, is wrap the length of the commit message lines at 72 characters. So, instead of

> For partial_tukey(n) and punchout_tukey(n), […] The use of this is that different parts of a block are ignored as the might contain transients which are hard to predict anyway. […]

You could do

> For partial_tukey(n) and punchout_tukey(n), […] The use of this is
> that different parts of a block are ignored as the might contain
> transients which are hard to predict anyway. […]

But I'll fix that for now.

[Lee-Carre]

Looks good to me.

Thankyou.

wrap the length of the commit message lines at 72 characters

A hard-limit seems unwise, to me. Software should (at display-time) word-wrap based on the display environment, so that lines are a sensible length for everyone.

If there's a legit reason, significant enough to ignore sound accessibility & usability guidelines, then I'll consider it. A pointer to reading material would be fine.

If it's for a change-log, or similar, that has some excellent reason for a hard limit, then that could be implemented in software, too.

The downside to hard line lengths, is that if one has a wide display, then much more scrolling is involved. Letting their software display text how they want, keeps them in control of their own reading experience. Plus, it breaks the likes of grep when searching for multi-word phrases which span a hard line-break.

[ktmf01]

wrap the length of the commit message lines at 72 characters

A hard-limit seems unwise, to me. Software should (at display-time) word-wrap based on the display environment, so that lines are a sensible length for everyone.

I didn't invent it, that is the convention when working with git as far as I know. git doesn't do word wrap by itself.