its a simple work round.

and works nicely. As long as you don't use TOC

This is a great example of how a simple workaround can lead to a new feature request. Thanks to Phil's brain realizing that this workaround can mess up a TOC, it seems we could use a "levels" setting.

Something like [[toc levels="3"]] to stop the TOC listing at H3. Personally, I rarely use TOC (or first line indenting), so this would not be a big deal to me either way, but it seems like it might be useful for more things than "working around a workaround".

From one can of worms to another!

-Ed

He seems to be really good at figuring stuff out using methods you normally wouldn't think of, doesn't he…

Methods such as actually reading the wiki syntax carefully and cleverly… :-)

James Kanjo deserves a promotion…

To what exactly? He is an admin of this site, he is a pro, for free, and I can't think of anything higher than that… But seriously, what would you promote him to? (developers team, maybe)

Did you see the picture…?

I was on my ipod, and missed that.

Also, How do you get the Life's Handbook logo. I was never told that.

Ghrgh. I'm not admin of the profiles.wikidot.com site. However, putting [[module Rating]] onto profiles.wikidot.com/profile:_template seems like an interesting step.

We are all wiki pages, it seems…

(I never even realized there was a profiles site until the bottom toolbar showed it randomly for a week or two… :-)

> I never even realized there was a profiles site

Neither did I. But this made me think whether profiles.wikidot.com could be used to count how many registered users Wikidot has at the very moment.

A stress test for the Count Pages How-To code? See what I did ...

It seems that ListPages can handle up to 50.000 pages (although taking quite a few minutes), but not the 356.545 profile pages that we have 31 Jul 2009 22:00.

There's also another issue with order="pageLengthDesc" or order="pageLengthAsc" taking much more time than any of the other sorting options.

KANJO… kanjo… they cry! WTF! OWN GOAL :-( :-(

Helmuti is back in the game, and the game is on!

Oh fromble tomble.

Well, an unideal workaround is as follows:

Normal text line starting at the begin. Now will follow a next paragraph.

blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah

Code:

:   : Normal text line starting at the begin. Now will follow a next paragraph.
: blah, blah, blah...blah, blah : [!-- --]

Alternatively, you could use CSS to unify the paragraph settings across your wiki:

p {text-indent: 5%;}

But you've already expressed your disinterest in CSS.

Personally, in my opinion, Ed's solution was the best. There's no real justified reason to avoid using div blocks.

Just to remember what I posted on 20 Nov 2007 and this howto:embelish-text:examples…

I can't use CSS because it indents everything that isn't prefaced by some other syntax like + or *. There's no reason that I can see that we can't use ^ as a simple way to indent a paragraph selectively. * by itself starts a list. ** is an indented part of that same list, whereas **this** comes up bold. So there's no reason that we can't use ^ to indent paragraphs and ^^ to create superscript.

^Test^ <— Doesn't do anything either, so it's not stepping on any toes there.

How would I redefine the existing syntax for H1 with CSS? I never use a single + for headings, so it would be useful for me to redefine that one. It's a workaround but a messy one.

I would suggest something like h6 because site headers are usually in h1. But if you do decide on using h1 put the following into your custom CSS (making sure it's after any other h1 rule):

h1 {
    font-weight:normal;
    text-indent:25px;
}

Rob

What do you mean site headers?

I tried that Rob, but the h1 is showing up in the large size and redefining the size isn't work.

The site header is the title of your site displayed at the top of the page. On this site it's

Wikidot.com Community Portal

One way to avoid affecting all H1 elements, is to narrow the scope:

#page-content h1 {
    font-weight:normal;
    text-indent:25px;
}

-Ed

I tried that Rob, but the h1 is showing up in the large size and redefining the size isn't work.

Put the #page-content in front of the h1 and it will work.

-Ed

The problem was that h1 { } by itself wasn't changing anything but indenting it. Adding the #page-content however, allowed the font size to work.

Thanks Ed, I should have picked that up.

Rob

Thank you both. The redefine of + for indenting is working wonderfully and I also managed to figure out how to alter some other elements of my new D&D campaign wiki to suit my tastes better. =) The only problem is that now I can't use a table of contents on any page I indent paragraphs. A small price to pay but worth for the aesthetics. =^.^=

You're welcome. But please don't use the syntax =^.^= which puts the text upside down! :)

ɯıɥ ǝʌol llɐ ǝʍ puɐ poƃ ɐ sı ɥɹǝʇǝıd

Rob

I think - a +* ( one header + plus an asterisk) should stop the ToC inclusion.
- you should try this on a test..

Hä?

ɯıɥ ǝʌol llɐ ǝʍ puɐ poƃ ɐ sı ɥɹǝʇǝıd

Good joke!

ɯıɥ ǝʌol llɐ ǝʍ puɐ poƃ ɐ sı ɥɹǝʇǝıd

¡ǝsɹnoɔ ɟo 'ʎʇıuıʌıp sıH sǝıuǝp ɥɐıssǝW ǝnɹʇ ǝɥʇ ʎʃuO ¡ʎuunɟ ʎɹǝʌ 'ɐɥɐH

All I see is a bunch of gibberish and boxes. I guess internet explorer 6.0 can't recognize whatever font or html/css you're using.

Ah, internet explorer 6. Yes you miss out on so much modern browser functionality. We were displaying text upside down which is just a silly little trick.

I hate IE 6, it just causes too many problems these days. I would strongly recommend you upgrade to IE8. I would say the same if you were using Firefox 2 when we are now onto 3.5+. There's little reason to remain on older browsers unless you are told to as some sort of policy by the neanderthals in corporate IT.

Rob

There's little reason to remain on older browsers unless you are told to as some sort of policy by the neanderthals in corporate IT.

Or, in the case of the restaurants I support, forced into IE6 because we can't install anything newer on Win2K machines (once the economy improves we're planning on some hardware upgrades). Thankfully, Firefox works great, so I make sure everyone uses that for our wiki site.

-Ed

Oh, I hadn't thought of that issue Ed. I'm lucky that mostly I get to use more modern browsers on (slightly) newer computers, and if not I have Firefox 3.5 mobile on my USB stick. It must be a headache for you to still have Win2K machines. But at least you can use Firefox. Extra pepperoni please.

Rob

Yeah, at work… IE6 is the default and their IT dept set it up so that you can't install anything else and if you manage to, it uninstalls and deletes it when you log in. Haven't tried any usb drive portable browsers yet though.

I don't think that's a bug.

But what IS a problem is that there seems to be no obvious simple way to interpret the include line literally.

I don't think that's a bug.

I think it is a bug. Code blocks should always display the contents as-is. In other words, the parser should ignore whatever is inside and just apply the blockquote formatting to it.

-Ed

Code blocks should always display the contents as-is.

I still disagree. Including code has been very useful on pages such as the poll — if I change the code on a poll include, I need not have to change the code on the poll page.

On second thought, it would confuse some Wikidot users if the content is included in code blocks. As you say, one should be able to assume that code blocks are safe from the parser.

Also, an include statement of an include statement is also brought up — not great at all.

Interesting "Include" discussion

I wrote:

I think at the moment the includes

• are not working in Forum threads - THIS IS GOOD! ( think if some people would like to insert big pages..)
• are rendered aind exchanged by the included content in Code blocks - this is NOT so bad…

I would NOT change this behaviour now!

• but the documentation should really take a notice about this fact..

And an interesting answer I can quote here from Ed Johnson:

I would NOT change this behaviour now!

Since it seems to be in use so much right now, I have to agree. Maybe if Michal can figure out a way to not parse the includes inside a code block, then some kind of option switch could be added to the code syntax:

[[code type="xxx"" includeNoRender="true"]]
(or whatever makes sense)

-Ed

I think, this is a good idea to use the behaviour NOW as a default attribute and sometimes the includeNoRender= as a switch if we need another behaviour..

@James,

It seems the more we discuss this, the more we're both moving to a middle ground. ;-) I can see why you like it as it works now and you now agree with me that a "parser safe zone" is a good thing too. At this point, the main thing is to get a little disclaimer on the wiki syntax page.

-Ed

I've added clarifications to the doc (both in the code block and the include sections).