A discussion is ongoing about implementing the ability to edit messages per section for long posts, akin to Wikipedia’s functionality. meglio proposes allowing separate edits for sections divided by horizontal line separators, H1 tags (#), or H2 tags (##). This feature would make editing easier, reduce scrolling in the message editor, and result in smaller, more atomic edits.
meglio notes that while this feature might increase the number of edits saved in the database, these edits are relatively inexpensive. mpalmer expresses interest in this feature, particularly for using Discourse as a knowledge base, where articles can be quite long.
mcwumbly suggests exploring the idea of backing revision handling with a git repository, where the latest content would exist as text blobs in the database, and history would be stored in a separate git repository. mpalmer responds that while this idea might be suitable for a third-party plugin, it’s not entirely insane, and notes that there have been discussions about archiving important topics to an external location.
Sometimes, our messages are way too long. For example, a first message in the contest topic where the rules are explained, examples and advices are given.
Still, we promote “less but longer messages” in our forum, otherwise it may become a mess when a topic is summarized. So, we have to follow our own rules and post long messages as well!
We divide messages into sections with using a horizontal line separator:
… or just <H1> tags.
The proposition is to allow editing every section separately.
A section is a piece of topic message divided by any of the following:
a horizontal line separator
H1 tag (text prefixed with #)
H2 tag (text prefixed with ##)
The number of edits saved in the database might increase. However, such edits will be more atomic, and anyway they’re cheap, thus not sure if it’s a drawback or not.
Benefits:
easier to edit
less to scroll in the message editor
better, smaller atomic edits (aka commits in git - better to commit smaller changes and more often)
No other changes needed - “edit” history viewer needs no changes.
I’d be interested in this feature, too, because I use Discourse as a knowledge base, and those articles can end up being quite long. We may be a vocal minority, though.
I wonder if revision handling for article content could actually be backed by a git repository.
Since revision history is not accessed too often, it’s conceivable that there would be a way to have the latest content exist as text blobs in the database, with history in a single git repo that had a file for each post, named by its ID, which should be stable.
We’ve discussed “archiving” important topics (like, say, those in a knowledge base…) into some sort of external place, to access if/when everything Discourse-related is on fire. Nothing’s been done yet, but it’s definitely in mind. Our plan was just to dump the current text of the first post in a topic to a static directory somewhere, because revisions are already kept inside Discourse, but a git repo isn’t a completely insane idea. I’d expect it would be third-party-plugin territory, though.
