AT&T Archives: The UNIX Operating System, a presentation largely by a young Brian Kernighan

Describes how the UNIX pipeline and philosophy empowers users to solve their own problems by composing existing, simple programs together without having to write new programs outright. This is something those of us who've used UNIX shells for years take for granted by now, but there's something really enjoyable about seeing Bell Labs folks articulate their then-new idea for this paradigm, and seeing how much of it is still very relevant today.

it is Bandcamp™ Friday®, which means i have purchased the 2025 remaster of Gay Bar by Electric Six and spliced the first verse with that of its Japanese radio edit

...okay i had no idea the WYSIWYG mode even existed. very impressive that you got this working with that!!

Types of BBCode

The spoiler plugin I've built, which adds spoilers and "restricted" blocks of text in the form of BBCode, involved working with the BBCode renderer in SMF. Surprising, I know!

Maybe a bit more of a surprise is that SMF 2.x has not one, but two BBCode renderers. The one SMF 1.x hackers might remember is the server-side rendering code that's an undocumented mess. Don't worry, it's still a mess. We'll have to worry about that soon, but first, I want to talk about the JavaScript-based SCEditor used in SMF 2.x.

There are two modes to SCEditor: plain text and WYSIWYG. You can switch between the two by clicking the page icon in the toolbar:



The text-based editor is as basic as it gets, and the WYSIWYG editor is... an iframe that you edit because it's content-editable. Which, okay fair, I can't think of a better way to do it. But that does mean we have to convert between HTML and BBCode. So how to we do that?

By hand, of course

I won't go into the details since the SCEditor docs handle it pretty well, but basically: you either receive the BBCode form pre-parsed and have to turn the values into an HTML fragment (text -> WYSIWYG), or you receive the HTML element in the DOM and have to return the BBCode as a string. Somewhat annoying when you have something as complex as a details/summary pair of elements, but I couldn't think of a better way to do it generically.

This is all client-side, though. SCEditor always sends the BBCode to SMF when you hit Post or Save Draft, since SMF doesn't know what to do with the HTML. Unfortunately, this aspect of SMF is poorly documented. I have come to expect this at least.

So, to start off, we have to hook integrate_bbc_codes with a function that we'll use to include our BBCode. That hook function will look a little something like this:

function hook_my_bbcode(&$codes, &$no_autolink_tags) {
  // $no_autolink_tags is an array of tags that shouldn't have their
  // content automatically turn into links. we'll be ignoring that
  // here.
  $codes[] = array(
    // the tag will be [box][/box]
    'tag' => 'box',
    // more on this in a moment!
    'type' => 'unparsed_content',
    // $1 is the content between the tags
    'content' => '<div style="border: 1px solid white;">$1</div>',
    // Provide a function to transform the content the user entered.
    // For example, [noguest] uses this to hide text from guests.
    'validate' => function(&$tag, &$data, $disabled, $params)
    {
      // If the user didn't provide content, provide it for them :)
      if (empty($data)) {
        $data = "im in the box!";
      }
    },
    // yes this is a block element
    'block_level' => true,
  );
}

There are a bunch of other array keys I'm skipping over here, which are only really documented in the SMF parse_bbc function in Subs.php. The main thing that I want to share that tripped me up is the "type" key. Here it's "unparsed content," but what does that mean? What is "parsed content"?

Fear not, curious reader, for I shall share the code comment in the middle of a function documentation with you:

  type: one of...
      - (missing): [tag]parsed content[/tag]
      - unparsed_equals: [tag=xyz]parsed content[/tag]
      - parsed_equals: [tag=parsed data]parsed content[/tag]
      - unparsed_content: [tag]unparsed content[/tag]
      - closed: [tag], [tag/], [tag /]
      - unparsed_commas: [tag=1,2,3]parsed content[/tag]
      - unparsed_commas_content: [tag=1,2,3]unparsed content[/tag]
      - unparsed_equals_content: [tag=...]unparsed content[/tag]

Well. This is useful, but only vaguely elucidates what "parsed" content is. It's referring to the parsing of BBCode: for example, the content of [mytag][b]hello[/b][/mytag] would be "hello" if [mytag] is parsed content, but "[b]hello[/b]" if it's unparsed. In retrospect, this was probably obvious...

There's an important caveat to the first one, internally "parsed_content" but actually defined by the lack of a "type" parameter: you cannot use the "content" field, and "validate" can't be used to modify the content. To actually convert the tag to HTML, you have to use the "before" and "after" fields, like so:

$codes[] = array(
  // the tag will be [box][/box]
  'tag' => 'box',
  // what to add before the content
  'before' => '<div style="border: 1px solid white;">',
  // what to add after the content
  'after' => '</div>',
  'block_level' => true,
);

This is because the parser is effectively replacing the beginning tag with the "before" parameter, noting there's an open tag currently, and continuing on with parsing. Once it finds that closing tag (or the BBCode ends abruptly), it inserts the "after" content.

As far as I can tell, this doesn't happen for any other form of parsed content, as it recursively calls parse_bbc in those cases. I suppose it's far more likely for the actual content to have lots of recursive calls; e.g. a pile of nested quote blocks. But it's an annoying pitfall if you don't know about it!

This especially caused issues for me with the [noguest] tag, because the "validate" function is the core of it. So, at least at the moment, you can't actually use BBCode within that tag. I might just fix it by doing a recursive parse_bbc call, but I want to see what (if any) impact that has first.

Checking the poll results, and all of the "yes" options are tied. Hrm.

I think it's reasonable enough to start by splitting out the projects forum, and we'll go from there. I'll include this in the next announcement post, in case anyone misses this (I'll be making some changes on that front, too).

This is done, alongside the spoiler tag!

Logged-in users only

Sorry, this content is only available for logged-in users.

What game to choose is still open for discussion, but that might be another topic.

Done!

Here's an example:

"Spoiler Alert" by They Might Be Giants

whatever happens, there needs to be a forum explicitly for vibing. just imo

...ok idk exactly what I mean there either, but like, something that encourages a degree of silliness or chill or what have you. every forum needs a way for people to settle into the community and feel more at ease, which sometimes means letting loose a little, fucking around a bit, etc.

i think having a "Projects: The creative and/or clever stuff you're up to" type thing (indicating that it's not just for tech projects) alongside Chat might be sufficient for now without being too preemptive; if Chat starts getting dominated by another specific genre of topic again, we can always spin off another category at that time.