You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there,
first of all, thanks for this! After some research, I think this extension would be what I'm looking for, but I did encounter 2 issues for my use case (also found in yafg):
stripping the title results in a KeyError if no title is specified
if I don't strip the title, i got a "Figure 1: None" caption.
I would like to do a PR for this, but I was wondering what are your plans for this project...
do you intend to continue/resume the development or should I start a new, independent, fork?
which is the best branch/commit to continue your work? I see that ContentHack branch is ahead of the others, but I has many failing tests. Are they bugs to squash or there's some missing functionality still to implement?
The ContentHack branch was working towards my vision of allowing a configurable caption for any content based on the original concept. I refactored the code so it made more sense in that context. Unfortunately, my python OOP skills are inadequate and I've stalled.
iirc:
I understand a superclass is needed once the content type is determined but I couldn't figure it out
two lines are written in the wrong order for tables
Of course if it worked then tests would be needed.
Any PR to resolve these or any other issues would be welcome.
OK, now I understand what you tried to do, and while my PR fixes all the tests, they aren't really good from an OOP perspective. But at least we now know that it works and that a refactor should always pass the tests.
We can make the various content types subclasses of the CaptionTreeprocessor and register each one in the extendMarkdown method, so that the parent class only has common code and the children only have specialized code.
I would gladly help you do this, let me know if you want to merge the current PR first or if it's ok to go all in with the overhaul.
PS: I already did some more refactorings, mainly to make it more compliant with the google style guide (variable/method/class naming) and to switch to pytest (just a personal preference, it avoids keeping a useless class around), but let's take it one step at a time 😉
Activity
flywire commentedon Jan 25, 2023
The ContentHack branch was working towards my vision of allowing a configurable caption for any content based on the original concept. I refactored the code so it made more sense in that context. Unfortunately, my python OOP skills are inadequate and I've stalled.
iirc:
Of course if it worked then tests would be needed.
Any PR to resolve these or any other issues would be welcome.
sanzoghenzo commentedon Jan 25, 2023
That's wonderful to hear (well, read 😅 )!
OK, now I understand what you tried to do, and while my PR fixes all the tests, they aren't really good from an OOP perspective. But at least we now know that it works and that a refactor should always pass the tests.
We can make the various content types subclasses of the
CaptionTreeprocessorand register each one in theextendMarkdownmethod, so that the parent class only has common code and the children only have specialized code.I would gladly help you do this, let me know if you want to merge the current PR first or if it's ok to go all in with the overhaul.
PS: I already did some more refactorings, mainly to make it more compliant with the google style guide (variable/method/class naming) and to switch to pytest (just a personal preference, it avoids keeping a useless class around), but let's take it one step at a time 😉
hendrikp commentedon Mar 4, 2023
Small note in the wiki on page https://github.com/flywire/caption/wiki/Development#unittest
the line
python -m unittest -v test_caption.captionTestCaseshould be replaced by
pytest --covAs the testing framework was changed.