Re^2: How to escape square bracket in PM?

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 \ "\" - 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.

Comment on Re^2: How to escape square bracket in PM?

Replies are listed 'Best First'.
Re^3: How to escape square bracket in PM? (specs) by tye (Sage) on Apr 13, 2005 at 02:48 UTC
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; [` 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	[reply] [d/l] [select]
Re^3: How to escape square bracket in PM? by BUU (Prior) on Apr 13, 2005 at 00:21 UTC
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.	[reply]
Re^4: How to escape square bracket in PM? by Tanktalus (Canon) on Apr 13, 2005 at 00:34 UTC
What's wrong with just using the HTML entities? Rather than using [cpan://File::Spec], just use <a href="http://search.cpan.org/search?mode=module&query=File%3A%3ASpec">File::Spec</a>. Or, instead of using magic <code> tags, just manually escape all the special characters in your code. Someone made the horrific mistake of getting us hooked on this HTML-for-dummies approach of writing on this site, in ways that made sense for perl programmers. dragonchild's question is just along the same lines as everything else we have here to make our lives easier in things we do all the time (refer to documentation, CPAN, ISBNs, other nodes, other users, other sites, etc.). One thing we do all the time is put brackets (square brackets for those who prefer) in our text. It's not unreasonable to request it. And I'm not sure it's a ridiculous amount of work. A significant amount of work, yes. But I'm not so sure about ridiculous. The amount of work is hugely dependant on the specification. If we need to now go and escape all backslashes, yes, that's ridiculous. Maybe more. If we come up with an idea that is a bit more compact, then it may not be nearly as bad. It's not as easy as, say, changing where doc:// tags or cpan:// tags point at. But it's just a matter of finding all the places that link handling is called, and mucking about with the substitution regular expression a bit.	[reply]