Towards a better BBCode

cairnarvon@feynman:~$ cat hello.txt
Hello {spoiler /prog/}.

What do you think of my {sup new} syntax for {i {sup B}{sub B}code} based on S-expressions? It supports {b.i.u function composition} and {sup*2 iteration {sub*3 (and nesting, obviously)}}. It uses curly braces {m \{\}} rather than the traditional {b (}parentheses{b )} because that will require less escaping.

{aa No more unmatched or misnested tags!}

I've written a {spoiler.i terrible} FIOC {i.m SexpCode-to-BBCode} translator, which you can find here: http://sprunge.us/KPWB?py
cairnarvon@feynman:~$ python sexpcode.py < hello.txt
Hello [spoiler]/prog/[/spoiler].

What do you think of my [sup]new[/sup] syntax for [i][sup]B[/sup][sub]B[/sub]code[/i] based on S-expressions? It supports [b][i][u]function composition[/u][/i][/b] and [sup][sup]iteration [sub][sub][sub](and nesting, obviously)[/sub][/sub][/sub][/sup][/sup]. It uses curly braces [m]{}[/m] rather than the traditional [b]([/b]parentheses[b])[/b] because that will require less escaping.

[aa]No more unmatched or misnested tags![/aa]

I've written a [spoiler][i]terrible[/i][/spoiler] FIOC [i][m]SexpCode-to-BBCode[/m][/i] translator, which you can find here: http://sprunge.us/KPWB?py

Hello /prog/.

What do you think of my ^new syntax for ^B_Bcode based on S-expressions? It supports function composition and ^{iteration _{(and nesting, obviously)}}. It uses curly braces {} rather than the traditional (parentheses) because that will require less escaping.

No more unmatched or misnested tags!

I've written a terrible FIOC SexpCode-to-BBCode translator, which you can find here: http://sprunge.us/KPWB?py

In related news, we need a [verbatim] tag that stops the parsing of BBCode inside it like [code], but without the syntax highlighting.

>>2
Someone is a [b]BBCode newbie![/b]

>>1
I preferred `b(my own) `i{`o`u(BBCode) version}.

>>3
I know about manual unescaping, but it's a lot of effort.

>>2,4
Hint: it exists. It's sort of like one of those .Net languages, but without all the consonants.

[b][i][u]Is it really that much effort?[/u][/i][/b]

[sub][sub]I don't think so![/sub][/sub]

>>4
I didn't escape those tags. Take that, faggot.

>>2
Okay, okay, I let you in on our big secret. it's the [#] tag.

>>3
I preferred `b(my own) `i{`o`u(BBCode) version}.
Why? In terms of the number of characters they're the same, except instead of an easy-to-reach space or period, yours uses `, which isn't even accessible without a modifier key on most keyboard layouts. In terms of beauty, yours is harder to read and harder to implement, because it doesn't use S-expressions.
And if yours doesn't do tag iterations, it's less powerful than the one in >>1 as well.

Replacement ideas for BBCODE are terrible. They are even more confusing. BBCODE isn't better if you optimize it for less characters. BBCODE is better if it's less confusing.

>>10
Oh, you mean like HTML? You know, that standard that every hackneyed bug-ridden implementation of every ass-invented markup language outputs. The thing your web browser actually displays.

>>11
What do you want it to do? Break your webpage whenever it encounters broken HTML? That's what XHTML is for.

>>10
The issue isn't the number of characters, it's the fact that explicit closing tags make it far more error-prone. This is a problem that has afflicted languages like it ever since SGML inflicted them on their bastardization of GML. S-expressions solve this problem beautifully.

>>11
I think he meant like Markdown.

>>9
which isn't even accessible without a modifier key on most keyboard layouts
On my keyboard ` is just above the Tab key, to the left of 1, and under Escape and it's been there on every layout I've ever used (AFAICR). But it's not like I designed the system to be a replacement for BBCode or anything, so I didn't take into account different layouts.

yours is harder to read
Beauty is in the eye of the beholder, I quite like the way mine looks but to each their own.

harder to implement, because it doesn't use S-expressions.
This is bullshit, implementing it was piss-easy and only took around 30 lines.

And if yours doesn't do tag iterations, it's less powerful than the one in >>1 as well.
True, I didn't think of that at the time.

Oh, and mine has also the property that the only character you really need to escape is ` - any brackets not preceded by ` are treated as ordinary text. And you can choose which type of brackets to use ((), [], {}, <>), so that you don't have to use a modifier key at all (using `[]).

>>13
it's the fact that explicit closing tags make it far more error-prone.

So you want a universal close tag that closes any open BBCode tag?

BBCode parsers can already be coded to not allow broken BBCode to be parsed. But I see what you are saying.

I'm thinking about this in my head right now, and it seems like would be harder to make a BBCode parser that uses a universal close tag. Or maybe not. I'm not sure, I'd need to think it through.

>>12
No, the submit function should sanitize the HTML properly, just like a well-written text processor would do with any markup.

I should point out that shitchan doesn't bother sanitizing anything, and that's why we get garbage like the entire board being rendered in italics. You can have problems with any markup format if you're a piss-poor programmer who doesn't bother doing things properly.

As for the close-tag redundancy: I don't see anything inherently error-prone or disadvantageous with it, personally. Yes, it's a bit more verbose, and that's annoying, but any decent editor could easily support auto-completing closing tags (say, by filling in the most recently opened tag when typing </), and the redundancy is occasionally extremely useful for catching accidentally mis-nested tags and identifying why some block of text is showing up in the middle of nowhere at the bottom of the page.

I think it's unfortunate that the shorter SGML syntax (the <b/something/ style) has faded into obscurity; it would be nice to have something like that for the simple cases when nested tags and other such complexity isn't necessary.

>>14
Markdown is generally not very useful, in the same way that every attempt to make writing HTML "simpler" also usually turns out badly. Just write the damn HTML and get it over with.

Just use RTF text controls on web pages.
Though then you have more than one problem.

>>17
that's why we get garbage like the entire board being rendered in italics
The reason why that happens is because there's a bug in the way shiitchan truncates posts. It wouldn't have been a problem if the programmer added a simple function to close all unclosed tags in truncated posts.

>>16
harder to make a BBCode parser that uses a universal close tag
Complete nonsense. If you're doing your job of parsing the text correctly, you're already keeping a tag stack. Suppose you used [/] as the "close recent tag" syntax, you just pop the last tag off the stack and output its closing HTML.

Incidentally, >>1's "parser" is awful, inefficient, and error-prone -- much like every amateur script kiddie attempt at writing some text-massaging code; and that's not only because it's wasting tons of processor time and memory repeatedly concatenating immutable strings, rather than building an array and joining it at the end.

>>19
Yes, and that bug stems from the fact that it's plain and simple, horribly written. See also the [o] bug in quoted text, the idiotic behavior of wrapping parts of code blocks in blockquotes if lines start with >, etc. It's a fucking awful parser.

>>17
Some people, when confronted with a problem, think
“I know, I'll use sanitized HTML.”   Now they have two problems.

>>16,17
universal close tag
As for the close-tag redundancy: I don't see anything inherently error-prone or disadvantageous with it, personally.
The main problem with BBCode as it is implemented on Shii_tchan (and XHTML, and XML, etc.) is the fact that tags must be nested properly. That's responsible for a lot of broken code, and pretending it isn't when the evidence is right in front of you is naïve at best. With S-expressions, this problem just goes away.

decent editor
I look forward to your dedicated BBCode editor, but until then, your only option is basically to use an HTML/XML editor and s/<>/[]/. Meanwhile, every single text editor in existence already does paren matching.

S-expressions are just the superior solution in every way imaginable. Quit making excuses and get with the program.

More people know BBCode than they know HTML.

Using the "having to learn another language" argument is moot, because that other language would be HTML, not BBCode.

Whether you like it or not, BBCode is highly popular around forums and such.

>>20
wasting tons of processor time and memory
It's funny because 1. you don't know how Python handles strings, and 2. even if you're processing the longest post Shii^tchan will let you post, the script returns before you're taken your finger off the Return key.

error-prone
Is it? Demonstrate. I think you're just sore because you didn't think of it first.

>>22
Any fucking text editor with support for scripting -- such as vim, emacs, etc. -- can do that.

>>23
BBCode only exists because certain dumbfucks decided that [b] was somehow easier than <b> to handle. The original implementation did nothing to sanitize their output except making sure that every [b] was followed by a [/b]. The fact that people are goddamn morons and can't "learn" how to write < and > is pretty sad.

>>25
Any fucking text editor with support for scripting -- such as vim, emacs, etc. -- can do that.
Can but doesn't.

BBCode only exists because
BBCode exists as it does because people wanted it to be obvious their input was going to be processed into HTML rather than just dumped verbatim, to discourage people from expecting to be able use every HTML tag in the spec without limitations.
It still mimicked HTML rather than using something sensible (like S-expressions) because these people were still web developers, and therefore brain-damaged.

>>23
I'm not convinced that's true. BBCode isn't as popular as it once was, and traditional BBCode-supporting forums are a dying breed. Meanwhile, everyone and their grandmother knows HTML. At least, mine does.

>>24
you don't know how Python handles strings
That's funny because you don't seem to know shit all about what I know, and perhaps even less about the subject you're pretending to be so all-knowing about. Try looking it up, += in a loop is most certainly slower than "".join(list), and strings are immutable. Full stop, there's no room for argument.

And: while there has been some work done in Python 2.5 in regards to optimizing strings, other implementations (IronPython, Jython, etc.) are not nearly as well-optimized there, and implementation regardless, joining a list is still on average at least 20-30% faster even with the most recent Python version, it consumes less memory, and is also quite a bit easier on the GC.

It doesn't mean much on a small scale with a single post, but go ahead and use code like that on an app server that's processing several posts a second. Shit like that is why people think dynamic languages are so slow; they don't bother learning how they are actually implemented.

(And by the way: how about that code stepping through the input stream one character at a time? Jesus!

Oh, as far as how >>1's syntax is "error-prone"? Try formatting a block of C code and making sure you escape all the braces in it.

>>28
one character at a time
Regardless of how fancy you want to get, you aren't going to get around having to look at every character.
I don't see the problem, anyway: >>1 acknowledges the code is terrible, and it's just a proof of concept.

Meanwhile, nobody else on /prog/ even knows how to write any code, let alone bad code.

>>29
You weren't saying the syntax was error-prone, asshole. You were saying the parser was error-prone.

>>29
Unless you've invented some new C/BBCode hybrid, your C code isn't going to contain any SexpCode/BBCode that needs translating. Don't run the script on C code.
Difficult concept?

>>32
Oh, my mistake. I guess no one posts any code on this board.

For a discussion of BBCode replacement and the implementation of >>3, see http://dis.4chan.org/read/prog/1254413507.

>>33
While that's true, you'd still be an idiot if it weren't, for not running it on the two lines of introductory text rather than on the giant block of C.
Even if you want to post literate C type crap, whether or not to keep parsing inside {code ...} blocks is (so far) an implementation issue, not a problem with the language.

You might as well complain that BBCode stops you from using variables like b, i, and spoiler as array subscripts.

[ " version." [ "-code" [ "B" sub [ "B" sup i " [ [ "my own " u b "And I, of course, prefer " root

You're supposed to be thinking up a lightweight markup language.

How about just use [/] as a catch-all close tag.

I'd even settle for [b this text is bold/]

>>35
How exactly the fuck do you propose that the parser handle writing } inside a code block and still know when to close it, without having to modify one or the other? And what the fuck are you even babbling about? This has nothing to do with ``literate'' bullshit, it's about how the proposition to use one single character to close a block is a far worse proposition than duplicating one character.

And you obviously can use [b] as an array subscript, without having to change the code. The only thing you can't write without modifying it is [/code], and that's not valid syntax in any programming language I can think of offhand.

>>37
I brought up [/] already in >>20. This same syntax could of course be used with HTML (which no one has yet come up with a single actual reason for not using).

>>38
(which no one has yet come up with a single actual reason for not using)
Because you're a fucking idiot. Here's a clue.

>>38
I brought up [/] already in >>20. This same syntax could of course be used with HTML (which no one has yet come up with a single actual reason for not using).

Because then it's not HTML anymore. It's just some fucktarded language that uses < > instead of [ ]

<b>bold text</> is not HTML.