A hierarchical view of all pages on the Wiki (yes, this would be a tree with circles in. It would have to be plugged into the update script, to change itself whenever someone adds a link to a page. (Emperor)
Currently, the [list of full links] (which is what I'd end up using for input data) and the [index of all pages] are regenerated every time rather than cached (which is why they take so long).
I'd like one of these too. I even reckon I know how to write one. I have something similar I wrote about four years ago. However, this would require me to generate images on the fly, so probably won't happen until after Christmas. Meanwhile, what would people find more useful - a Perl one that generates a big 2D graphical mess, or a Java one that lets you fly around a neat 3D chart but runs only in Netscape 3.141, on February 29th, if the moon is crescent-shaped and purple? - MoonShadow
Hmm, getting it to output something that [graphviz] can use as input would be an idea... -- Senji
Can we have more punctuation available for generating game boards please? Or a list of what is available, but things like * , # _ would all be useful.
MoonShadow: poo. This seems b0rked, and I can't tell why. The only characters my code explicitly excludes are " " and "=". Some markup gets interpreted beforehand, but that should only result in "<", ">;" and "&" being excluded, as far as I can tell. This will have to go on the back burner until I have time for a decent-length debugging session.
TODO
Open feature requests for Wiki script go in this section'
MoonShadow: How about an action that reads the Wiki database and uses a [Markov chain text generator] on the resulting text to produce a plausible-sounding page (which would not be saved)?
Two requests, one easy, one, probably, hard. (wow, how many commas can you fit in a sentence?) Could the 'Last edited____ dif' bit be moved to the top of the page? Quite frequently I abandon hope of finding the amend that has been made on a long page and just scroll down and hit diff. Once you are viewing the 'diff' page, could the amends shown be 'a' linked to their actual position on the page? - Kazuhiko
We can do it together on Saturday if you like ;) - MoonShadow
Nyo. I thought you'd realised by now that I only pretend to be a programmer... Of course, the real skill comes in getting the computer to believe as well... - Kazuhiko
AlexChurchill would really like this too. Links to Diff and Edit at the top of the page would significantly decrease my WaitingForWiki?.
Ditto - long pages can take a long time to load - especially annoying when all you want to do is revert to a non-spammed (and thus non huge) version. Would be better to have a copy than a move. --Vitenka
When an UnReified? link is postpended with a quotation mark, can we make that question mark become the link, rather than adding an extra one? So that PleaseDoNotReify? doesn't become "Will you reify PleaseDoNotReify??" --Vitenka (CosmeticImprovement?)
Yes, in principle. I'll have to think about exactly how to do it, though, because the decision of how much text to suck in and pass down to the link-munging code has already been made by the time I know whether the link is going to be reified or not, and I don't want to make the code uglier than it already is. Best way seems to be to always suck in question marks and then alter all cases but one to discard them again. - MoonShadow
Whereas AlexChurchill would vote against this one. I mentally edit out the BlueQuestionMark when reading, and such sentences would end up looking as if the author hadn't finished them. --AC
Because I know you don't have much to do already ;)... would it be possible to fix the diffs, so that they don't show up lines as having changed if all that's happened is a newline added at the end? --AlexChurchill
[fix ISBN link - it shouldn't need a colon, should it?] - AlexChurchill's revision comment on Kanji, vs "Typing ISBN in upper case becomes a link without a colon." - Vitenka, /ErrorReports. Guys, I don't want to have to change this behaviour every week. Which do we want, and which is erroneous? - MoonShadow
Eeep. Sorry. I had neglected to remember this changed behaviour. Requiring a colon is absolutely fine, I was just forgetting ItsNotABugItsAFeature. --AC
Well - it should only accept real (looking) ISBN?s. ISBN followed by a space shouldn't make a link. --Vitenka (I'd say ISBN:123 should link (but only the 123, not the word 'should'!), ISBN123 should link, but 'I'm now talking about an ISBN here' should not.)
The problem with that is, I want to use the Amazon links for all Amazon stock, not just things that have ISBNs. The things Amazon uses instead of ISBNs have the same number of characters, but are not limited to specific character classes. There is no way to stop "ISBN thingammyjig" linking since there is no way of telling "thingammyj" from a valid Amazon product ID. - MoonShadow
So can't ISBNtingamyjig make a link, but ISBN thingamyjig not? --Vitenka
We could do it that way, but it's not very intuitive. The reason I currently pull in things containing spaces and dashes, allow a space after the word "ISBN", and used to make the colon optional, is because they are written that way elsewhere, and I wished to forestall revision comments like AlexChurchills?, along the lines of "I copy-pasted this ISBN and it's not linking", or &quot;I copied this ISBN verbatim from the back of the book, dashes and all, and it's not linking". I was trying to cut down on "how do I link to ISBN" questions by making the links just happen when someone typed in an ISBN in whatever way they felt like. The experiment seems to have failed, though, since people tend to ask the question anyway - even when there are examples around right next to where they're editing - so maybe we ought to do that. MoonShadow
I don't know how possible this will be (it could be trivial, or it could involve brain-exploding rewrites of the Wiki stored data format). How about colouring text according to the person who wrote it? It would be done on a line-per-line basis, and the colour could be just a hash of the username if available or IP address if not, mixed towards black a bit. It would make reading long conversations easier. --Admiral
It should be fairly easy to do if the colourings were added from this point forward - just a change to the edit stuff. It may be a bear to do retroactively. But I'm not sure it would be a good idea - it's bad enough that I already have three hostnames, colouring to those would be bad. And no 'just log in' isn't an answer - I already sign my posts when I remember. Luckily if this was done I wouldn't see it, but if other people saw it and it positively made it more difficult to tell I had written stuff it would be bad. It might be nice to save us having to sign ChiarkPerson and Plasmon person posts. I'm sure MoonShadow will comment on the difficulty (or otherwise) of actually implementing it. --Vitenka
I'm thinking it's more likely to help than hinder, and one can always have an option to switch it off if you find it annoying. As for editing from several machines, one could always tell MoonShadow which IP addresses you normally use, and he can hardcode their colours. Retroactively, I would be thinking something along the lines of "cvs annotate", but that doesn't quite fit the current user/IpAddress? paradigm. I admit it sounds a lot easier to just do from here onwards. --Admiral
You misunderstand. I can turn it off (And have, globally. My browser is monochrome and proud of it.) What I can't do is get other people to turn it off when viewing my comments. --Vitenka
Yay. I have a monochrome monitor at home. They're fun. It's also the biggest monitor in my possession. --Admiral
Not practical to do retroactively as stated, I'm afraid, and probably not practical in general. Metadata is currently stored on a per-document per-revision basis. At the moment, diffs are not stored - they are generated on the fly as and when required. I simply do not have the time to make the sweeping changes that would be necessary to store per-line metadata - there are much simpler and less controversial changes on the request list that have been waiting for an implementation for a very long time now (autogenerated contents, for instance). I've been considering writing something to allow people to do coloured diffs over a small range of revisions rather than just two, which would have a similar effect to what you propose, but that would be too slow to use over the entire revision history and/or as a default browsing mode - consider what would be involved in colouring TodayIAmMostly, for instance. There are other issues - how do you propose to handle spelling and grammar changes, for instance - who do they get attributed to? What about if multiple people edit the same unit of text? - MoonShadow
On a slightly more inflammatory and less technical note, I would say I agree that deeply nested conversation on a webpage is ugly - but the answer for a wiki is not to make it into a web BBS, it is to split the conversation up and/or refactor it. If a conversation is getting too difficult to read, perhaps it's time to summarise it into a list of points made and restart discussion on each of those separately. I'd say the aim ultimately is to condense results of debates into readable articles or FAQs, and encouraging deeply nested discussion is counterproductive to that aim. Long discussions tend to recur or go round in circles - people forget points that other people made earlier, and newcomers who might read a brief summary or precis that catches their eye simply don't bother reading long intractable debates before they post. I see wiki as the answer to this - old discussions should get condensed, so that points are always easily accessible. Yes, this involves work on someone's part, but so does changing the wiki script and I think the outcome of refactoring could be rather more useful :) Wiki is not a newsgroup or a BBS, and attempting to turn it into one would miss the point. Would people be happier with a ["proper forum"]? If so, we should switch the tools we use. - MoonShadow
Heck no. Probably because this is my first wiki, but I do not want to go back to enforced threading and other broken conventions. (The obvious answer to 'who' for each character is the last person to emplace it. The 'how to do it' has no obvious answer though) --Vitenka
One fairly simple way to implement it would be to prepend each line in the stored page with a colour encoding (something like :colour#004512:) when it is written, which gets transformed into coloured text by the displaying engine. When one edits the page, the colour encodings are stripped out to give the text that is placed inside the edit box, and when the change is saved a little fiddling with diff/line numbers will put the colour encodings back in their proper places along with the new ones on the new lines. Of course already existing pages would not have the colour encodings present, so they would be merely shown in default colour, until some new lines are made. --Admiral
I respectfully think this is a bad idea. There are serious practical problems (if I correct spelling in some troll's paragraph, do I get blamed for writing it? What if I delete flames, or tweak the meaning in evil fashion, or inline answer a question?), and also philosophical problems (part of the Wiki concept is that a page doesn't have a single author to get credit or blame; ReFactoring? is pretty incompatible with the proposal; and so on). I agree with MoonShadow that some of the old arguments are long overdue refactoring. Maybe I'll do MagicTheGathering or StarCraft sometime soon. --AlexChurchill
Sure, if someone donates a powerful, modern machine to do the webserving ^^; - MoonShadow
You could do something like this without requiring anything clever on the server by putting in different CSS for different levels of indentation; so DL { color: #660000; } DL DL [ color: #006600; } DL DL DL { color: #000066 } and so on. It wouldn't tell you who said what, but it would make discussions easier to follow. --SGB
You can already supply an arbitrary URL for a stylesheet in your preferences box. I could do with going through and naming the outer blocks of all the different kinds of generated pages though. - MoonShadow
Would it be possible to connect the preview and diff scripts together to allow a "preview diff"? Not an urgent request, but I'd find it very handy sometimes. It would allow revision comments to be significantly more meaningful in some cases. --AlexChurchill
Yes, that should be feasible in principle - I'll add it to the end of my long list of things to do.. - MoonShadow
Maybe some kind of spoiler markup that produces white on white or black on black text that you have to click-drag the mouse over to select the text in order to read it? It should be easy to implement and fairly cross-browser compatable. The only downside I can think of is that anyone editing the page would be able to see it so it could only be used for very minor spoilers... --K
This particular method does not work on all browsers. Mine, for example, would IverseVideo? the text - turning White-on-white into Black-on-black. You also have the problem of wanting to obscure the diff - which is going to be hard unless every spoiler line gets tagged as such. --Vitenka (I'd like something, I just don't see an easy solution)
I was thinking of something like:
<nowiki>Wait until you see the bit where [Spoiler:nothing happens]!...</nowiki>
...producing one of:
Wait until you see the bit where [Spoiler:<font color="#ffffff">nothing happens</font>]!...
Wait until you see the bit where <font color="#000000" style="background-color:#000000">nothing happens</font>!...
* Each page has a "rot13 this text" box next to the search box at the bottom. If JavaScript is available, this is done locally, otherwise via a submission to the server.
* People wanting to read a spoiler copy/paste the gibberish into the box and hit the rot13 button.
* People wanting to write spoiler text copy/paste the text into the box and hit the rot13 button, then copy the text, edit the page and paste it in
* As a shortcut, text in <rot13>..</rot13> tags will be rot13ed when the page is saved, losing the tags and original text from the source.
Seems to solve the diff problem, the colour problem etc.. at the cost of being slightly more inconvenient. Thoughts? - MoonShadow
I like it. It's elegant and relatively simple. The last point (rot13 tags) is a particularly nice touch - at first glance I did wonder if it would cause code munging to an extreme degree (since I had assumed that not much was done before saving) - but since MoonShadow suggested it, I suppose it's not too bad. Gets my vote. Could perhaps have <rot13> and <spoiler> as interchangable tags, as it might be used both as spoiler and also for more geeky things? --ChrisHowlett
Dunno if it's finished yet, but hitting the Rot13 button whilst on the recent changes page does odd things. It turned my viewing the last 2 edits (angela raynors ones) into two days instead. Which was odd. --Vitenka (Wondering quite how the tiny box is going to be useful enough for movie or game spoilers)
Could we have a ROT13 box on the edit page as well? Sometimes I'm in the middle of an edit and want to write something in ROT13 and have to open a new tab to get to the ROT13 box. --Rachael
A page which lists the 50/100/? oldest pages (i.e. the ones which have not been revised for the longest time.) --K (thinking it might help with dredging up old things to refactor or maintain)
Works fine, but would seem likely to aggregate a very large number of deliberate LeafPages? - things like HAND which will probably never be updated. --Vitenka (Request an easier way to get to the next 100, rather than getting the lot?)
The $$CONTENTS feature is buggy. See LinuxBox/TechSupport. I think the code which inserts the contents table is still processing the unreified-page-? and so borks the link.
Some kind of anti-cheat counter for games? I'm thinking of BNF but maybe multiplayer AJAX stuff would need it too. Whilst you can verify by posting a move, you need something similar to a DiceRoller? protection of listing all the attempts, to stop people rolling until they get a favorable result and then posting that. Totally completely unimportant, of course. --Vitenka
You're thinking for the m:tg generator? Each BNF page includes a hidden seed in the HTML, which one could use to verify something really is generator output. BNF generators get a *lot* of activity, so not sure I'd want to keep any kind of persistent log of it for any significant length of time. - MoonShadow
I am indeed thinking that. It's probably overkill though. Probably no-one would ever check it. --Vitenka
The little orange tag for an rss feed seems to have become a DeFactoStandard?, perhaps the 'subscribe me' link should use it? --Vitenka
On the diffs linked from RecentChanges, would it be possible to have the author named? I follow long conversations by opening a load of tabs, so it's hard to refer back, and it's hard to tell the difference between a person who's forgotten to sign and one who just doesn't. So, where it says "Difference (from revision X to revision X+1)" at the moment it could say "Difference (by SGB from revision X to revision X+1) --SGB
It's not incredibly important, and I'm not sure if anyone else has the same problem, but the number of times I've tried to sign myself as --~~~ or --~~~~ (a la MediaWiki?) and then had to correct it is getting silly. --qqzm
Screen resolutions are (in general) much better than they were when ToothyWiki started out: can we have a taller edit box? 40 rows fits easily on a 1080px-high browser window, or 30 rows on a 768px (which is my home monitor, and about the smallest I've seen these days). I think you may be able to control the text-area's height with CSS, although it will still need a rows="" attribute, which would even allow media queries if you wanted to be very fancy. --CH
You can change this already on your [preferences page]; under "Misc", you can set edit area rows and columns to whatever you like. --MoonShadow
![[Home]](/img/text_logo.jpg){kind=logo}
ToothyWikiInternals/WikiFeatures