being able to reffer to other users inline with a simular replacement system to the markup system. probably with @{USER_KEY}.{field} or some other character to identify it in a message or timestamp. which acts as a shorthand for styled span with the text of the field being insterted.

example use: adding timestamps/ day breaks to MPSA style chatlogs since those often have "{handle} [{shorthandle}] started pestering {handle} [{shorthandle}]"

which would probably look like this in practice @-- @JADE.handle [@Jade.short_handle] started pestering @DAVE.handle [@DAVE.short_handle]

we were seperately going to make a feature request for adding timestamps to the mspa template but that would probably be reduntant as that would likely be the test case for this.

hard part really is exposing it to terra in a way that let's templates configure the way this system works. maybe they're stored in Postblock as a struct which holds: user mentioned, field, and timestamp/message context or something, wdk? also allows for adding mentions to the discord template.

I'm currently working on making a post using Cohoard, and I've found that the Twitter template includes line breaks in between the <span> for the display name and the <span> for the handle that seemingly mess up Cohost's Markdown parsing. It renders fine in Cohoard, but bringing it over to Cohost breaks it for some reason: I'm afraid I can't really figure out more of what's causing this on my own, but removing the line breaks seems to fix it so that looks like the best option for the template.

in Godfeels, June Eg8ert's headmates Dare and Risk have different text colors from their name colors. Dare's name color is #7882ff and Risk's is #3e9fd1, while Dare's text color is #0715cd and Risk's is #005682. is there a way to support that in Cohoard? — alphy

i upped the font weight to 600 so that it looks bold like in discord

also i figured i could do it myself and open a pull request because it's CSS-y stuff, rather than ask you to do it

this is also my first pull request soooo i hope i did it right

Problem

The README should link to the actual published Cohoard site, so that people who look at the repo can go and try it out!

Solution

We add a link to Cohoard at the top of the README. We add a link to Cohost as well!

Currently the website is hard to develop locally with because it uses lots of files hosted on other severs. The following need to be able to use a local version of the file:

• Templates
• The wasm-bind generated Cohoard package

• [x] Create table-style config.
• [x] Make table persistent between reloads.
• [x] Make row placeholder text change when row header is updated.
• [x] Highlight the table to show why a Tera template errors out.

The github actions should let me deploy a new version of the Cohoard WASM library. This will need to do the following things:

1. Check out the repo
2. Run the following commands in the wasm sub-crate

wasm-pack build --target web --release
wasm-pack pack

(this might need to install cargo along with wasm-pack first) 3. Upload the files cohoard.js and cohoard_bg.wasm to the Spaces CDN that Cassie is using, with an appropriate semver version name (or possibly to just a "latest" folder?).

Hosting some images on cassie's site would be useful for people to use. Good options include the Discord and Twitter default profile pictures, an all black/white/transparent image, and Undertale images.

It would be nice to have a way to add a person with a set of reasonable preset values. Some good examples are Undertale, Homestuck, and 17776 characters.

Currently, this just tries to parse "missing variable" messages from Tera. This is very hacky and brittle, and would be better done if Tera could report rendering errors more richly. Some other things that aren't great are:

We highlight the entire column, when we should try to pinpoint the
specific row that caused the error.
Im not really sure what to do if the script uses a key that isn't in the
config table. This is annoying to detect but could feasibly be done.

Must be merged with https://github.com/a2aaron/Cohoard/pull/27

Would complete one task in https://github.com/a2aaron/Cohoard/issues/9

Discord itself seems to use a font weight of 500 for usernames (normal text is 400, and bold text is 700). However, lots of fonts don't have more than two font weights, so there isn't anyway to make the username bold without it being just as bold as normal bold text.

The Discord template uses the following font family: Whitney, Verdana, Helvetica Neue, Helvetica, Arial, sans-serif, falling back to the first one in that list. In practice, almost everyone probably sees Verdana, since most people don't have Whitney installed. Helvetica Neue does have 6 weights (100 thru 600) but it seems like it's not a default font on Windows machines (which means we probably can't rely on it). The rest only have two font weights.

Below are some comparisons of how a post might look in different fonts:

Cohoard, actual font: Verdana, font weight 600

Cohoard, actual font: Helvetica Neue, font weight 600

Cohoard, actual font: Helvetica Neue, font weight 500 (imo this looks the closest to actual Discord)

Cohoard, actual font: Helvetica, font weight 600

Cohoard, actual font: Arial, font weight 600

Discord, actual font: gg sans, font weight 500 (i think?)

It would be nice if a template could specify what variables they use in the Config table and what kind of variables those are. This could go in a config block and would specify the name + type of variable. We could use this information to do things like only display the columns relevant to a template or display some inputs using a color selector or checkbox or similar.

Right now, we have to fight pulldown_cmark on a bunch of stuff, because it's trying to do a bunch of stuff for parsing Markdown. This includes

• eating newlines
• adding <p> tags to messages
• using <pre> and <code> instead of a <span> that we can style
• not handling underline

This is annoying and suggests that we might be better off writing our own markdown parser. This doesn't need to implement the whole Markdown spec, but instead just the inline formatting stuff (and probably doesn't even need to be super good at it's job, so long as it can get most of the cases). This would make handling blank newlines much easier as well.