Is this already a bug report?
No, I think it’s fine
Here, I left a space so it didn’t become like this
Version 1.1 patch-notes:
Upgraded from Discord to Discourse
Fixed the typo/mistake where I wrote “Discord” instead of “Discourse”.
If I broke something in this patch I’d be very surprised.
Link to previous script version for downgrading in case you want to live the Discord life
I’ve been meaning to make my own markdown script, but hacking it into the post cooking is a pain. I have a working markdown plugin, which would be more useful across the board. But WaniKani’s Discourse plan doesn’t currently support custom plugins. So I’m trying to convert that plugin into a standalone script for the time being, but running it through the markdown engine without converting markdown unrelated to ruby is a pain.
w.require("pretty-text/engines/discourse-markdown-it").cook actually work? I wouldn’t think it would. I think if I run the whole post through that I’d still end up converting unrelated markdown, so I need to find a way to only convert highlighted text or something like that.
Yes, as soon as someone inputs something like:
I also had to inject into the
save() function – probably because
Discord Discourse doesn’t accept a cooked string if it doesn’t match the raw input? Therefore I convert the furigana markup in the raw input right before
save() is called.
Version 1.2 patch-notes:
Ruby to furigana markup feature
As soon as ruby markup is detected in the input box, IME2Furigana now offers to convert it into the more compact furigana markup form.
If I broke something please let me know.
Link to previous script version for downgrading in case version 1.2 doesn’t work
Does this really need a prompt?
I’m not sure – there might be cases where my ruby markup parser fails (it definitely fails with nested ruby tags). The resulting markup (after conversion to furigana markup and then back to ruby) is also most likely not the same anymore, so for example the Discourse functionality where it highlights the quoted part of the whole post after expanding the quotation would probably not work (I haven’t verified this). And since I automatically add lang=“ja-JP” to the ruby tag, the visual appearance of quoted parts might also be altered. Therefore I wanted to leave the user the choice before manipulating what they wrote.
Would you prefer a different behavior?
That all makes sense. I would like it to just convert it, but I understand that it might not be for everyone. Could you maybe make it a setting at least? Maybe just a variable at the top of the script?
Okay, no problem
By the way, thank you for suggesting my script for the Japanese Only (Beginners) threads! Do you know if Mami-sensei also uses userscripts for her posts? Since she uses
<del> tags inside ruby, this might lead to problems with my script. For example
<振>[ふ]り<仮<del>仮</del>名>[がな] leads to 振り<仮
I guess finding a fix for this will be the next point on my to-do list.
I don’t know, buy my impression is that she doesn’t
With your script, what is actually saved for the post? The ruby tags or the markdown?
Version 1.3 patch-notes:
Added setting for unprompted ruby to furigana markup conversion
You have to edit the script and set
Sorry for not providing a more convenient way to access settings. I’m wondering if it would be a good idea to add a settings section for my script in the Discourse preferences menu?
The ruby tags. For some reason the result after posting was always <漢字>[かんじ], instead of 漢字. Either I missed some place where I would have had to inject something, or the server does some sanity checks?
I’m pretty sure the “cook” functionality for the markdown is run on the server. I think the client-side copy only runs for the preview pane.
Yes, so I assume there is no other option than to save as ruby tags.
Version 1.4 patch-notes:
Until now, every text that did not contain kanji was classified as “user input” that should potentially be used as furigana. That could lead to problems if the IME first converts the input into katakana or even emoji and afterwards into kanji. The last “input” not containing kanji was then used as furigana, leading to 狼 or 汗.
Now it uses the last input containing only hiragana or punctuation marks. I hope nobody plans to use their IME in katakana mode and wants their katakana input as furigana.
Tags in furigana markup
It should now be possible to use tags like
<del> inside of furigana markup. Examples:
That’s probably a feature nobody will ever use.
Please let me know if something doesn’t work.
Link to previous script version for downgrading in case version 1.4 doesn’t work for you
Thanks for the bug report – I have confirmed that version 1.4 doesn’t work in Waterfox. Version 1.5 should fix this. Since you went back to version 1.3, it probably won’t auto-update for you and you have to manually install the current version. And thank you for adding the script to the API list
When I saw some time ago that you had problems with RegExp lookaheads in Wanikani Heatmap, I was wondering if some users would also have problems with my IME2Furigana script, which also uses RegExp lookaheads. As it turns out, the lookaheads were fine – the negative lookbehind was not.
To be fair, regexr.com did warn me that negative lookbehind might not be supported by all browsers. And in my defense, I did put that part in a
try...catch block. Too bad that regular expression literals are compiled when the script is loaded, and not during runtime, so the
try...catch block didn’t help at all
Version 1.5 patch-notes:
Bugfix for browsers not supporting RegExp negative lookbehind
Waterfox doesn’t support negative lookbehind in regular expressions, which caused version 1.4 to not work at all in that browser. With version 1.5 it should work now. However, if your browser doesn’t support negative lookbehind, there is a rare case which will lead to wrong results: if you edit or quote a post that contains
> in the ruby base, and then let IME2Furigana convert the ruby markup back to furigana markup, the
> won’t get sanitized to
> and IME2Furigana won’t be able to parse the resulting furigana markup.
Example: 2 > 1 will be back-converted to
<2 > 1>[wrong] instead of
<2 > 1>[wrong]. The latter can be parsed by IME2Furigana, while the former can’t.
I doubt that this will ever be an issue, so I’m currently not planning to fix this.
Please let me know if something doesn’t work.
Link to previous script version for downgrading in case version 1.5 doesn’t work for you
Honestly I don’t understand why the lookahead was giving me trouble with the Heatmap. Looking at the specs it should have been supported, but maybe something else was going on too
is it finally working?