Thanks to Raymond, Michael, and Ken for your responses!
Obviously (I think ;-), whether I choose to deprecate the double markup
characters in my lexer for the Scintilla family of editors has no
influence on deprecating them within Foswiki (or TWiki).
I am going to, at least initially, choose not to support those double
markup characters in that lexer. If I start to feel very comfortable
programming in C/C++, I might revisit that decision.
I guess it just means, for anyone who may choose to use an editor in the
Scintilla family (using the lexer I'm working on) to edit Foswiki pages
offline, they should avoid the use of double character markup.
I will still, at least mostly, satisfy my goal of having the lexer work
as kind of a "lint" for Foswiki markup. Anything that works correctly
in the lexer will also work correctly in Foswiki (that is my goal).
There will be some things that won't work correctly in the lexer that
will work fine in Foswiki, and a user of the lexer will need to avoid
These double markup characters are one of those things. There are
some "corner cases" that I'm going to also choose not to
support--things like WikiWords being ended by punctuation (e.g.,
WikiWo*rds will, in Foswiki, recognize WikiWo as a WikiWord--I don't
plan to (ever, I think)).
There are other things I won't support initially that I hope to someday
support. Like, for Foswiki table markup, I'd like the lexer to
actually format the text in the shape of a table (sort of like ASCII
art), including wrapping long cells to multiple lines. But that is a
long way off.
On Friday 13 May 2011 01:46:41 am Michael Tempest wrote:
> On 5/12/11, Raymond Lutz <raylutz@...> wrote:
> > I never use that markup and vote to deprecate it. Use the obvious
> > _* and *_ to get the same result.
> > --Raymond
> For better or worse, == and __ are widely used. They are certainly
> used in the wikis at my work. We will alienate our users if we stop
> supporting == and __ at some time in the future, which means we
> cannot really deprecate that markup.
> It might be possible to *add* support for _* and *_. I view that as a
> separate issue.