On 21/01/24 04:10PM, Kyryl Melekhin wrote: > Mart Zirnask <martzirn...@gmail.com> wrote: > > [...] So try the stock version, see what features are missing for > your needs, then try mine, do a diff and patch if I have the features > you may need, and have your own custom fork. Keep in mind though that > I made my neatvi a general purpose editor that I use for everything now, > I comletely got rid of VIM from my system,
>which is considered harmful. You are taking cat-v's list way too seriously here I think. > So ideally my wish is to make people do the same. Many people use dwm and > st and it grew to have many good patches and infinite user control. So > why can't we have the same good things for a text editor? I tried all > text editors listed on the rocks page and all of them were not suitable > for hacking in some way, just like how easy it is to hack on st or dwm > for example. But neatvi came in as a saving hero. github.com/kyx0r/neatvi Wow, that is a lot of edits. One of the things that makes suckless programs so useful for obscures uses is that there is a barebones skeleton and a bunch of patches to choose from. I myself use some guy's fork of st, but my own patches for dwm, ii, and other programs. It would be good to see your changes split into these groups: - Sent upstream to ali (stuff everyone needs) Pick one (or both): - Made into individual patches in the Suckless way (stuff that may suit one's taste) - Your public fork (a bunch of patches appplied like you have, but not peculiarities to you). If you do this, I probably would't use your fork still, but someone else might. - Your private fork (stuff that only you need) (no need to publish this) Then I would perhaps consider using your code, however I happen to see fit, for this program. This is my personal opinion, I hope you find it useful. From your README: > Q: Why not distribute as patches, like on suckless.org? > A: It's hard to maintain, say this repo have 35 patches, so it will > be 35+ diffs. And each time something will mess up because one file change > will require to change every patch offset, etc. I disagree that it is hard to maintain. What I do is: - Make a clean fork at the patch's commit git checkout <commit> && git branch commit1 - Apply the possibly outdated patch - Merge - Fix conflicts This works fine, you can do 35 patches if you want this way, it would take around an hour to get a custom fork. It is easier to add code than remove code. > Regards, I remain Your Most Humble and Obedient Servant, -- CAEE B377 FC82 BAF9 102C D22F C5CE D003 1AA8 E281 Spenser Truex https://equwal.com
signature.asc
Description: PGP signature