GNOME Bugzilla – Bug 620562
Whitespace handling for schema description
Last modified: 2010-06-19 03:11:45 UTC
See: https://bugzilla.gnome.org/show_bug.cgi?id=617917#c15 Key descriptions are documentation, so they should be verbose - multiple sentences or sometimes multiple paragraphs. We want to be able to write: <description> This is a long description. With multiple sentences that are too long to fit into 80 columns. And would give standard editing tools fits if not line-wrapped. And a second paragraph </description> And not have that be displayed to the user as, say: --- This is a long description. With multiple sentences that are too long to fit into 80 columns. And would give standard editing tools fits if not line-wrapped. And a second paragraph --- The alternative of: <description>This is a long description <....> line-wrapped. And a second paragraph.</description> is really hard to edit in emacs or vi, doesn't work well with 'diff', etc. Now we could just say that this all is a question to be settle between the tool and the people writing the schemas but I think that's suboptimal. Should be specified in the GSettings documentation. Approaches: * Preserving whitespace as written: Not easy to work with when treating the schema file as text. * XML whitespace normalization. (Consecutive sequences of whitespace turned into a single ' '.) Main problem is that there is no obvious way to represent a line break; to have multiple paragraphs. Metacity actually takes this approach, and while schemas are occasionally written with multiple paragraphs they get collapsed in gconf-editor. * Markup for paragraph breaks. (Say, allow <br/>) * Non-standard whitespace normlization. Say: - Strip any whitespace up to and including the first \n and after and including the last \n - Strip any common indent off the remaining lines - Remove \n, except leave \n\n
I like the last option best. This is something like what asciidoc or wiki software does and it feels very natural.
empty line == paragraph break sounds like something that is fairly easy to implement and document, so +1 from me
i'm confused about why this is a bug.... nothing inside of GSettings actually processes the description. I've made a patch against intltool that implements the blank-line-for-paragraph approach when pulling the strings out for translation.