4 ms·
I worked on this problem for just over a decade before moving onto other things. It’s a tough problem to solve. The biggest problem I ran into is that the larg
by austincheney 5y ago
I worked on this problem for just over a decade before moving onto other things. It’s a tough problem to solve.
The biggest problem I ran into is that the largest segment of user growth were too fickle. They wanted all kinds of magic in new optional features for their personal preferences that took incredible effort. I lacked the analytics to see who used which exotic features. Most of these people just wanted a beautifier more that a diff tool and would drop you in a heartbeat for more popular tools that wouldn’t do what they wanted but were popular.
The tool I wrote did have a strong following mostly around markup language parsing that was not at all exotic but solved problems other tools refused to approach.
My guidance is don’t become a code beautifier. In the languages I was supporting during the time frame I was supporting this code beautifiers were all the rage. Nobody seemed to want a diff tool with extra capabilities. Stick to being a diff tool. The people that are intentionally looking for intelligent diff tools tend to be more engineering focused and make for a loyal audience. People looking for code vanity are just the same as window shoppers walking down a street.
- pdimitar 5y agoCan you give us a link to your tool?
- hinoki 5y agoThe GP’s first submission to HN was a link to a diffing tool, so I assume it’s this: https://prettydiff.com/ https://prettydiff.com/
- Wilfred 5y agoThanks, this is good advice. There are some super featureful diff tools out there. For example, https://github.com/dandavison/delta https://github.com/dandavison/delta does a line-based diff but it also syntax highlights its output. I'm hoping that defining syntax in a separate TOML file will let end users extend difftastic for their own languages/config files. I want to keep difftastic small and manageable.