Spurious comma with authortitle style and \textcite

[dbitouze]

Since biblatex 3.4, authortitle style and \textcite leads a spurious comma between the author(s) name(s) and the title. For instance, the following MWE:

\documentclass{article}
\usepackage[style=authortitle]{biblatex}%
%
\addbibresource{biblatex-examples.bib}
%
\begin{document}
\textcite{knuth:ct:a}
\end{document}

leads to:

Knuth, (TEXbook)

whereas, as shown here, it used to lead to:

Knuth (TEXbook)

(until to biblatex 3.3).

[moewew]

This is because in 8bf55f2 following #363 the \textcite commands were changed to use \nametitledelim\bibopenparen instead of \addspace\bibopenparen, this can cause problems if \nametitledelim contains anything other than a space. We already have \extpostnotedelim so that should probably be used here (and renamed?)

[u-fischer]

@moewew I'm not sure if a new command is the solution. It can get confusing if one has a \nametitledelimbib and \nametitledelimtextcite and more variants.

"nametitledelim" is a clear name and if would a pity if one couldn't use it in all places where is makes sense. Imho one should ponder over a more generic solution. Perhaps one could define a test which allows to check if one is in a bib, or a textcite or a parencite so that one could do something like this:

\renewcommand\nametitledelim{\ifin{textcite}{\addspace}{\addspace\addcomma}}

Another idea would be a hook in the precode of a cite command so that one can add specific redefinitions.

Or one could write something like this

\DeclarePunctuationFormat[textcite,parencite]{nametitledelim}{\addspace}
\DeclarePunctuationFormat[bib]{nametitledelim}{\addperiod}

and then use \printpunct{nametitledelim}. (But I'm not sure if it is a good idea to extend the Formatsystem from entrytypes to "citetypes". Perhaps it will confuse everyone ...).

[moewew]

Of course it has downsides having that many names. But is a situation with "Name_ Title" really the same as "Name_ (Title)", does the "_" really separate the name and the title in both cases, or is there something more to it in the second case? \textcite often needs a bit more work than other cite commands, case in point: \textcitedelim, textcitecount, textcite:postnote; so I don't think we would be going completely off the rails here. (Of course I take more macros over hard-coded delimiters any time.)

I'm not very fond of overloading simple punctuation commands with checks. Those constructions become unappealingly long and then confusing quite quickly. Your second idea (though very similar, I admit) looks more appealing to me. Implementing it is a different story then ...

[plk]

I'm open to this if someone wants to fork and try it? For 3.4, do we need to fix something though?

[moewew]

I think the current situation is definitely undesirable and should be fixed, a comma before the brackets looks just wrong. Whether that is by reverting the \addspace\bibopenparen fix or by implementing another solution is up to you.

I would say that introducing a new command (or re-using \extpostnotedelim) is probably not going to cause lots of damage.

I'm sorry, I pressed the wrong button and inadvertently "closed" the issue.

[plk]

How about auto-generating some variants of all these delim macros like:

\textcite*delim
\parencite*delim
\cite*delim (which is the default for all \*cite*delim)
\bib*delim

and they all default to the corresponding untyped \*delim.

[dbitouze]

I think the current situation is definitely undesirable and should be fixed, a comma before the brackets looks just wrong.

I fully agree.

[plk]

Ok, looking at it, tracking in #363

[plk]

(tracking on here so @u-fischer can see it). Here is a suggestion. In the table, by default, any macro with no explicit value uses the value from the "upstream" more general macro. Any suggestions for defaults welcome. @moewew ,@u-fischer - would like your opinion here too.

\nameyeardelim                   \addspace
  \bibnameyeardelim
  \citenameyeardelim
    \textcitenameyeardelim
    \parencitenameyeardelim
    \footcitenameyeardelim
\nametitledelim                  \addcomma\space
  \bibnametitledelim
  \citenametitledelim            \addspace
    \textcitenametitledelim
    \parencitenametitledelim
    \footcitenametitledelim
\extpostnotedelim                \addspace
  \bibextpostnotedelim
  \citeextpostnotedelim
    \textciteextpostnotedelim
    \parenciteextpostnotedelim
    \footciteextpostnotedelim
\postnotedelim                   \addcomma\space
  \bibpostnotedelim
  \citepostnotedelim
    \textcitepostnotedelim
    \parencitepostnotedelim
    \footcitepostnotedelim
\prenotedelim                    \addspace
  \bibprenotedelim
  \citeprenotedelim
    \textciteprenotedelim
    \parenciteprenotedelim
    \footciteprenotedelim
\nonameyeardelim                 \addspace
  \bibnonameyeardelim
  \citenonameyeardelim
    \textcitenonameyeardelim
    \parencitenonameyeardelim
    \footcitenonameyeardelim

[plk]

I'm thinking of doing something like this:

\printdelim{textcitenameyeardelim}

where this falls back on progressively generic delim macros: \citenameyeardelim and then \nameyeardelim etc. The fallbacks would be as in the list above. That way, if a more specific delim context macro isn't defined, it picks up the next more general one. This should fix the issue in a more general way. Comments?

[moewew]

You should be much more interested in @u-fischer's opinion and expertise than my opinion here. But for what it's worth, I am quite fond of the old \setunit{...} syntax. I think short-term it would be enough to have just \nameyeardelim, \nametitledelim, \postnotedelim, \extpostnotedelim, \prenotedelim and some \textinfodelim (mhhh, yes I know, but we can't call it \textcitedelim) and we are good to go.

I fail to understand what \bibpostnotedelim would be good for. Would \bibnametitledelim replace \labelnamepunct? And could \bibnameyeardelim used instead of the now hard-coded delimiters in the authoryear-* bibliography styles?

As a long-term solution your idea sounds very interesting, I believe. It will take the name thing to the next level, though (footciteextpostnotedelim).

[plk]

Not all of these delim names are "real" - it's just easier to make a loop to auto-create a hierarchical tree of delims which inherit downwards. The strange ones you mention wouldn't be advertised to users or used at all. \setunit is perhaps fine but it wouldn't do inheritance. The \printdelim would be optional of course, only if you wanted the inheritance functionality - I would probably use it in the standard styles and document it. Could even provide a user-level macro for constructing arbitrary delimiter hierarchies.

[u-fischer]

I like the idea of a \printdelim command. But I'm not sure about longer predefined chains. I'm not sure that all cases can really be represented by tree hierarchies and I fear that it gets to complicated. If I had to define say three different nameyeardelims (space, dot, comma) I would probably set \nameyeardelim to the most used and define for all the other a special case, and not try to use some intermediate command. So I think I would prefer \printdelim[textcite]{nameyeardelim} which would use either \nameyeardelim or \textcitenameyeardelim.

[plk]

Yes, the tree thing is a bit much I think. Ok I see your solution basically defines the fallbacks dynamically from the optional argument. I think that's nicer overall and doesn't rely on hard-coded naming conventions. I'll do a test implementation of such a solution in DEV soon.

[u-fischer]

One could perhaps have also a command \DeclareDelimFormat[textcite]{nameyeardelim}{code}, then \printdelim could use some internal commands (e.g. \delim@nameyeardelim) and would be independant of the existing commands. (But I haven't really tried to think this through, I'm a bit in a hurry, so it could be nonsense).

[plk]

I was also thinking of something like \DeclareDelim so that there is less clutter in the actual calls. The fallbacks are declared in the \DeclareDelim and then the user only has to do \printdelim{foo} rather than specify the fallbacks at use time with \printdelim[bar]{foo}. This solution also makes the general delimiter setup much easier to see in one place rather than having to look through the actual code used to print things.

[u-fischer]

If you allow only \printdelim{foo} then how will you make possible that \printdelim{foo} gives in a \cite something different then in a \textcite (without going back to some hardcoded chains)? Imho the variants \printdelim{foo} (try only the delim "foo@delim" associated with foo) and \printdelim[bar]{foo} (try first "barfoo@delim", then "foo@delim") is clearer.

[plk]

Ok, this is a different issue - do we want to have context-sensitive detection of delims? That is, detect we are in \cite as opposed to \textcite and act accordingly? That's harder.

[plk]

Here is something concrete to think about which I have working at the moment:

\DeclareDelimiter[delim2]{delim1}{X}
\printdelim{delim1}\printdelim{delim2}

prints XX

This way, there can be arbitrary fallbacks defined for any delim. You don't have to use \printdelim and can access the delims as normal but if you do use it, it follows the fallbacks defined with \DeclareDelimiter. I also think it's better to not concat delim names and make it more general - you spell out completely the delim names.

[u-fischer]

Hm. I think I'm loosing you. What do you gain by the "fallback" delim2? Where is the difference to

\DeclareDelimiter{delim2,delim1}{X}
\printdelim{delim1}\printdelim{delim2}

where both delim2 are at the same level?

Ok, this is a different issue - do we want to have context-sensitive detection of delims? That is, detect we are in \cite as opposed to \textcite and act accordingly? That's harder.

I don't think that it is hard: A cite command would only need to save its own command name somehow, so that is can (inside the cite) be accessed e.g. as "\citetype". Or one could declare the citetype in the precode.

It is another question if we want it and should do it. It has some attraction. \DeclareDelimFormat[textcite,parencite]{nameyeardelim}{<code>} would then be very similar to \DeclareFieldFormat[article,book]{title}{..}. On the other side it looks like a lot of code for a bit of punctuation, and as I wrote above I'm not sure that it will not confuse people.

[plk]

The difference was that \printdelim{delim2} would still print X even though undefined, as it falls back on delim1. But perhaps this is off the point - I am coming round to the idea of a flat structure with context sensitivity, as you say - I think this is less confusing. So, to summarise, the solution would involve:

• Something like \blx@delimcontext (\citetype doesn't cover delims in bibs, shorthand lists etc.)
• Defaults for this in \DeclareCitationCommand, \printbibliography and \printbiblist
• \printdelim with no optional arg uses the context default, with optional arg some other context setting

[plk]

Here is a quick test implementation output:

\def\blx@delimcontext{none}
\DeclareDelimFormat{delima,delimb}{X}
\DeclareDelimFormat[textcite]{delima,delimb}{Y}
\DeclareDelimFormat[parencite,footcite]{delima,delimb}{W}
\DeclareDelimFormat[parencite]{delima}{Z}

\printdelim{delima},\printdelim{delimb}

\def\blx@delimcontext{textcite}

\printdelim{delima},\printdelim{delimb}

\def\blx@delimcontext{footcite}

\printdelim{delima},\printdelim{delimb}

\printdelim[parencite]{delima},\printdelim{delimb}

\printdelim[parencite]{delimc}

\renewcommand*{\delima}{A}%
\delima,\printdelim{delima}

\def\blx@delimcontext{none}
\delima,\printdelim{delima}

Output is

LaTeX Warning: Delimiter 'delima' for context 'parencite' already defined,
overwriting on input line 46.
LaTeX Warning: Delimiter 'delimc' for context 'parencite' undefined on input line 58.

X,X
Y,Y
W,W
Z,W
A,W
A,A

The thought here is that definitions/use with no context option should define the plain macros people are used to so that the usual ways of defining/using delimiters interacts with this setup when there is no context option, because that's a new concept. How does this look?

[plk]

3.4 dev version has a relatively complete implementation with documentation (section 3.9.2) and a test file (04-delimiters). I have just corrected the one nametitledelim case with this interface and it seems fine with biber and bibtex backends. Would be grateful if you could review the documentation section and example file. Thanks to @u-fischer - this was a much cleaner idea and it can be used together with the existing interface. @moewew - this works with \setunit - see the authortitle .bbx files. You can also do some interesting things by redefining normal macros like \x as \printdelim{x} and then declaring suitable \DeclareDelimFormat definitions. See the 04-delimiters.tex file for examples of how to use the automatically created bibliography delimiter contexts and how to override these with hooks.

[moewew]

I just played around with this new feature and I am really impressed. Especially because from what I gathered it retains backwards compatibility with the "old" way of doing things, which is quite important as those redefinitions are quite common.

Would it make sense to have a starred \DeclareDelimFormat analogous to \DeclareFieldFormat* et al.?
In the light of josephwright's plans in #375, would it make sense to merge the biblist and shorthands contexts?

I think nameyeardelim (in the bib version) could also be deployed to authoryear.bbx's name-year bibliography macros. I'm dubious whether nametitledelim should be used instead of \labelnamepunct in standard.bbx. The name strongly suggests it is appropriate there, but \labelnamepunct is quite widespread, so

\DeclareDelimFormat[bib]{nametitledelim}{\labelnamepunct}

could be an option.

Finally and unimportantly, in the doc section in this new feature it says "nomatter", could there a space missing?

[moewew]

Great. While I was playing around with that, I noticed that context nesting works only with two levels, if the commands are nested deeper only the second-to-last level is restored. Could that ever be a problem?

[plk]

Hmm, I think it will depend on how the nesting is done and where the \restoredelimcontexts are called - do you have an example?

[moewew]

Check out

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[style=authoryear,backend=biber]{biblatex}

\addbibresource{biblatex-examples.bib}

\begin{document}
\cite{sigfridsson}\makeatletter\blx@delimcontext\makeatother

\fullcite{sigfridsson}\makeatletter\blx@delimcontext\makeatother
\end{document}

after \cite we get back "none", while after \fullcite we're still in the "footcite" context (because we went one level deeper with "bib" in \usederiver and then could only restore back to "fullcite").
In \usedriver the global assignment of \blx@delimcontext is not needed, I think, maybe we can get around that...

[plk]

Ah, of course, well spotted. The context saving needs to use a stack now that we have delim context switching in \usedriver. Looking at it.

[moewew]

Maybe we can get around that entirely by keeping the \delimcontexts within groups. It seems to me as though almost all of those could be moved inside groups (I'm not sure about the citation one in the precode ...).

[plk]

In general I agree but keeping track of groups is usually just asking for bugs in a project this size ... I'll have a look though.

[moewew]

Yes, it would probably work fine up to the citation commands where I lost track, but that is the important bit, so ...

[plk]

That may not be so hard because the pre/post code expansions are all in \citeprint. Just testing a group based fix now.

[plk]

Try it now - test docs are identical and your problematic case works now.

[moewew]

Looks good. Thank you.

I'm just wondering, do we we need \restoredelimcontext and \blx@delimcontext@saved now everything is local? I just did \renewcommand*{\restoredelimcontext}{\empty} and things seem to work just fine.

[plk]

Yes, that's next on the list ... however, it might still be useful for users in some circumstances at the document level, with custom contexts.

[plk]

Actually, you're right, this would just be confusing unless it were global in which case it would be even more confusing. I have removed it completely and tests are fine. 3.4 is updated.

[tommarcoen]

I wanted to use the latest dev verison of biblatex so as to have a fix for this issue so I cloned the repo and did a build.sh install. However, now I get the following warning when running biber:

WARN - Warning: Found biblatex control file version 3.1, expected version 3.0

After a bit of googling, I discovered that I have to update biber but I'm already running the latest version (2.4). Any ideas?

[plk]

Usually, the DEV version of biblatex requires the DEV version of biber and in this case that is version 2.5 which is also on Sourceforge.

[tommarcoen]

Makes perfect sense. Now it does work. Apologies for asking stupid questions.

[plk]

No problem.

[moewew]

Would it make sense to add the default

\DeclareDelimFormat[textcite]{nameyeardelim}{\addspace}
\DeclareDelimFormat[textcite]{nonameyeardelim}{\addspace}

to the .def files?

What about \DeclareDelimFormat[biblist]{nonameyeardelim}{\addspace}?

[plk]

Well, they are covered already by the defaults without contexts:

\DeclareDelimFormat{nameyeardelim}{\addspace}
\DeclareDelimFormat{nonameyeardelim}{\addspace}

[moewew]

Yes they are in a way. It is just that changing to \DeclareDelimFormat{nameyeardelim}{\addcomma\space} leads to the comma also appearing in \textcite. We could restore pre-3.3 behaviour if we give the space for \textcite explicitly.

[plk]

Ok, perhaps that's better but it might be confusing for people who set \DeclareDelimFormat{nameyeardelim}{\something} and want/expect it to set all the contexts.

[moewew]

You are right there. Either solution has its drawbacks, I'd prefer to keep backwards compatibility by setting the textcite context explicitly, that way changing \nameyeardelim the old way gives exactly the results it did before 3.3. But I can see that it could be confusing, I would however argue that users that know about the new scheme will have learned how it works from somewhere and I assume the defaults would be documented there as well.

[mschnetzer]

Hi, sorry to comment on the closed issue. I still have the "comma-problem" with the citestyle authoryear-icomp - no problem with simple authoryear. Any help appreciated (warning: i'm not really into coding). Perhaps you could fix that in the next update? Thanks a lot for your effort!

[moewew]

@smanull I have a hunch that your problem is essentially #432. Please check the solution in the linked TeX.SX question (or test the dev version where the problem should have been resolved). If that does not resolve your problem, please consider posting a proper minimal working example that we can investigate.

[mschnetzer]

@moewew Thank you so much for your fast answer, that really solved the problem. For everyone else searching for the solution and ends up here: include \DeclareDelimFormat[cbx@textcite]{nameyeardelim}{\addspace} in your preamble! Probably sometime it will be "built-in" and this line becomes obsolete ;)

[moewew]

@smanull The issue should be fixed in the upcoming version 3.5 (not yet released to CTAN, but available here and on sourceforge) with not exactly the same line but a new mechanism to that effect.

So with versions >= 3.5 that line should not be needed any more.