Ah, there was an XHTML error in the cutesy capcode, and of Safari won't handle XHTML correctly and die on errors. Gah. Fixed.
>>216
I remember at least one or two boards on 2ch that used it, though I can't remember which (moon language and such, you see).
I apologize for the dumb question I made at the end of >>218. I forgot that Kareha permasages (not closes) a thread after the limit is exceeded, so there's no need for a hypothetical 1001th post anyway! orz
> Put the Entire thread link on the top of the thread, not the bottom.
Well, since the current update has removed almost all links to entire threads, I won't do THAT, but I guess a Last 50 link could be snuck in somewhere... Maybe the thread title should be an l50 link?
About the etyomology of "fusianasan":
http://4-ch.net/nihongo/kareha.pl/1102656968/224-
Should be fixed now.
Kareha can't use different layouts for posts on different pages, except by CSS trickery. I could add the second colon, though.
Also, I've implemented optional thread closing now, but there's no extra post. That would just be a total mess to implement, and would make re-opening threads annoying, if such a feature was requested. It replaces the posting form with a notice that the thread has been closed, instead.
GDLib for thumbnails: http://wakaba.c3.cx/sup/kareha.pl/1113869490/5
Congratulations to 82.94.251.206!
So the subject line will look like this:
[username]<><>[unix timestamp from now]<>[content of comment box]<> <>[IP]
>>48-50
First of all, I don't believe it would make bumps more valuable in any way. People bump threads all the time with worthless replies since most don't even know what "sage" is or means or what it is good for. They will simply continue to do this, no matter whether the sage function is changed in this way.
Even at this stage, years after its introduction to a major western userbase, people are still clueless about the main basic functions of image- and discussionboards in the Futaba/0ch style. There are some signs of improvement, but they are rare.
I doubt people would be willing or eager to learn a new, different behaviour at this point in time.
The only real change is what >>50 points out (though I want to mention that even that point is mostly misunderstood: if people want to protest against a certain thread, they should post as many sage posts as it needs to get permasaged (although it's arguably counterproductive, considering the default prune behaviour of imgboards). If threads are still bumpable and trolls find that they have been flamed with a sage, they will just bump it once more). And I don't think that's enough to justify a pretty major function change.
requesting features:
>>n and >>q and anything else that can be used in the url.
>>157
So the functions need to be hardcoded to a post element one way or another? If I wanted to, let's say, create a template for gazo-box or Shiichan (both use checkboxes for sage), I'd need to slightly modify kareha.pl to check that new checkbox input instead of the Link string input?
An interesting limitation. Thanks for explaining.
About permasaging/deleting after a certain thread filesize is reached: would this be the same as a limit on the total number of characters in a thread? Or would we also include WakabaMark formatting, hyperlinks (including navigation), name/date/title headers, reply boxes, and non-Unicode characters in the formula?
>>158
Chances are that most if not all major/fundamental changes made to Kareha's core scripts will clash with the philosophy of most people here (including WAHa), and they won't care for them anyway. There really aren't all that many big-bang end-user features left to be implemented in Kareha before it loses its minimalist charm.
P.S. Reminder for >>85
First thought: It would eliminate the concept of sageing as a protest entirely.
>considering the default prune behaviour of imgboards
One of the parameters Kareha uses to determine pruning is MAX_POSTS, so even if you sage a thread under this new condition, you still add to the board's total postcount and speed up the process for pruning that thread, regardless of MAX_RES. The only flew is this assumes pruning is based on thread creation date, not popularity (because someone could easily bump a shitty thread and save it from deletion).
I also agree that enabling this functionality would further make threads vulnerable to intentional bumping by trolls. I was sorta envisioning it being used in a mature community where trolling is minimal and quickly weeded out by regulars.
Here's a new idea: how about trying this in reverse? Only "sage" posts are counted in MAX_RES, in which case saging can again be used either in protest or as a courtesy to others. The only problem is that people can then freely bump threads without consequence.
Yes, it's throwing Javascript errors for me if I use that character. Gonna look into that some more.
Oops, here's the screenshot. orz
Apparently it's not Japanese, because it's supposed to be pronounced as an English word. I have no clue, though.
>>178
There will always be pranksters around. This is probably a good example on what matters to trust tripcoders more than anonymous contributors.
Trivia: Here is a list of 2ch kopipe to fool people into using fusianasan:
http://ansitu.xrea.jp/guidance/?fusianasan
I have always found that it's more difficult than one would think to implement features that will measure "popularity" in a satisfying way that isn't open to abuse in one way or another.
>>137
I'd advocate going for a separate interface a-la Wakaba, but it might be a bit too much to do for this release.
Also, maybe Easter Eggs like the Eternal September timestamp and others (if they exist) should be documented in config.pl.
Lastly, a question: who here finds enough use in the auto-expanding comment box to justify the annoyances when you click in or out of it?
> Right, I guess it was dumb to mention 0ch/Futaba in the first place. The point is, as you said yourself, tripcodes are a gimmick, and if someone wants to maintain a persistent identity across multiple boards and sites (ie, everyone here with a tripcode), they have no choice but to use ordinary tripcodes. Secure tripcodes are useless because they limit your identity to a single board, supposing each board/site's cipher key is different -- which it should be, since that's the point of having a secure tripcode in the first place. No one should be so paranoid about a tripcode that they'd need to have a different one per board/site.
True, they're of limited usefulness, but people like admins might prefer to use them. And there are certain cases were you might use them temporarily for various purposes. I wrote the code already, so I might as well leave it in. It has some uses at least.
> Shouldn't we sacrifice some backwards compatibility for a more robust and scalable design? It might even be possible to provide an upgrade.pl for old threads.
I think I'm too lazy to do it. It's kind of hairy. Besides, as I said, you can remove a lot of the drawbacks of seprate installations by using symlinks.
Well, a lot of machines run on x86 these days, so that covers a lot of it. And you could pre-compile for a couple of other architectures, and have it pretty much covered. Linux and unixes in general make it ridiculously hard to distribute binaries, as opposed to Windows or Mac OS, but it's still possible with a bit of trickery. Avoiding dynamic libraries helps a lot.
This is the obligatory encoding test ... in <code>
㋋㏡
ゔ〲〰 ゔ〲〲〰〰 ゔ〲〰 ゔ〲〰 ゔ〲〰ゔ 〲〰ゔ 〲〰ゔ〲〲〰ゔゔ
〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰〳〵ヷヷヷヷ〰〰〰
(♛ฺД)(*゜∀゜)~♡ℳฺℴฺℯฺ❤ℒฺℴฺνℯฺ..._〆(゜▽゜*)㌰㌰ ㍉㍍㌧㌔㌶㍊㌣㌦
㌀㌁㌂㌃㌄㌅㌆㌇㌈㌉㌊㌋㌌☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ ☠ฺ
☼♭♬♫♨♩♧♦♥♤♣♢♠♡♐ฺ♑ฺ♒ฺ♓ฺ ♔ฺ♕ฺ ♖ฺ ♗ฺ♘ฺ♙ฺ♚ฺ♛ฺ♜ฺ♝(・∀・)/ヾ~~╋┓!㋦㋸㋭°
|壁|」゜ρ゜)」 ノ ヽ``~ 力㋦㋸㋭°
/ ⌒ヽ
/ ´_ゝ`) I am sorry、 the β α κ α kopipe couldn't be carried out・・・
| /
| /| |
// | |
U .U I've been meaning to change some of the defaults away from Futaba-style to saner behaviours. Any suggestions for what to change are welcome. So far: