Lemmy federates code blocks with additional <span> tags added in on each line which /kbin just treats as plaintext (it should really strip them out or treat them as tags, not plaintext).
See this comment for an example
This userscript for kbin.social tries to remove those tags and make Lemmy code blocks actually readable.
Edit: Latest version supports infinite comments and turbo mode.
Would you like to add this to KES? You can use KES’ propagation feature to ensure it applies to comments loaded in on the fly when infinite scrolling is enabled without needing to worry about page load events.
May I also suggest something more idiomatic like the below?
const code = document.querySelectorAll('pre code'); const reg = /^\n<span>/g const reg2 = /\n<\/span><span>/g const reg3 = /<\/span>\n$/ code.forEach((block)=> { let str str = block.innerText; str = str.replaceAll(reg, ""); str = str.replaceAll(reg2, "\n"); str = str.replace(reg3, ""); block.innerText = str; }); ```</span></span>
I’ve been considering it, but I currently lack the time to do it properly, so probably not soon.
The script here was created in a hurry, I mostly cared about it working for my use case, and I put it online so it can hopefully be useful for other people too. But that’s why I didn’t put a lot of thought into things like how the code looks, compatibility with kbin features I don’t use like infinite scrolling, and proper testing (referring to my “probably doesn’t work in turbo mode” instead of just trying it out).
I should definitely make a version 2 of this first though that takes into account infinite scrolling.
If you need help packaging it, let me know. Can prepare it and credit you. Setting up infinite scrolling in KES just requires one line (
recurs: true
in the manifest) and KES will take care of spawning observers automatically.By the way, what is turbo mode, exactly?
In recent updates ernest enabled Symfony’s bundle integrating it. You can enable/disable it in the sidebar settings, at the bottom of the general section.
I haven’t looked into how exactly it works, but it’s supposed to give a single page application experience without the developer having to write the javascript for it. And it breaks a few of the scripts I’ve been using.
Thanks, this was helpful. By design, Greasemonkey scripts necessarily trigger on page load. However, KES initializes its own mutation observer and watches for events that change the DOM, but does so in a granular fashion so that only those of relevance (changes to the thread index and comments) are propagated. It looks like when turbo mode is enabled, the entire DOM up to the HTML tag is replaced at once, so our more granular approach is missing this change. We need to watch for basically all mutations now and filter them accordingly.
After making the necessary changes, it seems to be working again as intended, but some additional refactoring is needed, and I haven’t checked the implication of this on specific scripts/add-ons yet. It looks like it should be easy enough, since the majority of functionality I looked at was working again when using a more permissive observer.