feat: separe linguify into linguify and linguify-raw

[im-trisha]

Should fix part of what was discussed about in #30.

@SillyFreak I ping you, seems like you'd be happy to see this x)

[im-trisha]

P.S. I hope this is good + the tests with tytanic pass (Tried locally)

[ensko]

Looks good overall! I agree with most of the formatting, although I generally prefer to separate stuff like that into a separate commit (or PR, but that can be overkill).

The code change was simple enough; you can see my comments regarding the parameters.

Stronger testing would be nice; see the comments there.

Many thanks for your contribution! Let me know if there's anything unclear or something where I could help out with a part.

[ensko]

So my understanding is that in the fluent test, we both prefer the original formatting; after that revert and removing the two parens, I think this is good to merge. Thanks again :)

[im-trisha]

@SillyFreak I do prefer the original formatting, but I also think that, in every language that has a standard, it should be respected, so I think we should allow the formatter to do its changes. But if you prefer the old formatting I can keep it anyway.

And no need to thank me! Its a pleasure, plus I did nothing really big and had to make you lose time on comments x)

[ensko]

I also think that, in every language that has a standard, it should be respected

I'm torn on this—it removes something that would be bikeshedded otherwise (see: right here), but in this particular case the code is also shown user-facing in the manual, and the formatting there is thus a bit more of a deliberate choice. The test code is supposed to check that the manual shows correct information, so keeping that code in sync makes sense imo. (But the current manual way of keeping them in sync is of course also not great.)

Another viewpoint is that typstyle is still relatively young, so I'm not sure I would call it a standard yet. It surely is the most used Typst formatter though. I'm also reminded of this Reddit comment, itself quoting this blog post:

Most programming projects in the wild follow a Pareto curve where you can build 80% of the project in 20% of the time, ship and then iterate to improve on the last 20%.

But the problem with formatters is that you can't ship if it's doing the right thing 80% of the time. This would mean that every 5 lines it format things in a weird way. People are very sensitive to the way their code is written so this won't fly.

To me this means that a young formatter should not necessarily be considered the standard outright, but on its way to getting there.

In any case, at least for now I feel that the current formatting is fine, and thanks for removing all these other inconsistencies that have crept in!

And no need to thank me! Its a pleasure, plus I did nothing really big and had to make you lose time on comments x)

It's also always a pleasure when other people see something worth to put their time into too, no worries :)

[im-trisha]

Thanks for the kind words, I like the way you "said" things, never tought of it that way. I guess that for the general public for typst (university notes, papers etc.) the formatter does a wonderful job, but for packages its still meh.

I will continue contributing to this with pleasure! Just @ me or If I dont really answer (I dont open github very often) you may as well send me an email or contact me anywhere else.