single option does not take barriers into account

[cgnieder]

Original report by bers (Bitbucket: bersbersbers, GitHub: bersbersbers).

---

See this example:

\documentclass{article}
\usepackage[single,use-barriers,reset-at-barriers]{acro}
\DeclareAcronym{SB}{short=SB, long=some bug}
\begin{document}
    \ac{SB}, this should not print "(SB)"

    \acbarrier Here's a barrier!

    \ac{SB}, \ac{SB}, this looks correct
\end{document}

This outputs:

some bug (SB), this should not print ”(SB)”
Here’s a barrier!
some bug (SB), SB, this looks correct

In my opinion, the single use of SB before the barrier should not print "(SB)".

I want to use a barrier to have an isolated part of my document (the abstract), in which I use the same acro definitions, but do not want to see "(SB)" if "some bug" is used twice in the document, but only once in the abstract.

[cgnieder]

Original comment by Clemens Niederberger (Bitbucket: cgnieder, GitHub: cgnieder).

---

the barrier command does not influence the single option at all. In the example you give, sb is used three times and the document looks exactly as I would expect it to look. The barrier is only meant to produce local lists…

[cgnieder]

Original comment by Clemens Niederberger (Bitbucket: cgnieder, GitHub: cgnieder).

---

This is not a bug but the expected behaviour

[cgnieder]

Original comment by Nick (Bitbucket: makf1127, GitHub: makf1127).

---

Sorry to dig up a closed thread. Is it possible to produce the behavior that the OP asked about?

I understand that behavior described isn’t a bug, but it would be nice to have a “barrier respecting” variant of the single option. For example, in a long document with multiple chapters, one may wish to have self contained acronyms in each chapter. A chapter that uses the acronym multiple times should define it (i.e. produce “long name (short name)”), but a chapter that uses it only once should use the single style output.

[cgnieder]

Original comment by Clemens Niederberger (Bitbucket: cgnieder, GitHub: cgnieder).

---

I understand the reasoning. I cannot predict when I will find the time to look into this, though, because it may not be quite so trivial to implement…

[cgnieder]

This is implemented in version 3.0.