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.