On 21/01/24 04:10PM, Kyryl Melekhin wrote:
> Mart Zirnask <martzirnask_AT_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
Received on Mon Jan 25 2021 - 11:25:22 CET