This hyphenation exceptions log, as given by the hyphenex package, details cases in US English where the default TeX hyphenation is not correct. Examples include:
- codesigner is given as code-signer, when it should be co-designer;
- dataset is unhyphenated, but should be given as data-set;
- buzzword is given as buz-zword, when it should be buzz-word.
But there are pages and pages of these, and most for words that are in no way esoteric. (As it happens, when making this issue I encountered a word not listed on that list: coauthor should probably be co·author or and not coau·thor – so there are likely many more undocumented exceptions that exist.)
As a user, this goes against my expectations for how this library would behave. It is possible that people can configure individual words on a case-by-case basis, but I argue that this library should attempt to provide defaults that work in as many cases as possible, because we cannot expect the majority of users to know anything about hyphenation, especially not enough to configure it in such a fine-grained way.
Hence, I suggest that this library takes into account these exceptions (it is a public domain/very permissively-licensed list, so this should be no problem) by default. It’s possible it could allow disabling them with a feature flag, but to be honest I don’t see the use case for this.
This hyphenation exceptions log, as given by the hyphenex package, details cases in US English where the default TeX hyphenation is not correct. Examples include:
But there are pages and pages of these, and most for words that are in no way esoteric. (As it happens, when making this issue I encountered a word not listed on that list: coauthor should probably be co·author or and not coau·thor – so there are likely many more undocumented exceptions that exist.)
As a user, this goes against my expectations for how this library would behave. It is possible that people can configure individual words on a case-by-case basis, but I argue that this library should attempt to provide defaults that work in as many cases as possible, because we cannot expect the majority of users to know anything about hyphenation, especially not enough to configure it in such a fine-grained way.
Hence, I suggest that this library takes into account these exceptions (it is a public domain/very permissively-licensed list, so this should be no problem) by default. It’s possible it could allow disabling them with a feature flag, but to be honest I don’t see the use case for this.