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
--
Why, do you think I ought to have /\/ <nemo(a)nut.house.cx>
one? It seems odd to give a bundle \ ...
of vague sensory perceptions a name / DISCLAIMER: Use of advanced messaging
... \ technology does not imply an endorsement
http://www.nut.house.cx/~nemo /\/ of western industrial civilization