Closed moewew closed 6 years ago
Is this a typo: DeclareOuterCitdeDelims
instead of DeclareOuterCiteDelims
?
Well, as far as I can tell, renaming isnt as bad as it seems especially when you have a fall back with full functionality. And therefor there is a changelog to read about these things.
Ooops, yes indeed thanks. I might be indecisive and fickle when it comes to naming things, but I'd like to think that I'm not totally bonkers ;-)
You are not at all! And you document everything very well!
btw -\DeclareOuterCiteDelim
didnt confuse me but I see your point using plural form here.
First attempt is at https://github.com/moewew/biblatex-ext/commit/8956df8b602c2670a8b1c2abcdfcc64660193534. I also went ahead and renamed two internal cite commands. Unfortunately there I can't implement full backwards compatibility. So I should probably get out the update quickly to avoid old code spreading (I doubt a lot of people use it ... yet).
I think biblatex-ext
will succeed – sooner or later: I already had in mind to refactoring archaeologie
building upon ext-authoryear
.
One question, since this issue is about (re)naming conventions: we did you choose to call the styles ext-...
instead of ...-ext
(as in biblatex-ext
) you could have named it ext-biblatex
as well?
You might want to wait using this style as base for heavily customised styles until the internals have settled. Not sure when that would be. Given that people seem to use the style already (https://tex.stackexchange.com/q/435664/35864) I'm not even sure I can get away with renaming the internal cite macros as planned...
I chose biblatex-ext
as name for the style to conform with the package names of most other contributed styles (biblatex-chem
, biblatex-apa
, biblatex-chicago
, ...). But I found it easier to have the ext-
as prefix for style names, so it is immediately obvious an ext
style is used. That information might get lost if it's at the end, especially with styles that already have an -
in their name authoryear-icomp-ext
. Plus I can say git add ext-*
and all all files at the same time...
Even more renaming results in https://github.com/moewew/biblatex-ext/compare/renamedelim
Now with detection of old bbx:introcite
names. No attempt is made to salvage things, but users are warned of the old names.
There is https://github.com/moewew/biblatex-ext/pull/11 now which will probably be merged later today so I can get an update out before tonight.
The update went out to CTAN just now and should become available during the next few days. Fingers crossed that I don't break people's documents and upset too many people.
I am curious how much I need to change with the styles I built so far upon biblatex-ext
with the renaming :)
I sincerely hope not that many. https://github.com/LukasCBossert/biblatex-socialscienceshuberlin should be fine (at least on first glance).
I assume the only potentially breaking change is bbx:introcite
->bbx@introcite
, and there you should at least get a handy warning.
\bbx@xrefcite
is probably not modified by many styles and so I don't see it as that problematic even though there is no backwards compatibility there.
All other changes should be fully backwards compatible, but they only apply to citexref
and the \Declare...CiteDelims
.
great. there is another style (not public yet) for which I used biblatex-ext
but I didn’t modify citexref
and \Declare...CiteDelims
- so I think it should be fine then (or the backwards compatibility will take care of it).
We shall see. You know where to complain...
I won’t complain - just asking for guidance and help then :)
v0.4 with the name changes is out and in TeX live and MikTeX as of today. So I'm closing this for now.
I always knew there would be the risk of me disliking a command name I have chosen. Now it has come to that...
Somehow I feel
\DeclareOuterCiteDelims
withs
would be more natural. I suppose it would be easy enough to change to the new name and add a deprecation notice for the old name while retaining full functionality. Question is if at all and when these changes should happen. I'd look a right pillock if I go around changing names willy-nilly every release (especially of user-facing macros...).