Tooster

> Difftastic is perfect on 64% of diffs and near-perfect on 17% more.

> Omnidiff is perfect on 90% of diffs and near-perfect on 5% more.

I did not find examples in the repo or any way to test what "perfect" or "near perfect" in those cases mean. On the playground you compare against unix diff only. Based on my quick comparisons with difft, I do not see much difference. Could you add a link to comparisons or show how it differs and what are those numbers based on??? I'm not dismissive, just looking for a proof or showcase.

It would be nice if you checked out lazygit and consider adding support to it's recently added OSC1717, adding supporting for staging in the main diff view directly: https://github.com/stefanhaller/diff-line-metadata-spec

Also it would be nice to have a more thorough and comprehensive comparison against difftastic, because I don't think there are much, or even any difference to code diffing compared to it: https://ivankovic.github.io/omnidiff/showcase/

Does yours support move + change detection across different files, like A/before.rs => B/after.rs (~some changes)?

AppImage works in the same way downloading a binary from the web and running it with `./program` works. It is dumb simple, but it has really poor integration with the system. I've been using AppImages for several years but the manual churn got to tedious — auto updates, system integration, background services, keeping it tidy. I contributed AppImage packaging workflow to some apps — mechanism itself is messy, supporting other systems is a pain (e.g. core libs between major ubuntu versions can pose a big problem, python apps as well),documentation is poor; even original proponents now advise against this format (citation needed). For some of the AppImages I still have to use (when authors don't distribute anything else), I use GearLever, but it itself is... a flatpak app (and we tried to port it to snap and it was dumb). Bottom line — they are ok-ish but you trade one kind of convenience for other and there is a lot more work on author's side. And a lot of the things about them are messy.

I did full circle of deb -> snap -> flatpak -> app image -> flatpak -> snap + deb + nix nowadays. Flatpak was overwhelming, required flatseal and often theming broke. FS sandboxing and permissions UX was annoying. Ultimately debs are the most convenient ones for now. Snaps get there but the cold boot time and occasional errors annoy me AF (ghostty as snap on fresh boot/after a while opens in several seconds vs miliseconds for deb, which becomes annoying day to day). I wish we had something like perms and portability of .apk + speed of .deb + compression and auto-updates/channels like snap + ease of distribution like AppImage + something from flatpak.

Ultimately on linux(es) I have a everlasting problem of "where shit/problems comes from" and tracking what comes from what and is where.

And the online mapping ecosystem is completely fragmented. Half the apps out there demand a $25/month subscription, creating these hermetic, proprietary silos. They are gating and monetizing trails, hikes, and routes that were crowdsourced by the community in the first place. I’m not paying $300 a year to buy back data that I personally contribute to. There are gazillion similar apps, with slight variations, and the more powerful ones look like something straight from 2000s.

Instead of a pay-to-access model, a sustainable consumer map ecosystem could look like Wikipedia, or better yet, a peer-to-peer network like IPFS where you trade compute (route calculation) and storage. It could be a barter: you get to use the collective resources of the network because you are actively hosting tiles, routing data, or contributing metadata back into it. But that requires a critical mass to take off (like bitcoin did).

OpenStreetMap is great, but what we actually need is a modern consumer frontend built on top of an open, distributed layer: decentralized public registry for user-generated content, keeping your routes and trip itineraries discoverable by any client app rather than locked inside VC-backed silos.

Furthermore, current open-source projects miss a lot of quality-of-life features that commercial apps have—things like crowd-sourced opinions and reviews about places, public transit schedules, real-time traffic alerting and reporting, location sharing, street-view, and dependable speed limits during navigation. Without these active, live-data layers, the map looks stale and lagging behind the real world.

The user interface also needs to shift from a passive viewport to a high-contribution editor. Right now, if you want to make serious geometry edits, you’re forced into JOSM. It’s hard to boot, clunky, and quite clearly has never seen a proper UI/UX designer, scaring away everyone but the most hardcore power users. I'm a person who doesn't give up easily, but when I tried adding parking zone regions for the city I gave up after 2 days of trying to make some sense of this software. A modern mobile UI should let you freehand draw a route that snaps to paths, edit regions on the fly, or drop advanced metadata — like parking restrictions — in just three obvious taps, without a steep technical learning curve.

Finally, the client app itself should be a pluggable core. Instead of building every feature from scratch, it should allow users to plug in open modules for whatever they need, whether that's live public transit routing, traffic estimates, location sharing, or advanced 3D metro overlays. The data is there, and the rendering tech is there; we just need a shared, distributed network structure so companies can't charge us a premium to gate the social and metadata layers. I wish there was an EU initiative to have a fully featured app like that, unifying all the existing ones in place of N abhorrent, barely functional implementations in all of the different local public transport apps (looking at you italian AMT genova or you, french IDF mobilites).

Every day, I pass by numerous signs and plaques reading "funded by EU funds." Most of the time, they are attached to public transport or road infrastructure. For anyone genuinely trying to understand the EU's impact — rather than just defaulting to blind hatred — there are plenty of public resources available. You can find maps and project lists detailing descriptions, funding amounts, and progress statuses.

Granted, this data is usually "boring" by today’s dopamine-driven attention standards, so it's no wonder people rarely talk about it. But if you actually stop and take an interest in what has been accomplished, you start noticing the impact everywhere—it just takes a little effort. After all, how hyped can you really get over a repaved road in some remote village you've never even heard of? You can't. But the people living there certainly feel the impact, even if they don't always notice where the money came from.

Go search for maps provided by EU or your government sites, for instance https://mapadotacji.gov.pl/?lang=en

You might disagree with certain aspects of the EU, but leaving a rage-baited, hateful comment is the easy way out. Looking at actual accomplishments—despite your frustrations—takes real effort.

For stuff which actually can matter and had impact on daily lives (beside aforementioned public transport impact):

  - USB-C as a standard power connector
  - hassle-free travel between countries
  - GDPR you mentioned
  - recent "stop killing games" public initiative which shows that common people can stand a chance against multimillion dollar companies
  - abolition of roaming charges and access to a free internet up to certain limits — huge PITA solved for people going on vacations  
  - universal healthcare between countries on vacations  
  - strong 14 day guarantee for online purchases, free return policies and minimum 2 year warranty  
  - food safety regulations (but if you don't care you won't be impressed by it)  
  - certain regulations regarding flights and passenger rights (cancellation compensation, recent regulations regarding baggage, to fight with scammy practices of flight operators)   
  - right to repair 
  - even the commonly memed bottle caps is nice UX — you (or more commonly a kid) won't be able to drop a cap on sand rendering :) And thanks to that there is noticeably less "small trash" on beaches and in parks (left to solve are beer caps ;)

The intend of this comment is just to show that it's not "nothing" if you bother to look, the stupid/bad/ugly is beside the point here.

Yeah, how many agents can you people even run at once and how much does it cost you? In company we used the monthly token quota and nowadays it's basically unusable with claude opus 4.6 on high reasoning. You can basically burn through 100% usage through a single day. How does it even scale for you with N agents and which magical plans or models do you use, where tools like this are even viable?

Cap your html bodies to 75ch width for comfortable reading. Minimalism doesn't conflict with nice layout and it's 1 line of css.

Currently I am leaning more into P2P for the zero-effort user side setup, although I was considering if hybrid P2P/client-server approach is feasible: free lite P2P vs paid, managed SaaS for user convenience and improved performance.

I want to create a local first, offline/p2p realtime multiplayer prototype app soon with reactive/signal data model and frontend agnostic design (considering solidjs/svelte). I'm on a tech research stage. How does it compare to rxdb, tinybase and zero sync? For reference right now I'm considering tinydb/rxdb.

I might be misunderstanding parts of the comment above, although I think it aligns with what I had in mind. Here’s what I meant:

If a ray carries full spectral information, then a transparent material can be described by its absorption spectrum — similar to how elements absorb specific wavelengths of light, as shown here: https://science.nasa.gov/asset/webb/types-of-spectra-continu...

In that view, transparency is just wavelength-by-wavelength attenuation. Each material applies its own absorption/transmission function to the incoming spectrum. Because this is done pointwise in the spectral domain, the order doesn’t matter:

OUT = IN × T₁ × T₂ (or in a subtractive representation: OUT = IN − ABS₁ − ABS₂).

So whether one material reduces 50% of the red first and another reduces 50% of the green second or vice verse doesn’t change the result. Each wavelength is handled independently, making the operation order-independent.

I was sure it must have been invented already! I've been trying to look for this idea without knowing it's called "spectral rendering", looking for "absorptive rendering" or similar instead, which led me to dead ends. The technique is very interesting and I would love to see it together with semi-transparent materials — I have been suspecting for some time that a method like that could allow cheap OIT out of the box?

And that's a great thing! I look forward to them being more mature and more widely adopted, as I have tried both zed and helix, and for the day to day work they are not yet there. For stuff to take traction though. Both of them, however, don't intend to be projectional editors as far as I am aware. For vims or emacs out there - I don't think they mainstream tools which can tip the scale. Even now vim is considered a niche, quirky editor with very high barrier of entry. And still, they operate primarily on text.

Without tools in mainstream editors I don't see how it can push us forward instead of saying a niche barely anyone knows about.

I’d also add:

* [Difftastic](https://difftastic.wilfred.me.uk/) — my go-to diff tool for years * [Nu shell](https://www.nushell.sh/) — a promising idea, but still lacking in design/implementation maturity

What I’d really like to see is a *viable projectional editor* and a broader shift from text-centric to data-centric tools.

The issue is that nearly everything we use today (editors, IDEs, coreutils) is built around text, and there’s no agreed-upon data interchange format. There have been attempts (Unison, JetBrains MCP, Nu shell), but none have gained real traction.

Rare “miracles” like the C++ --> Rust migration show paradigm shifts can happen. But a text → projectional transition would be even bigger. For that to succeed, someone influential would need to offer a *clear, opt-in migration path* where:

* some people stick with text-based tools, * others move to semantic model editing, * and both can interoperate in the same codebase.

What would be needed:

* Robust, data-native alternatives to [coreutils](https://wiki.archlinux.org/title/Core_utilities) operating directly on structured data (avoid serialize ↔ parse boundaries). Learn from Nushell’s mistakes, and aim for future-compatible, stable, battle-tested tools. * A more declarative-first mindset. * Strong theoretical foundations for the new paradigm. * Seamless conversion between text-based and semantic models. * New tools that work with mainstream languages (not niche reinventions), and enforce correctness at construction time (no invalid programs). * Integration of semantic model with existing version control systems * Shared standards for semantic models across languages/tools (something on the scale of MCP or LSP — JetBrains’ are better, but LSP won thanks to Microsoft’s push). * Dual compatibility in existing editors/IDEs (e.g. VSCode supporting both text files and semantic models). * Integrate knowledge across many different projects to distill the best way forward -> for example learn from Roslyn's semantic vs syntax model, look into tree sitter, check how difftastic does tree diffing, find tree regex engines, learn from S-expressions and LISP like languages, check unison, adopt helix editor/vim editing model, see how it can eb integrated with LSP and MCP etc.

This isn’t something you can brute-force — it needs careful planning and design before implementation. The train started on text rails and won’t stop, so the only way forward is to *build an alternative track* and make switching both gradual and worthwhile. Unfortunately it is pretty impossible to do for an entity without enough influence.

"Many communities depend on AI tools to detect and ban AI content" interesting...

If not depending on AI tools then depending on a... hunch? So like a modern-era witch hunting?

Someone committing poor quality LLM generated code and deeming it appropriate for review could create equally bad, if not worse, handwritten code. By extension, anyone who merges poor quality LLM code could merge equally poorly handwritten code. So ultimately it's up to their judgement and about the trust in the contribution process. If poor quality code ended up in the product, then it's the process that failed. Just because someone can hit you with a stick doesn't mean we should cut down the trees — we should educate people to stop hitting others with sticks instead.

"Banning LLM content" is in my opinion an effort spent on the wrong thing. If you want to ensure the quality of the code, you should focus on ensuring the code review and merge process is more thorough in filtering out subpar contributions effectively, instead of wasting time on trying to enforce unenforceable policies. They only give a false sense of trust and security. Would "[x] I solemnly swear I didn't use AI" checkbox give anything more than a false sense of security? Cheaters gonna cheat, and trusting them would be naive, politely said...

Spam... yeah, that is a valid concern, but it's also something that should be solved on organizational level.