Wiki Updates (masochism?)

Love the logo. I think adding that is higher priority than updating ash.php?

StDoodle said:

stuff.

Click to expand...

GeSHi generates some CSS code, which gets applied to the page in question. So color of the links won't be a problem. Since GeSHi is written in PHP, and there's only so much I can do with styles, I think I'll have to modify the base. Which probably won't be too difficult. I'll see what I can do.

[where doing this man]

heeheehee said:

Love the logo. I think adding that is higher priority than updating ash.php?

Click to expand...

Well, I think getting most of the ash information to be placed (sanely) on the wiki is priority #1. Thankfully, everything that needs to be done as prep work has been done, and the rest is stuff where the changes would propagate when made, without any additional editing required.

heeheehee said:

GeSHi generates some CSS code, which gets applied to the page in question. So color of the links won't be a problem. Since GeSHi is written in PHP, and there's only so much I can do with styles, I think I'll have to modify the base. Which probably won't be too difficult. I'll see what I can do.

Click to expand...

The ideal thing would probably be to set up an additional wiki somewhere just to test this stuff out, so 1) we only had to bother fewyn when it was 100% done and 2) not take the risk of breaking the mafia wiki.

I don't, at this time, have any space to offer for that myself, but I wouldn't be surprised if someone here did.

But again, since it won't hold us up going forward, it's nothing that needs to be stressed over.

I have access to a whole bunch of server space that I shouldn't (attribute it to incompetency at my school, not illegal activities, heh), but somehow I think that setting up a wiki for testing wouldn't be the smartest thing to do...

But yeah, I'll look around for some testing grounds.

What do you need to actually test?

fewyn said:

What do you need to actually test?

Click to expand...

Well, heeheehee is going to try to modify SyntaxHighlight so that everything recognized as an internal ash function becomes a link to the function's page, which could possibly bork things if it doesn't work, I'd imagine. For just changing colors, yeah, no big deal; but the links thing seems like it could wreak havoc if there were any bugs.

Just keep passing me the files it won't actually break the wiki data.

fewyn said:

Just keep passing me the files it won't actually break the wiki data.

Click to expand...

Well no, not the data, but perhaps the way it's displayed. I just wanted to take the burden of testing off of you; if you don't mind, all the easier!

Also; heeheehee: when you do your next iteration on the parser, could you remove having single-quotes getting parsed as strings? Technically, they can be used as such, but it means the highlighter borks every time you have a single-quote used as an apostrophe in a string or location.

Here's the version without single quotes.

Lemme see... you'd want the first category to link to control structures, the second and third to go to datatype constants, and the fourth to go to each individual page (redirecting as needed)?
Edit: Oh wait, no, just the last one? Okay.
Double edit: Hmm... I wonder if I could force it to link just by modifying ash.php... Wait, no, I'm just being silly.

Added aggregate as a type as well, but that probably won't be used much.

Third edit: Fixed and tested. Should now work without any errors, I guess.

jason what font is that you used in the wiki logo?

fewyn said:

jason what font is that you used in the wiki logo?

Click to expand...

Gill Sans.

I got bored, so I whipped up a simple script parser to test out the syntax-highlighting. Since it no longer recognizes double brackets, the new version of ash.php might be compatible with the wikilinks. Yay! The innate linkage so far is actually a bit of functionality in the custom language file that I stumbled upon (I'm not completely sure if it works on the wiki itself), but limitations of this feature prevent me from doing the linkage for each function without bloating the file substantially. Since wiki-linking may or may not work now, we'll see, I guess.

Comments [on the highlighting]? (Should I add a new section for "ZLib variables"?)

heeheehee said:

(Should I add a new section for "ZLib variables"?)

Click to expand...

Seriously? That's script documentation. The wiki is for mafia documentation. As nice as zarqon's script is, it really shouldn't be documented on the wiki.

It's just that so many scripts use ZLib that I might as well have it link to ZLib's forum thread. So people won't be all like "Where the heck did this function come from and what does it do? It's not part of ASH! Ahhh!"

Loi. zarqon has become part of the mafia environment.

heeheehee said:

Comments [on the highlighting]? (Should I add a new section for "ZLib variables"?)

Click to expand...

I appreciate your work on this!

Comments: I wouldn't make dataypes into links for two reasons; 1) Too many links will be more of a clutter than a help 2) Each function page already has links to all relevant datatypes; it's not like they'll be super-secret-buried and 3) Wiki links should be (and as far as I've seen, automagically are no matter what you do) colored in the blue(link) purple(visited) red(missing) scheme that users are familiar with, so either you'll end up with most of the highlighted syntax being these colors, or you'll end up with links that aren't styled in line with the rest of the wiki (and every other major wiki).

As far as links in the highlighted code goes, I'd say just do built-in functions. I wouldn't include ZLib stuff at all; nothing against ZLib, but if we start using it in code samples (outside of a well-marked and away-from-normal-funciton-pages area), I feel that will cause more confusion among new users. I am, however, okay with including such functions on the wiki; as long as they are marked clearly as not-built-in (preferably by appending "(zlib)" to the end of the page name).

I'd avoid the red color (as that's a wiki's way of saying "missing page link"). Don't forget that, once the wiki is populate, links will be blue or purple, so that color can be used for built-in functions. IMO, control structures (if, while, continue, break, etc.) should have a different color than true & false (which could share with numeric valuse, and even basic text, as it's all values).

I realize the wiki color limits make things a bit of a pita, but there are still a couple of good color options available: grey (of some sort) is nice for comments IMO, you could probably manage both a lime/light green & a very dark green without the two looking too close, and... well, ok, that's about it for major differentiation.

Again, thanks for your efforts. (& sorry to be picky, but I needed a good long break from editing the wiki. )

StDoodle said:

sorry to be picky

Click to expand...

Instead of "being picky", let's call it "having a strong guiding vision." Sounds much better that way.

Hahaha, I'm ridiculously flattered by this discussion.

I'd also prefer ZLib stuff to be distinct from ASH. I'm fine with mentioning ZLib vars as an example for the file_to_map() page (or the mafia settings page) or something, but inclusion of ZLib should be restricted to code examples (actual code from ZLib functions, not calls to ZLib functions which are not defined on the Wiki). I also don't want to have to update documentation in multiple places when I change something.

Also, it's possible to style links with different colors; does Wiki markup prevent that? I'm not sure what's happening at the moment with this syntax highlighting / function linking.

I forgot that I had true/false as the same color as control structures. Heh.

Changed around some colors. Anything in particular you want me to change? (It's not really difficult to change stuff -- I've been using ColorSchemer's online color generator to pick out whatever looks nice)

I have no idea how wiki markup interacts with CSS styling of links. I think that SyntaxHighlight wasn't linking properly, but now that we can (hopefully!) use wiki linkage, we'll see.

Edit: Oh, and the highlighting of records? Total accident. =D

zarqon said:

I'd also prefer ZLib stuff to be distinct from ASH....I also don't want to have to update documentation in multiple places when I change something.

Click to expand...

Well, if you prefer that "one place" to be the wiki, I certainly don't have a problem with it, as long as you append (zlib) or similar to the end of page names. Actually seems like it might be a good idea; I picked up one code example when I was starting out that made use of a ZLib function and was frustrated as $%*# that it wouldn't work. Being able to find info on said functions at the same place as "normal" functions would be a nice bonus. But it's a wiki, so we can do it if you don't want to (but it's a bit down my list ).

Also, it's possible to style links with different colors; does Wiki markup prevent that? I'm not sure what's happening at the moment with this syntax highlighting / function linking.

Click to expand...

To the best of my knowledge, you need to do some complicated junk to re-style links. Wikis automatically parse anything they recognize as a link AS a link, so everything in your href= if you try to do a normal html link becomes a link, and you get trash markup. Yes, you CAN avoid this, but like I said, it's complicated. It's probably easier to get around this messing with things on the level of heeheehee's mods, but as mentioned below, why introduce the possibility of confusion?

The whole point of a wiki format is that it's standardized enough so that users have some idea of what to expect. Changing link colors defeats that purpose. (Sure, documentation is job 1, but making the documentation USABLE is job 2.)

heeheehee said:

Changed around some colors. Anything in particular you want me to change?

Click to expand...

Well, since I have this grand vision & all.

I would make datatypes a different color (that blue looks very similar to link blue). #00ffff?
The light blue-grey for variable names etc could probably just be regular black (I'm kinda used to "anything not recognized as part of the language is the 'default' color").
I'd make the string color more of an orange than yellow; I can NEVER read yellow-on-white. #ff9933?
Maybe darken up the pink of control structures slightly? #ff33ff?
Maybe even a slightly darker grey for comments, like #aaaaaa.

Okay, that last one's just plain picky.

Also wrong. #8A8A8A is darker than #AAAAAA. Heh. Darkened anyways.

The light blue-grey isn't actually part of the syntax-highlighting, but I'll remove it, if it's really bothering you. Other fixes have been made, but the #00FFFF is a bit... bright. Also removed the greening of the records (I realized that was a leftover from methods in Java, where I jacked the template, mostly).