Fix kbin Code Blocks
greasyfork.org
Dirty fix for kbin code blocks federated from Lemmy. Strips out the weird tags on each line.

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.

  • shazbot@kbin.social
    1·
    10 months ago

    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?

    • Pamasich@kbin.socialOP
      1·
      10 months ago

      This library.

      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.

      • shazbot@kbin.social
        2·
        10 months ago

        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.