On Sat, Dec 21, 2002 at 11:20:17PM -0600, Derek Moore did utter:
For example, say we wanted to use /slashes/ for italics. How would the following line be rendered:
"In UNIX-style operating systems, services' configuration files are located in /etc/. The X Window System's configuration files, for example, are in /etc/X11/."
How exactly is the software gonna know when /[word-boundary]...[word-boundary]/ is to be italicized text, or a UNIX-style path, or anything else where forward slashes are normally employed and aren't meant to italicize? It'd be possible to work up some logic so the software /could/ distinguish between paths and something that's to be italicized... But what if you wanted to employ italics like this:
"/anti/dis/establishment/arianistically"
In my NEWS markup notes, you'll see that while I set the "/" to be the italic control character, a single "/" is not the delimiter for starting and stopping italic. Rather, a startline, whitespace or punctuation, followed by "/" and then followed by a non-punctuation character - will trigger the start of italic. Reverse for end-of-italic delimiter. (might need some tweaking for usage - especially with regards to punctuation).
You might mean for it to render:
"<i>anti</i>dis<i>establishment</i>arianistically"
My system would currently have rendered it as "/anti/dis/establishment/arianistically" exactly ;)
Sure, this means in-word italicing (and bold, etc) isn't possible - but I think given the 10/90 rule (10 percent of features will satisfy 90% of needs), this is a reasonable tradeoff. I'd maybe suggest allowing pure HTML for any remaining cases?
Regarding file paths which could be italicised? I think throwing a simple no-wiki syntax around it would be the best way to keep a path clean of wiki markup :)
Much better is:
"[/anti/]dis[/establishment/]arianistically"
I think you're in danger of reinventing a html1.0 shaped wheel, however, and losing the simplicity of .txt "nomarkup". I'd rather lose a feature (or only provide it as html - eg, for italicing parts of words) than overly complicate the markup. The thought-experiment I use is "could I send this raw code to a non-geek friend, and be confident that they'd not find the markup confusing, but rather, find it obvious?"
pre-release should be out sooner than later. Right now I'm working a lot of the conceptual stuff, the framework, the integration of components, etc. You have to create a consistent theory before you can create a consistent product. <g>
Indeed - which is why I've been theorising my NEWS markup already. You're further along than I am though. (and when it comes to product development of my ideas, I'm astoundingly lax :/
I'm sure your ideas are invaluable. And I'm sure I'll be incorporating your best ideas into Wikitax.
And similarly I'll likely nab wikitax ideas for NEWS. Ultimately, I hope we find a single compromise between read/learn/use-ability and features/complexity needed to power what we want :)
.../Nemo