Use the HTML entities encoded form:

• [ is represented as [
• ] is represented as ]

Update: Here's a one-liner that will help you to figure out what the HTML entities are for particular characters. It's easy to tinker to test other symbols too:

perl -MHTML::Entities -e "print qq/$_\t/, encode_entities( $_, $_ ), 
$/ for split //, shift" "[]<>"

__OUTPUT__
[       &#91;
]       &#93;
<       &lt;
>       &gt;
[download]

Beware shell interpretation of the symbols you test. ;)

When I'm feeling lazy in the ChatterBox, I use "[[]" for "[". For example, "[[]test]" gives "[test]". "]" doesn't need escaping, with or without this trick.

Update: Oops, this should have been a reply to the OP.

They work fine, and in fact I use them most of the time when I want to quickly toss a [ and a ] into a paragraph somewhere. But the lazy solution has its drawbacks.

First, the "download code" link will also download all those [ and ] characters into whatever legitimate code you're downloading. Second, the contents between code tags gets rendered in a different font by most browser configurations.




Dave

pmdev - how hard would it be to implement backslash-escaping, a-la "\["? That way, we can use the same thing for \< and \& ...

Can we just add an entry in the Help section? I did look over there.

I like the idea. However, a question does not make a spec. ;-)

• What if I actually wanted a backslash immediately preceeding a PM-link?
• Do we do anything to any other backslash?

My proposal here would be to ignore all other backslashes, and if you actually want a backslash right before a real link, you HTML-escape that using &#92; "\" - this should be so rare that this extra bit of work would be an appropriate Huffman coding level for it ;-)

The other question is who would use this? We have to understand that we're not making newbie errors less likely here. We're just simplifying the life of those who are experienced and newbies who actually read the documentation ;-) I'm ok with that, but only as long as everyone understands the scope of the change and doesn't expect anything more.

After that, though, there is another whole level of work to getting this into the PM code, methinks. I have already found a couple places that would need changing. I imagine there's a half-dozen or so places to do this. So it's just a matter of finding them all, and either changing them all, or changing them all to call a common routine. But figuring out what precisely is desired/desirable is always the first step.

Yes, that is a better specification. And it reduces some of the problems with a naive approach. But it also doesn't match the original request which called for \& and \< to work.

But I'm still reluctant to support such a scheme because it doesn't match anything else. It is rather oddball compared to both what the site supports and to what Perl supports (and making it match Perl closer makes it too much of a backward compatability problem). It also doesn't fit in with the processing (HTML-filtering) scheme already being done so it likely has a higher performance penalty than other alternatives.

I'd rather move forward with older proposals for improvements such as 1) supporting some of &lb; &lsb; &lsqb; or whatever the list was (plus the s/l/r/ partners), 2) Switching to using [[ ... ]] for making links, 3) making a user setting such that [link] gets displayed as "[link]" instead of "link" (users who have no problems remembering how to escape square brackets can disable the setting), etc. These also introduce backward compatability issues but the work for addressing them is better justified because they are more general solutions.

The amount of work involved just doesn't seem justified to me for such a oddball solution to a single problem that already has several solutions (that each are part of some bigger scheme that solves more than just that one problem) and several other (less one-off, less oddball) alternate solutions proposed. Such "bolted-on" fixes tend to pile up and make a system more fragile, inconsistent, hard to understand, etc.

I'm least opposed to having \[ (and maybe \& and \<) work in the public CB. That greatly reduces the processing overhead problem and restricts the backward compatability to monk habits (in a way that should only very rarely be noticed). I was originally thinking that supporting \& and \< would be good because it would mean that \ at least solves more than one problem, but \& appears fairly frequently in Perl code and I've already eliminated most of the problem with unescaped <'s (I didn't even bother to escape any of my <'s in this node) so I'm back to thinking only \[ should be special.

This would address the primary location of the problem (in my experience). Since I've actually seen several people try \[ in public chatter, I think it would be helpful there.

Going down that road a bit further, in order to implement it for the public CB without impacting the filtering code, we'd need to process \[ before processing links. So we'd do CODE tags, then m/\\+\[/, then links and HTML filtering. That might work well. I'd appreciate comments, especially from monks with lots of experience on the site.

- tye        

Eh, why? What's wrong with just using the html entities.. which already work? I suppose you save a character or two, but hell, we're using html, which isn't known for it's concise mark up. Tye has already pointed out the ridiculous amount of work needed to implement this change that merely saves a character.

And then we'd have to allow escaping of backslashes which would then lead to all these questions about how to get backslashes...

Are you going to write the code to fix all of the old posts so that they aren't fouled up by the new, very short meta character that you want to introduce?

- tye