Here's the BBCode Cheatsheet I've been working on: <http://jsfiddle.net/danneu/er62ohnd/2/embedded/result/> It's missing some things like the javascript that makes `[hider]`s work. It's also not a comprehensive list of all the tags I want to support. But I'm pretty proud of the `[tabs]` BBCode. Ever since I heard of BBCode-supported tabs, it has been the first thing I attempt to implement in a BBCode parser since it's pretty much the upper-bound of complexity. I'll post an update once I've added all the BBCode that I'm going to support at first. > How do you plan to do unread notifications in threads? For example, my favorite forum software (SMF) has a topic log in its database with the member id, topic/thread id and the id of the last message id viewed (which I believe is an AJAX call for browsers with JS enabled, and a message included with POST when users access a new topic page for disabled JS browsers like WAP or Lynx). That makes it simple (relatively so) to handle indicators of new posts by comparing the topic's latest message id with the topic log. Thanks for sharing. I hadn't pondered it much, but that's how I will do it (unless I can prove that it's insufficient). IIRC, vBulletin 3.8 let me downgrade to a similar implementation that instead stores that data in the user's browser cookie instead of generating a database update per authenticated request. Of course, a database-backed solution will actually persist across devices/sessions at the expense of database resources, so it's a better user experience (unless you run out of database resources). I already incur a database update every authenticated request by updating `user.last_online_at = NOW()` in the same query that I load a user given the `sessionId` in their cookie. (Source: <https://github.com/danneu/guild/blob/master/server/db.js#L407-L418>) I could incur another update on every authenticated topic-/convo-view request to update some `latest_topic_views` table, but it can be done asynchronously. I'll give it a shot. > @The Nexerus: I would say my keyboard is a normal layout. > > @Shienvien: I agree, it's a habit I have that I never found as anything until now. I type that way because I've always typed that way since I learned how too. It won't be easy to break that habit now that this has come to my attention. Don't worry about it too much since this behavior will go away once I roll out BBCode, a feature I'm wrapping up right now.

> Here's the BBCode Cheatsheet I've been working on: <http://jsfiddle.net/danneu/er62ohnd/2/embedded/result/> > > snip That is some garbled Aussie slang right there (in the link, for those who haven't read).

I'd tend to spell 'color' as 'colour', which is the British spelling. Will this be a problem when I'm doing the BBcode for coloured font?

Unless the easy way out of adding a duplicate code interpreter (for both the proper [Color] and the British [Colour], then it will be a problem. But we've no doubt Mahz can add them both, as the code is essentially the same. It might even just require a couple of extra lines of code (or even just part of a line)... hmm... on the subject of colored text... Will you add support for adding colors by [Color=#FF00FF] (Hexadecimal code), or just [Color=blue]?

> I'd tend to spell 'color' as 'colour', which is the British spelling. Will this be a problem when I'm doing the BBcode for coloured font? Good call. I'll add 'centre' as well and any others I find.

> Unless the easy way out of adding a duplicate code interpreter (for both the proper [Color] and the British [Colour], then it will be a problem. But we've no doubt Mahz can add them both, as the code is essentially the same. It might even just require a couple of extra lines of code (or even just part of a line)... > > hmm... on the subject of colored text... Will you add support for adding colors by [Color=#FF00FF] (Hexadecimal code), or just [Color=blue]? I support both.

Mahz is an equal opportunist color-code supporter. That being said, the new BBCode looks good. My English fails me at this moment, but the big underscoring lines separating the (larger) headers from the text below, is that automatic?

Just the answer we hoped for... we'd guess they are automatic, Hank.

> > I'd tend to spell 'color' as 'colour', which is the British spelling. Will this be a problem when I'm doing the BBcode for coloured font? > > Good call. I'll add 'centre' as well and any others I find. Yay!! British spellings! Top job here buddy! Looks better now than the Vbulletin forum :)

mahz you are crazy cool

> Mahz is an equal opportunist color-code supporter. > > That being said, the new BBCode looks good. My English fails me at this moment, but the big underscoring lines separating the (larger) headers from the text below, is that automatic? I decided to add some heading tags `[h1]`, `[h2]`, `[h3]` since I usually like to have a quick lightweight way to break my posts into 2-3 levels of subheaders. Markdown has lightweight syntax here: `# Header 1`, `## Header 2`, `### Header 3`. I added the underlines to make it more obvious which sublevel you were at, but I prob went a lil far.  Since I will support `[size=...]` and `[font=...]` tags, people can essentially roll their own headers. But I figured it'd be nice to have some opinionated h1/h2/h3 tags for when you can't be fucked. ---- I also spent way too long re-implementing custom buttons to the editor that support BBCode. Including a pop-up color-picker.  My goal for today is to finish up and push it to the dev server.

Good stuff.

ooh, shiney. When its over there, we'll gladly help test it for ya.

I pushed up the preliminary BBCode system to the dev-site: <https://dev-guild.herokuapp.com/topics/145/posts/ooc> I could use some help testing it. I'm also collecting performance data on the parser. Here's somewhat of a BBCode cheatsheet: <http://dev-guild.herokuapp.com/test> I'd appreciate some feedback. Notes: - I still haven't implemented all of the BBCode that I would like to support - Nesting some BBCode tags will simply generate broken output. Ex: If you try to nest `[tabs]`, the inner tabs are duplicated as top-level tabs. Haven't fixed it yet. - If you can cause a "Internal Service Error" (server crash) from bad BBCode input, I'm especially interested. Bad input should never crash the server. - I'd like to hear about BBCode rendering behavior that you didn't expect. Or enhancement suggestions. - What do you think of the color picker? Does it work for you? How much does it suck on mobile? Thanks for anything. Updates and notes to self: - TODO: Add aliases like `[colour]` -> `[color]` and `[centre]` -> `[center]`.

Two things we noted. mixing tags together means broken. [i][b]text[/i][/b] does not work. [i][b]text[/b][/i] works. Hiders seem to work well even nested. As does color, both text and hexadecimal. Combinations of basic formatting also works. (bold/italic/underlined)

> Two things we noted. > mixing tags together means broken. > > [i][b]text[/i][/b] does not work. > [i][b]text[/b][/i] works. > > Hiders seem to work well even nested. As does color, both text and hexadecimal. > Combinations of basic formatting also works. (bold/italic/underlined) I've been working on a validation system that gives helpful errors:  The BBCode implementation I'm using only exposes two vague types of errors, one of them being that "some tags appear to be misaligned" error above. I had to implement the rest of the errors in that screenshot. Unfortunately, fixing tag misalignment is a pretty hard problem if the parser itself doesn't expose that feature. Fortunately, the parser seems to handle things like misalignment well in that, instead of choking, it just simply doesn't render the misaligned BBCode into HTML. Bad tags and misaligned tags just remain unrendered plaintext for you to fix. Hopefully between that and my validation error messages, it won't be too hard to debug a BBCode clusterfuck. People writing format-heavy posts should have a decent feedback loop by clicking the Preview button periodically which triggers my error reporting system. (I'll deploy it to the dev server later tonight)

> Unfortunately, fixing tag misalignment is a pretty hard problem if the parser itself doesn't expose that feature. Can you at least pinpoint line numbers even if the actual tags involved aren't identified?

> > Unfortunately, fixing tag misalignment is a pretty hard problem if the parser itself doesn't expose that feature. > > Can you at least pinpoint line numbers even if the actual tags involved aren't identified? As I become more familiar with the code of this library, I might find out that it's doable without too much hassle. Obviously counting newlines comes to mind. But this library is implemented with regular expressions which are pretty opaque to work with. At least until I sit down and study it. I've been patching this library to provide validation errors and better tag implementations. If I don't watch out, it will've been more economical to've just written my own recursive descent or PEG parser, which is something I want to do anyways to vanquish BBCode once and for all. Imagine error metadata like: 'Expected [/b] on Line 10 Col 8 but found [/hider]'. And then exposing that to the user with some inline editor errors. Anyways, I'm definitely wasting time by obsessing over my error system. I mean, who cares. :lol

> > > Unfortunately, fixing tag misalignment is a pretty hard problem if the parser itself doesn't expose that feature. > > > > Can you at least pinpoint line numbers even if the actual tags involved aren't identified? > > As I become more familiar with the code of this library, I might find out that it's doable without too much hassle. > > Obviously counting newlines comes to mind. But this library is implemented with regular expressions which are pretty opaque to work with. At least until I sit down and study it. > > I've been patching this library to provide validation errors and better tag implementations. If I don't watch out, it will've been more economical to've just written my own recursive descent or PEG parser, which is something I want to do anyways to vanquish BBCode once and for all. > > Imagine error metadata like: 'Expected [/b] on Line 10 Col 8 but found [/hider]'. And then exposing that to the user with some inline editor errors. > > Anyways, I'm definitely wasting time by obsessing over my error system. I mean, who cares. :lol I'm sure there are plenty of people who could make use of such error reporting. Not everyone is so technically or detailed oriented (or sometimes those people post drunk/tired/high) and need a little more help.

I'm one of those writers that often makes use of the "edit" button, but sometimes I forget to edit something and have to go back in to fix it two or three times before it's correct. I noticed earlier that when I went to edit a post for the second time, when I saved my first edit had been replaced with what had been there previously. Is this a bug or just something that I have to refresh the page to do multiple times? Update: Even if I leave the page and come back, all edits are reverted back to the original post. So if I need to fix something, everything needs to be fixed again at the same time.