>>148

>5) Seperation of sage et al from the email field to something else...

This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.

>2) Have the string to sage and fusianasan defined as a constant in config
>3) A specific string for ID:Heaven instead of anything in the email field

As I mentioned above, this would better work if they could be modified within each template in the list of string variable definitions.

>4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?

I like this one, as far as saving name and e-mail inputs go. I occasionally browse 4-ch at school, and it'd be nice for just an option to clear cookies when you're done and don't want anyone else to use your name, e-mail, and deletion password.

What the hell is RENZOKU?

P.S. >>151 is RMS

> You mean requiring SQL software, or just making backwards-incompatible changes that would screw up old threads?

I mean, needing to alter the table that is already in the database. I don't want to try to do that any more than I have to, as it's pretty hard to get right in a database-independent manner.

> Are you only referring to flooding and spamming, or also trolls and flamewars?

Yes, only flooding and spamming. Trolling and flamewars are not a problem one should use banning to try and solve.

> Finally, out of curiosity: how much of the functionality in the .js file do you think could be properly implemented into a new or existing perl script?

Well, if you serve up dynamic pages, you can do the form-filling on the server, but that's about it. The rest is dynamic stuff.

>>41

>database redesign

You mean requiring SQL software, or just making backwards-incompatible changes that would screw up old threads?

>prevent abuse

Are you only referring to flooding and spamming, or also trolls and flamewars?

Finally, out of curiosity: how much of the functionality in the .js file do you think could be properly implemented into a new or existing perl script?

test

Funky, works... I am pretty sure the error has something to do with the characters preceeding the "¦" in the unprocessed tripcode. It begins with a "`"

>>16

Yes, it's throwing Javascript errors for me if I use that character. Gonna look into that some more.

>>342
Well, for example, in both forms the text labels are bolded when they shouldn't be, in Futaba and Blue Moon. If you take a look at Blue Moon, the text labels in Create new thread are larger than those in the Reply box.

>>323-324
The 2channel moderation request forms that are mods of 0ch use 強制リモホ, which is Forced_Remote_Host, more or less. And it makes sense, there.

Forced_IP is only enabled on the "Siberia super-news flash" board: http://etc3.2ch.net/siberia/

And I have no idea what that board is about...

Text Art's description about auto-linking URLs and >> references is redundant. Not a bad solution with the layout, though (hiding the menu behind "More options..." still bugs me).

Well, both >>30 and >>31 didn't change the ¦ into ?U so I am out of ideas what happened...

Removed it when redesigning the page head, haven't figured out quite what to do about it yet. It needs to be changed, but to what, I'm not yet sure.

I fixed the Javascript a bit, and uploaded it for these boards. Try shift-reloading to get the new code, and see if cookies work better now that I'm not using cargo-cult code.

> 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?

Oh, and "AA mode" should be changed to "Text art mode" so we won't be incessantly quibbling about the difference between ASCII and SJIS art.

No, but that's not the point.

GDLib for thumbnails: http://wakaba.c3.cx/sup/kareha.pl/1113869490/5

The problem reported in >>143 is still present.

On second thought, the whole search idea was pretty poor...but could you implement saging in a way that's independent of any particular post element, and is instead assigned in the individual templates?

test2. looks good!

I want a 1001th post! :(

>>16

What browser are you using? I think I've tracked down the problem, and it's most likely a browser bug. The ancient Firebird (not fox, even) version I tested at work had the same bug (character set issues in the escape() and unescape() functions). It looks like your browser also doesn't follow the spec for how they are supposed to work.

I hate that blue link next to the reply box! It looks ugly!

Also, there's no "Less options..."

Can't this be somewhere else but the post form?

Nothing specific, just protecting against any possible future ones.

>>16

Yes, it's throwing Javascript errors for me if I use that character. Gonna look into that some more.

>>259

Fixed.

>>260-261

The test script doesn't try to handle charsets at all at the moment.

> how about having a third party create extensions for those browsers and freeing up the real estate on the actual page?

What's with this obsession on removing the CSS options? It's a single line, and some of us find it useful.

Real estate? Scroll down.

> He meant saging a thread just because a part of the actual e-mail address contains the word "sage."
> You know, like [email protected].

Well, then you are out of luck, aren't you? So you want to enter your E-Mail but cannot because then the post wouldn't bump then? Solution: Write it in the comment field, problem fixed.
There is no reason to change well-known keywords for this or even turn this into a frustratingly unconvenient tickbox/checkbox.

>>343

"When they shouldn't be?" They've always been bolded.

>>66-67

Noted and fixed in development version.

>>266

I told you to shift-reload!