`Name-sg`, `name-pl` and `Name-pl` required only if needed

[dbitouze]

Since:

1. the capitalized form of a name can be derived from the lowercase form thanks to \text_titlecase:n,
2. the plural form of a name is often (at least in English, in French, in Spanish and, AFAICS, in Portuguese) derived from the singular form by adding a final “s”,

it would be nice for zref-clever to guess from the lowercase singular form (name-sg) of a name what are its capitalized and plural forms (Name-sg, name-pl and Name-pl), and would require the user to explicitly specify the latter only if the two rules above don't give the expected result.

Here is a MCE illustrating the feature.

\documentclass{article}
\usepackage{zref-clever}
\newtheorem{myconjecture}{Conjecture}[section]
\ExplSyntaxOn
\tl_gset:Nn \__conjecture_name_sg_tl {conjecture}
\tl_gset:Nn \__conjecture_name_pl_tl {\__conjecture_name_sg_tl s}

\zcRefTypeSetup{myconjecture}{
  Name-sg = \text_titlecase:n{\__conjecture_name_sg_tl} ,
  name-sg = \__conjecture_name_sg_tl ,
  Name-pl = \text_titlecase:n{\__conjecture_name_pl_tl} ,
  name-pl = \__conjecture_name_pl_tl ,
}
\ExplSyntaxOff
\begin{document}
\section{Section 1}
\begin{myconjecture}\zlabel{conjecture-1}
A conjecture.
\end{myconjecture}
\begin{myconjecture}\zlabel{conjecture-2}
A conjecture.
\end{myconjecture}
\begin{itemize}
\item \zcref[cap]{conjecture-1} and \zcref{conjecture-1,conjecture-2}.
\item \zcref[cap]{conjecture-1,conjecture-2} and \zcref{conjecture-1}.
\end{itemize}
\end{document}

[gusbrs]

Hi @dbitouze , thanks for the suggestions. I did consider both of them during development, and I think the choices I then made are still sound.

Let me start with the clearer case:

2. the plural form of a name is often (at least in English, in French, in Spanish and, AFAICS, in Portuguese) derived from the singular form by adding a final “s”,

The key word here is "often". Not even in English it is safe to generate a plural just by appending an "s". And the rules are language dependent, typically less regular than English.

And the result of trying to automate this is that zref-clever would "think" it knows the plural when it doesn't, so instead of getting a warning if something is amiss, just appending an "s" could potentially generate straight out wrong results, and quietly so.

So, there's no way I'm venturing in these waters. Plurals must be given explicitly.

1. the capitalized form of a name can be derived from the lowercase form thanks to \text_titlecase:n,

Here there is a trade-off. The casing macros are safer, but not completely safe, depending on the content of the argument. So I went with a known redundancy to be sure we are not tripped by the casing macros. I think that call still stands.

Besides, I expect the language files to cover most use cases. And the cost of doing it once there is pretty small, I'd say. And we get a cleaner infrastructure in exchange. So far, in your experience, are you actually needing to set a large amount of custom types?

[dbitouze]

Hi @gusbrs, and sorry for the delay!

2. the plural form of a name is often (at least in English, in French, in Spanish and, AFAICS, in Portuguese) derived from the singular form by adding a final “s”,

The key word here is "often". Not even in English it is safe to generate a plural just by appending an "s". And the rules are language dependent, typically less regular than English.

And the result of trying to automate this is that zref-clever would "think" it knows the plural when it doesn't, so instead of getting a warning if something is amiss, just appending an "s" could potentially generate straight out wrong results, and quietly so.

Indeed but, IMHO, it's not that serious. BTW, the glossaries-extra (and glossaries) and acro packages use an “s” by default for plurals.

So, there's no way I'm venturing in these waters. Plurals must be given explicitly.

Too bad! :wink:

1. the capitalized form of a name can be derived from the lowercase form thanks to \text_titlecase:n,

Here there is a trade-off. The casing macros are safer, but not completely safe, depending on the content of the argument. So I went with a known redundancy to be sure we are not tripped by the casing macros. I think that call still stands.

But the LaTeX team took care to avoid any trap with case macros (see p. 275 of interface3.pdf).

Besides, I expect the language files to cover most use cases. And the cost of doing it once there is pretty small, I'd say. And we get a cleaner infrastructure in exchange. So far, in your experience, are you actually needing to set a large amount of custom types?

Indeed, no. But I'm working on a LaTeX class that will be used by LaTeX beginners who can define their own “theorems”, thanks to a redefinition on my part of the "newtheorem" command that relies on a key-value interface. And I would like to minimize the "fields" that these users will have to fill in.

[gusbrs]

Hi @dbitouze !

BTW, the glossaries-extra (and glossaries) and acro packages use an “s” by default for plurals.

I know but, imho, not the best choice. Also, the cases are different. I'd expect all glossary terms / acronyms to be user defined, while for reference types we can easily provide the common cases, and only the exceptions need to be provided by the user. So the value of this feature is higher for glossaries(-extra) and acro. (I'm still not sure it's worth it, but it's not my call).

But the LaTeX team took care to avoid any trap with case macros (see p. 275 of interface3.pdf).

I've been following this from afar and I'm aware things have improved in this area in the kernel. But I think "avoid any trap" is an optimistic assessment, the problem is notoriously difficult. Granted, as far as I know, things should be pretty solid. Still, it is an added complexity.

There are also some technical complications on zref-clever's side. zref-clever is not very typical in option handling. Instead of the traditional "last set value is used", zref-clever works with four option scopes (general, type-specific, language and type specific, and language specific defaults, plus a fifth internal fallback), and there is a precedence rule which decides which one prevails. This is done at typesetting time, or rather while the reference is being processed, and whether the lower levels get the chance depends on if the higher precedence ones are set or not. I'm not sure it was the wisest decision I've made, but it was done on behalf of user flexibility. Anyway, during initial development I actually did try to derive the capitalized names from the regular ones, but it complicated the precedence level handling. After all, at a given level, if the capitalized version is missing, should I go to the next level, of "fill it in"? I could make this change at the time the option is set, but it's the same thing in the end, the precedence for each option scope will be tripped, since the higher level may prevail for a given option, even when it was not set.

Indeed, no. But I'm working on a LaTeX class that will be used by LaTeX beginners who can define their own “theorems”, thanks to a redefinition on my part of the "newtheorem" command that relies on a key-value interface. And I would like to minimize the "fields" that these users will have to fill in.

I'm happy to hear that. But it's the same thing for users in general, isn't it? zref-clever already offers theorem, lemma, corollary, proposition, definition, proof, result, remark, example, exercise, and solution for "theorem-like" environments. I hope this covers a good number of the most frequent use cases, for which the user doesn't need to set any names. For other cases, yes, they typically need to fill in four. If they use cap, or a language which sets allcaps, they may get away with two. If they require abbreviations, they may need to provide a full set of 8. However, whatever the case may be, it is always clear what option was set or not, it is also always clear if a name is missing, generating a corresponding warning. We are also sure never to automatically provide a wrong form which, if it occurred, would happen silently.

All in all, I'm still not convinced the added convenience -- which, granted, exists, but in my view is small -- is worth the added complexity.

[dbitouze]

OK, thanks for you nice and detailed answers! :smile: