Neatvi Re: [dev] Programs that rock

From: Spenser Truex <>
Date: Mon, 25 Jan 2021 02:25:22 -0800

On 21/01/24 04:10PM, Kyryl Melekhin wrote:
> Mart Zirnask <> 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.

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
> 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

Received on Mon Jan 25 2021 - 11:25:22 CET

This archive was generated by hypermail 2.3.0 : Mon Jan 25 2021 - 11:36:08 CET