|Syntactic Confectionery Delight|
Re: Wiki-Style syntax for posting (DWIM)by tye (Sage)
|on Oct 15, 2008 at 03:54 UTC||Need Help??|
Yeah, I think this argues for making much more focused hints. Just note P tags and CODE tags (and that < and [ might need CODE tags), quite concisely, with examples, directly above the Title box (with a ?-style link to more detailed help). (Maybe also discourage BR tags; we hates them fat, stupid, nasty habitses.)
As for more DWIM, I wouldn't do any of the many "wiki" mark-up styles nor would I do POD (at least at first). But I would like to take a couple of good ideas that are common to many of those:
Another DWIM feature that I'm surprised has never occurred to me before nor do I recall ever having seen it suggested: Require a space (or open paren or quote) before and not after [ for it to be transformed into a link (for users who haven't chosen "expert" mode).
I think those three "simple" DWIM features would eliminate a sizable majority of the formatting mistakes here. There is a bit of a trick in how to decide whether to apply those features to a particular node.
I think the most likely way to get this is to add a "format type" field to all write-ups and as a user setting. The choices would need to include at least "traditional PM" formatting that does no DWIM (for existing write-ups and for users who don't want any "improvements") and a "DWIM" formatting that uses the above 3 DWIM features while allowing all of the traditional PM mark-up. I'd probably just have all users default to "DWIM" formatting for their future nodes. A per-node over-ride would also be nice, especially for persistently anonymous monks.
It might be worth-while to have other formatting choices but I've talked myself out of all of the other options I've considered recently. I even considered having a UTF-8 format option, but I think it would be better to just convert the database en masse to UTF-8 (which would also tempt me to restrict the character set for node titles, but then Perl 6 would just use some such restricted obnoxious character for some strange operator and then we wouldn't be able to talk about it properly).
Oh, I just did some spelunking via SQL and my nefarious plan for /(?![^\s(>"])\[(?!\s)/ being optionally required for links to be expanded appears to indeed be a very effective heuristic. :)
I will try to get around to trolling the recent previous suggestions for how to redo the "hints" and come up with my own exact recommendation for the new to-the-point and in-your-face hints.