Split resdoc-b into its own package?

[seananderson]

The resdoc-b template adds substantial functionality, and although useful, it requires a large code base where most of it is not required by the rest of the original-style document types. This makes the code base for the original-style csasdown harder to maintain and I end up spending a lot of time debugging unit tests for this additional code base. I think somewhere around 60-70% of the codebase is currently for resdoc-b. In an experiment, I've already removed 53% of the lines of code while maintaining full functionality in resdoc, sr, techreport, and fsar. Simplifying the code would also make for fewer headaches on CRAN. Basically, I'm wondering if it makes sense to branch resdoc-b off into its own package.

One possibility is to keep it in a branch, but that's not as accessible to users. A branch would make it easier to pull in bug fixes, although a fork could have the same benefit. Maybe we could fork the current main branch, rename that fork, and then streamline the main branch here?

I'm not sure what a good name would be. csasdown.bilingual? Not sure that's great, but I'm struggling. Title rules: "(1) it may only contain numbers, letters, and periods; (2) it must start with a letter; and (3) it can't end in a period. This means package names cannot have hyphens or underscores."

ChatGPT had these suggestions:

• csasdown.enfr
• csasdual
• csasdown.b
• csasdown.dual
• csasfusion (kind of neat?)
• resdoc.b
• resdoc.fusion

Any thoughts on the approach and name @cgrandin? I can do the lifting to get them started.

[cgrandin]

@seananderson - Can this wait until I'm done with hake SOG? I have only a month to do this assessment and no time to have a possible broken package. I will be done the CSAS meeting by October 24 and would have some time then.

If you really need to do it now, I can just continue on the tagging branch for the next couple months, and you can work on a new branch prior to merging to main. Note that automatic PDF tagging will not work in the main branch. Also note that the tagging branch contains all the updates to make csasdown work with lualatex which we should be using anyway; remember I mentioned that many things (mostly link references) broke when moving to lualatex.

Issues with this - Any changes or improvements to csasdown will have to be done in two different packages in the future. e.g. if the style files are modified because some format is changed by CSAS. This means I would have to continually look at all commits for csasdown to make sure I don't miss anything.

[seananderson]

Yes, this can absolutely wait and maybe this isn't the right solution. Regarding changes to style files, there's no reason one package can't reference the files (e.g., the .sty and .tex files) and import functions from the other to avoid duplication and ease maintenance.