RLE: Tcl user and one of the wikignomes.
Created pages:
LkpPo - Hi RLE, I see that you care for actively improving the wiki like me. Do you know who I can contact to report a bug in the search engine? The bugtracker is hosted on Google and I do not like the idea of having to create an account with Google! Thanks.
Hi LkpPo - RLE here, I just noticed your edit to my page. If you look at the bottom of the About the WIki page, it implies that Colin McCormack might be a contact that you are looking for regarding bug reporting.
LkpPo - Hi RLE, I'll contact him. Thank you for your help.
PYK - Hi RLE, I'm looking for a way to link to the page http::geturl
Any suggestions?
RLE (2013-04-01): Try this way:
Edit page to see. The problem you are encountering is that raw colon characters are not allowed in a URL (rfc1738.txt ). Linking to the page by wiki number gets around that limitation, and then using the wiki "rename url" syntax, you can make the link look like http::geturl.
PYK 2013-04-01: Thanks. The problem with that, though, is that the "what links here" mechanism doesn't pick up on those links. Even if URL syntax doesn't support colons, wiki syntax still could (and should) recognize such links. I've filed this bug regarding the issue.
PYK 2013-12-13: Hi RLE, on the [return] page, you removed the brackets around the inline Tcl code examples. Isn't it standard style to put brackets around inline code examples? If you look at AMG's comments on that same page, for example, they had brackets around the code examples prior to my edit. I'm somewhat on the fence about what the standard style should be, but whatever it is hopefully it can be applied consistently throughout the wiki. Maybe it's time to initiate a Tcl Wiki Style Guide.
AMG: Hate to say it, but you did it again with the missing close bracket. You have:
[[`[return]`]
Which should be:
[[`[return]`]]
This will trip up the wiki markup parser if there is a mismatched open bracket nearby, plus it's very confusing and asymmetrical.
PYK: AMG, are you sure it will trip up the markup parser? I've never seen it do so. Rather, I interpret the double left bracket as the way to escape the bracket, but the closing bracket doesn't need to be escaped. I tend to be minimalist about syntax, so why escape the closing bracket if it isn't necessary?
AMG: I did a test on Graffiti a few minutes ago, and indeed it matched a single open bracket from earlier in the line with the single closing bracket you didn't think needed to be escaped.
There's a difference between being minimalist and taking shortcuts. The wiki markup translation code emits a single close bracket as a failsafe when given a single close bracket on input with no matching single open bracket, but it's still an error condition it's trying to handle gracefully. If you want to be minimalist, simply don't use the extra markup features in the first place. You're combining three markup features in a way that's easy to be confused about. Just pick your favorite and go with it, no need to toss in the kitchen sink too. The trouble with adding features to any language, markup languages included, is that folks then feel obligated to use them, even if they got along without for many years. Witness C++...
PYK: But that's a different situation because it was already in a "link" context, so not relevant to the comments above :P I'm not sure there is any way to escape a closing bracket in a link context. I doubt the implementation is as you say, because it would be more straightforward for it to simply interpret [[ as a single open bracket. Witness the fact that a single ] anywhere in a page is not treated specially. It's the opening bracket that moves the implementation into a different state. However, this is where Tcl Wiki Style Guide would come in handy, because we could just specify "don't do that" in the guide.
PYK 2013-12-13: The problem with using italics instead of brackets is that italics are already used to denote placeholder values that should be changed by the user to the appropriate value for a particular scenario.
RLE: PYK I never even noticed that the original brackets were there. After you added the bracket overload edits I just assumed that all of the brackets were the result of your edits and set about undoing the resultant mess.
I find it interesting that 6 paragraphs up you state:
Yet, [having] square [brackets] around [every] possible [word] that [happens] to be a [tcl] [keyword] hardly seems [very] "[minimalist] [about] [syntax]".
In fact, it gives the pages to which you've made this change a look reminiscent of 1930's ransom letters where each letter/word was cut from a separate newspaper advertisement, and so the result was a hodgepodge of random fonts, sizes, etc. English prose does not normally contain loads of square brackets within its sentences. In fact, they usually denote a parenthetical phrase, i.e. "a construction that can be used to extend the meaning of a word or phrase but is not one of the main constituents of a sentence". Which makes reading English prose loaded with lots of brackets a significantly different, more painful, experience.
The words in prose that are Tcl keywords, that are also being used in the context of their Tcl meaning, should simply be links. Reading the prose with embedded links is significantly less jarring than [reading] the [prose] with lots [of] extra [brackets] [throughout]. Which is why I set upon removing the brackets. As for AMG's originals, I do see some slight use where a Tcl command plus arguments might be inlined within the prose itself. But to [bracket] [every] [instance] of [any] use of [Tcl] [keywords] is simply overkill. I.e., brackets, within prose, is a feature/style best used judiciously and with significant restraint. Because do to otherwise risks making the actual prose significantly more difficult to read.
Given that you indicate that there is no "Tcl Wiki Style Guide" yet, where is this rule written down? Italics, like boldface and fixed width font, are styles of emphasis. More often than not, the meaning of any particular emphasis is conveyed by the surrounding context, and/or through that which is emphasized. I.e., this:
binary format H* input_string_here
indicates the "placeholder" via the name used. Adding italics to "input_string_here" simply makes it stand out more, but the above is not any less indicative of a placeholder by lacking italicized text.