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.

>>39
Easy enough, define <spoiler> on a sitewide basis. Just because the base syntax is HTML doesn't mean you can't implement a superset of the standard HTML tags.

And of course, document it on the site, with a "markup help" link or similar near the post form.

>>40
Sorry, you parsed that wrong. I should have been more careful with my wording there:
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).
That is, no one has yet come up with a good reason not to just use HTML -- or least something that very closely resembles it.

A good parser can stop malformed BBCode from being turned into malformed HTML.

In that case, you get unparsed BBCode which only makes you look dumb.

Careless mistakes do happen and I assume that the whole reason for this thread is because you want to make it less likely to fuck up your BBCode.

Why not just have a BBCode preview feature? Or why not make it so that it doesn't let you make a post if you have malformed BBCode?

I actually like the latter. No board should have un-parsed garbage markup, whether intentional or not.

Jesus Christ, did Xarn really troll all of you that hard?

>>44
What's the matter, they don't allow BBCode discussion in the People's Republic of BBCode?

>>44
That's not Xarn's tripcode, altough the username looks like his.

A good parser can stop malformed BBCode from being turned into malformed HTML.
Just as much, a good sanitizer can stop malformed HTML. The key component here isn't the BBCode, it's the "good parser" bit, and pretending BBCode somehow solves the problem of malformed or malicious data is like requesting to be sodomized in a prison shower.

In any case, this conversation is drifting towards the theoretical and ever-farther away from interesting programming talk, so I'm going to step out.

>>47
Just as much, a good sanitizer can stop malformed HTML.
That's true. But HTML is not the standard here, BBCode is.

Majority of the population knows BBCode better than HTML, if they even know HTML at all.

Besides, none of that matters, dis.4chan uses BBCode already anyways. So the question I ask is, do we really need a BBCode alternative? My answer is no.

I think you can solve some problems with lateral solutions.

I'll also point to this post in regards to HTML vs BBCode: >>23

>>48
Repeating baseless assertions doesn't magically make evidence appear.

The one thing that's always bugged me about ^BB_code is url tags. Why should it be [url]http://somebullshit.on.nimp.org[/url] when you want just the address but [url=http://someotherbullshit.on.nimp.org]I TROLL U[/url] when you want some other text or image as the link? _ARRRGH!!!!

>>48
By the same reasoning, all of these programming languages are bullshit and everyone should be using FORTRAN I.

Majority of the population knows BBCode better than HTML, if they even know HTML at all.
how many bbcode failures are posted to /prog/ per day? how many html failures per day?

>>52
Why the fuck would anyone use HTML on /prog/. BBCode is world4ch's formatting language.

>>51
What reasoning is that? Your post doesn't make any sense at all!

>>49
The truth is the truth. Take away BBCode from forums and give them sanitized HTML. They won't know what to do. People already know BBCode, not HTML. Changing BBCode to sanitized HTML is a burden on the user.

Of course, you don't listen to reason. You're gonna be close minded and ignore the facts because someone indoctrinated you to believed HTML is what the entire Internet population knows. Might've been true 10 years ago, but not anymore. You think facebookgirl and bloggerguy know two shits about HTML? Because let me tell you, they don't. People don't need to know HTML as much as before, what with all your joomlas and blogspots and myspaces and twitters, etc.

>>53

The argument that BBCode has equity with users is vague at best, and not very relevant regardless. If you want to talk about an audience that has something to lose from a system change, show me the audience, and tell me just what it is they have to lose.

Regardless, this is all tangential. The important argument here is not whether or not the semantics should be [tag] or <tag>, but something entirely greater: how one should design the means by which a user can bold, underline, and otherwise format his text posts within a given forum.

There may be ways to make a text-based formatting system (like BBCode) less painful, or easier on the parser, or more principally aligned with how browsers are told to render websites, and so on. But ultimately, they will never be intuitive in the same sense that handwriting is intuitive, because the user now has to juggle a confusing conceptual distinction between nested markup and written word within the same space, using the same medium. The user should not be responsible for writing both content and instructions on how to display that content. The user should only be responsible for writing content.

Forcing the user to write his formatting is a cheap fix. The browser sees markup; the user, meanwhile, sees images — letterforms included. Personally, I think BBCode is flawed, but good enough — because the only meaningful improvement to BBCode would be to not use BBCode at all.

I supose we should just use HTML, the elements used in BBCode are quite similar, only significant differences being the [ ] and [url], [color] which world4ch doesnt even use.

Like its any different writing <b></b> instead of[b][/b].

&lt;b&gt;&lt;i&lt;ESCAPE MY ANUS&lt;/i&gt;&lt;/b&gt;

>>1
What the hell man, that looks just like the BBCode I made up on the spot yesterday, but with less braces so you can't use parameters for your tags.

>>3
Also, you should use \i{bits} because that's what I did several weeks ago.

Jeez.

>>54
You're making the same unsupported leap >>53 made: that because BBCode is ``good enough'', no improvement is worthwhile. Frankly, this is bullshit.
The fact that it wouldn't be as intuitive as hand-writing (since when is hand-writing intuitive?) is irrelevant. Even if the comparison were at all tenable, the implication that anything but the best is all equable bad is obviously incoherent.

because the user now has to juggle a confusing conceptual distinction between nested markup and written word within the same space
You'll find that the user already has to do that, even in your precious hand-writing. That's what punctuation is, and to some extent what writing is altogether.

The user should only be responsible for writing content.
Style is content. There's no conceptual difference between well-placed italics and a well-placed semicolon, or a apt figure of style.

Your line of arguing would be offensively condescending to the user if it weren't so plainly incorrect.

HTML and a good parser is best.

>>59
Bullshit.

>>53
You think facebookgirl and bloggerguy know two shits about HTML?

From my meager understanding of Facebook and Blogger (I don't have either one of those) they both use HTML for formatting. Either way, "typical" users would likely find a GUI where they can select a block of text and click the bold button much more palatable than any sort of markup. Tons of highly popular and successful websites that allow for writing formatted content make the underlying markup entirely invisible. Adding CKEditor to a web app is nearly a drop-in process, and it'd take about two minutes to retrofit an existing site to use it.

"Power users" who might want to write the code themselves are also not coincidentally much more likely to know HTML. The average Joe that you're talking about probably only knows BBCode because that's the particular variant of weird brackets-and-slashes that they were introduced to; they don't care at all how it works or what it's converted to.

Essentially, most of this thread is comprised of stupid strawman arguments. Do some actual usability testing. You'll find that anyone who's not a programmer or web developer will likely find BBCode at least mildly annoying, and will be better off with something they can click; and the rest of the population will have little or no trouble writing HTML instead of BBCode or whatever other contrived markup there is.

>>58

You've seemed to miss the most important distinction: namely, that people see things, not markup.

There is a difference between this and [#][b]this[/b][#]. Letters are things in themselves, not pictures of things. You're right in that style is inseparable from content, because they are both effects of letterforms. But because of this, your belief -- that telling a browser "what that style should be" is the same thing as "that style" -- is plainly incorrect.

Of course it was clear that you didn't understand the point when you were willing to write something as misguided as "since when was hand-writing intuitive"? Hand-writing is nothing more than mark-making, by a person who is very particular about his marks. I want the page to look a certain way, so I make my marks directly where I feel they must go, onto the surface I'd specifically like changed. My hand is touching the graphite, and physically pressing it into the surface where my letterforms need to go. And with each movement of muscle within my fingers, I can make those letters as heavy or as light as I'd like, and on any axis. Fewer things are as intuitive as this, 58.

Compare that to BBCode. Now I must use letterforms not to make words or style, but to form incantations, wherein I summon the BBCode Arbiter-God. He sits in his kingdom until I have asserted that I would like others to be able to read what I have written, at which point we all wait for his procession, for the great Arbiter to glide in and proof my incantations. At this point, I can do nothing by hope. I hope that he will take what [i]I've done[/i] and replace it with what [i](I think) I wanted[/i]. I hope that I have instructed him correctly, as he is one of those Gods that is very particular about his tradition, and will refuse to overlook a single mistake. And I hope that even my [i]correctly formed[/i] runes will result in the style that I intended to make in the first place. And did I mention? That incantation, in order to work at all, must necessarily be written on the same paper as my speech, using the same pen, mixed in like clumsy cryptography. This is what any text-based formatting system would have us do. And yet, this is the system you would like to keep using, or even "improve." I fear that you've been worshipping false idols for too long. No user should be forced to summon a pagan God in writing just to make a mark. Instead: let him make the mark!

>>62
How funny that your post is full of BBCode failure.

>>63
And it's all due to one missing character.

>>62
You're still full of shit. The problem is that you don't understand the difference between genuine intuitiveness and mere familiarity.
I suggest you stay out of the discussion, because you have nothing of value to contribute.

What's the point of [rem] ?

>>66
I use it in my open source ^B_BCODE kopipe to insert the [o]BPL[/o].

FUCK

>>65
You're wrong, OK? But I can't prove it, so you better just take my word for it!
And by the way, you have nothing of value to contribute!

(　≖‿≖)

>>65
No, *you* are full of shit.

MY ANUS _{^{IS FULL OF SHIT}}

(spoiler)spoiled(/spoiler)
spoiled

(s)spoiled(/s)
spoiled

charmander learned Spoiler!
charmander learned Strikethrough!

>>73
char mander;

>>74

char meleon;

>>74-75
Please initialize your Pokemon.

Bamp for Reddit sensation!

This is the second time Xarn has been on the front page of both /r/programming and /r/coding, and he doesn't even have a Reddit account.

[tt]Achievement obtained:[/tt]
Eli Barzilay commented on your article!

I read that as "Torvalds, a better BBcode"

See also: http://cairnarvon.rotahall.org/2010/05/25/towards-a-better-bbcode/

bbcode does what html is supposed to do.

most forum software let you make custom bbcode. you can make ./ia tag or anything u wanted to represent [img][/img] if u want.

>>79
The real achievement would have been a flame war

I regret starting the Xarn meme years ago. I created a monster.

>>85
Xarn can not be created or destroyed

>>86
Xarn is God. All must bow down to Xarn.

>>85
Bio I am not a meme.

u lose asswhole

>>87
Yet he doesn't believe in himself.

>>89
No. He doesn't believe in any of the conventional religious Gods or all of the biblical texts since they don't mention him. Quite understandable really.

>>85-90
Xarn detected.