Closed falquaddoomi closed 1 year ago
We may also want a way to specify a specific section or paragraph "non-destructively" and rapidly. That is, be able to specify it conveniently from the command line or GitHub Actions, without having to make a new commit with changes to the markdown. Perhaps this could just be a regex that finds the first (or any?) paragraph that matches.
@falquaddoomi feel free to remove the "Original text" from the issue description since the problem is well described in the text you added.
I like the idea of using the template here for issues that were just decided to go to "In progress" after an iteration planning meeting: having a "Problem" and a "Proposed solutions" sections. And maybe also a "Description editor" section with the person responsible for editing the description as the issue and solution are polished. Then we discuss/comment here, as @vincerubinetti did, and the "Description editor" (there must be a better name for this) updates it accordingly.
We may also want a way to specify a specific section or paragraph "non-destructively" and rapidly. That is, be able to specify it conveniently from the command line or GitHub Actions, without having to make a new commit with changes to the markdown. Perhaps this could just be a regex that finds the first paragraph that matches.
I think this sounds great for revising, for instance, a single paragraph inside a file that belongs to a section. It could also be interesting to specify several paragraphs by specifying a list with their first words. In this issue, however, the goal I thought was to map files to manuscript sections (or "section types" to use the same vocabulary), and that should be a one-time change in the lifecycle of a manuscript (e.g., 01.introduction.md
will always be the introduction). If I'm not mistaken, what you suggest could be a great feature in another issue. But let me know if you meant something else.
I wonder if we should change the title of this issue to something like "Add support to map Markdown files to manuscript section types" or something like that.
We think we should go with a YAML config file for now, and possibly have it include support for all of the env variables, not just SECTION_MAPPING. Maybe we should reserve the HTML comments for later, and just for paragraph level granularity (and leave config.yaml for file-level granularity).
We think we should go with a YAML config file for now, and possibly have it include support for all of the env variables, not just SECTION_MAPPING. Maybe we should reserve the HTML comments for later, and just for paragraph level granularity (and leave config.yaml for file-level granularity).
Makes sense to me!
Issue merged into #31, except for the HTML part that we will consider in the future.
Problem: the AI editor needs to know the type of each section so that it can tailor the prompt to that section type. At the moment, section types are inferred from the filename, but we'd like to support more flexible mapping of text blocks to section types.
Proposed solutions: