Hi @ibrahima,
the current page was not an anchor in previous versions, so what was the anchor_string in that version was not included in the current page markup. The successive refactoring made the current page an anchor without href, but continued to ignore it in the markup.

That's an inconsistency which should be considered a bug, so this issue is valid.

Your particular example is good for highlighting the inconsistent behavior, however using the anchor_string to add a class is probably not the best way to do it.

You can target the anchors with a CSS rule, and with the classes keyword argument, which is currently ignored in the simple pagy_nav (which is another inconsistency, hence a possible bug to be fixed)

Will fix ASAP.

92fd345 - all i did was add it in the markup for the anchor-string for the gaps and current pages.

Is this the correct approach?

I can easily do for the other nav helpers and add tests.

OK, so I finally had a bit of time to analyze the matter properly.

The main goal of the anchor_string is allowing to use data-* attributes. Its naming is generic enough so to cover any string that you may want to add to the actual page links, but that does not mean we should abuse it. Current page and gaps became disabled anchors only to get an easier and more consistent way to target them with CSS rules, but are actually NOT used as active page links.

Now, using anchor_string to target also the disabled links (that became links only to be consistently targeted by CSS rules) would make it technically consistent, but would add things that we don't need - exactly because now we can easily target them with CSS rules.

In conclusion the anchor_string seems better added only to the active links - as it was designed originally. That means that unless there is some request with a valid use-case that require the change, the code is fine as-is ATM.

On the other hand, the docs require changes to fix and clarify the matter.

Will do ASAP.

Thanks for looking into it!