I have been using this editor as my main editor for over a year

[173duprot]

This is by far my favorite VI clone EVER! It's beautiful, simple, extensible, hackable, portable. It's exactly what I have been looking for for years.

Thank you for making this < 3

[kyx0r]

Thank you, this touched my heart. Be sure to recommend Nextvi to your friends.

[173duprot]

4 years of use and counting.

[cortexmancer]

This editor is WILD, I am really glad for it.
I've been using for C only, and yet still so much to learn and do

[173duprot]

5 years, nuts it's still being updated

[kyx0r]

Indeed, this is my text editor till the end of times.

It takes a really long time to formulate a least common denominator in the area of text editor theory. That means determining what text editor should have and have not. As this is a very open ended problem, when I started this project I had no idea of the difficulty. Thus, you can see how my understanding improved through the decision making and design choices. I had to fit the design to constraints on performance and number of lines of code. This is not your typical (means to an end) open source project, I began to see it as a Mona Lisa painting, which took Leonardo da Vinci years to complete.

If I conclude version 1.5 looking solid, I may take a break for some time. Although I never stop thinking about all possible paths and use cases.

To grok how far Nextvi has come in capabilities over this year, see my function which allows me to open a batch of files using a regex rule. This is simple but effective way to demo how Nextvi can be used to carry out pretty complicated logic. And this is just one way of achieving such a use case. Though I admit that this requires very deep understanding of the editor and most people will fail to find the see for automations despite near perfect documentation which also aims to not exdeed 1500 lines.
https://github.com/kyx0r/klec/blob/master/dotfiles/.rc#L306

[Un1q32]

I still use neovim as my primary editor because of visual modes and LSP, but nextvi has been extremely useful to me as an editor that has almost everything, and can still run fast on extremely low power hardware. Nextvi still opens files instantly well past the point where vim is too slow to really tolerate, I've never seen a system it really slows down on, I should run some old PC emulators and see how old I can go before noticing slowdown.

[kyx0r]

Good point. I would like to add that opening files right now is basically a memcpy(). It physically can't get any faster in any text editor, unless doing some kind of lazy loading or threading. (Also HW IO bound) I consider lazy loading cheating. It complicates the architecture quite a bit, though still pretty easy to implement in Nextvi. Right now I don't see the point of pushing it that far.

There are still some novel opportunities for optimization, like SIMD utf8 decoding. But, it's not super portable.
The other one would be multi-threading ren_position(). This one is quite a challenge since computations depend on past results.

And never forget that ex mode exists and can do any vi/ex operation more efficiently with the right options.

[173duprot]

NGL that's why I've truely been falling in love with zig as of recently.

There is no platform-specific SIMD instructions, you simply tell the compiler @Vector(...) and use a bunch of builtins for vector math, and the compiler will SIMD it on the specific hardware your using if it supports it.

Now obviously you can architecturally optimize for a specific platform or platforms if you want, but this allows the code to be clean and generic regardless on any platform including ones without SIMD with only a single line of code. I have crunched thousand-line C++ SIMD programs into generic ~150-line core algorithms on @Vector-s with no loss in performance. It's very impressive.

[kyx0r]

I tried Zig today and it kinda sorta sucked. To build zig compiler I had to recompile my llvm to support all architectures. I don't understand why they can't adapt their build process to whatever platform my llvm was already built for. That aside, bootstrapping is overly complicated and requires wasm. I had ccache enabled by default and it doesn't play nice with it either, for some reason there is a fatal memory leak either in ccache or in the way bootstrapping works. It filled my whole 30GB instantly. Problem went away once ccache disabled and usage stayed ~6GB max. Bootstrap process was single threaded and took quite some time. Using TCC was a no go, zig1 executable segfaulted when built with latest tcc trying to compile zig2.

I originally thought that zig could transpile zig code to C, but turns out it can only do it in one direction - from C source code to zig. Since it is not bidirectional, I don't see the point of this language now. It is useless to me. I still go C all the way baby.

EDIT: zig does have -ofmt=c flag but I couldn't find it in the docs? They had more than 3 years to document it so I don't really understand. Also this output doesn't translate to a working C program. It's closer to some kind of decompiled output.

My opinion may change once zig releases, as I've seen their plans to get rid of llvm which is a big plus and will remove some inconveniences.

[kyx0r]

Nextvi 1.7 is a stable release. I've run out of ideas for now, so this will stay for a while.

[Un1q32]

I've never actually used the zig programming language, but I have used their release tarballs as easy C cross compilers, you can do zig cc -target arch-linux-musl something.c and it will compile the musl sources for whatever arch with the same optimization flags you entered and make a static binary without having to setup the sysroot yourself. Also works for linux-gnu targets but it makes a dynamic binary that works on any reasonably old glibc version, and you can even target x86_64/aarch64-windows (will use mingw) or x86_64/aarch64-macos although that defaults to targetting a really new version and you can't change the target version with -mmacos-version-min for some reason. This is incredibly useful in CI build scripts for example, or just day to day when I wanna make a static binary for some weird architecture.

[kyx0r]

Yeah the fact that it can cross compile and statically link C by itself is pretty neat. I can see how it can be useful for such tasks.

[kyx0r]

In my limited view, I like vlang more right now. They are doing some interesting things, like having a 100% functional transpile to C. This is very good if I like to go lower level, since the language is not trying to be a C replacement. Just like C is not trying to be asm replacement and asm is not trying to be opcode replacement for hardware engineers. The backend is flexible to be tinkered and swapped out. Not reinventing the wheel. This is a pretty important consideration for maintainability and is what all these other new languages get wrong.

I've seen vlang a few years back as it was getting a lot of hype, but it also received a lot of negative feedback early on which I guess made hype die down. Now internet rarely even mentions it despite getting a lot better.

However, I'm still not entirely convinced that a C successor language is really necessary. Though if you see me making new projects in vlang, you'll know what's up.

[173duprot]

I haven't touched C in months honestly. I ported all my projects to zig and they now take up ~30% less lines while being both faster and safer because of generics. It may not work for other folks, but with my background in forth and lisp, metaprogramming is like water for me.