The scdoc system has a true parser, which should mean that there’s a strong relationship between the scdoc documents and, for example, the rendered HTML. If anyone is invested in improving usability of scdoc, a REALLY good place to start would be to embed file location info in the HTML. This would allow you to do in-browser editing via
editable and then apply those changes back to the original scdoc. This doesn’t solve the problem of writing an scdoc from scratch, or making structural changes, but it makes it very easy to e.g. pre-populate a template doc (this functionality already exists), and then do all the copy editing in the browser. Before any attempts are made to introduce new layers/frameworks/tooling to the doc system, I think this sort of thing should be investigated - I think technically this is NOT very difficult work, but has a really high user benefit.
As a reminder also - these discussions about the docs system come up every year or so - I think with good reason, as there are some real issues here. But just so it’s not in a vacuum: basically all of these concerns and proposals (e.g. doxygen, literate programming, wysiwyg) were discussed at length when the scdoc system was created. I don’t agree with every detail, but there were strong reasons for all of the decisions that were made. It’s worth digging through the sc-dev / sc-users for these convos if you’re interested in how we ended up with the system we have. I’ll post ML archive links if i can find some (or maybe someone else has an idea?)