121–130 of 158 posts
All AI generated, not something I can trust.
Yes, to some extent because AI only assisted the developer achieve their goal. But the developer is clearly talented, no doubt about that. They know their stuff very well. Having tried writing a text editor myself, I could quickly tell they know their stuff by analysing the program design
so many commits authored by `claude` with 100+ lines each, that extent is not "some".
1. CI looks unhealthy: https://github.com/sinelaw/fresh/actions/workflows/ci.yml 2. Thank you for running builds on ubuntu 22.04 so it's compatible with it. You might want to compile with cross or zig to support even older operating systems.
As it's statically linked I don't see a reason it shouldn't work in any much older Linux as well. But I haven't tried yet.
I'm not sure where you got this idea. The binary you distribute is dynamically linked:
> fresh: ELF 64-bit LSB pie executable, x86-64, [...], dynamically linked, [...]
and it links with libc, libm, and libgcc_s, which means the distro will matter, because GLIBC is not compatible that way.
How did you, after building this entire app, come to the conclusion that its statically linked? Rust apps typically aren't, by default.
I'm a little annoyed that for a Rust based tool the recommended installation command is to use npm. Why? Is Cargo not good enough? Cargo seems exceptionally well to me.
I get the frustration, but I think the npm option actually makes sense here. A lot of users who’d benefit from a fast Rust tool aren’t Rust developers and won’t have Cargo installed. Shipping it through npm lowers the barrier while still giving everyone the performance benefits. It’s not a knock on Cargo, just a way to make the tool more accessible.
Why not use the various standard and commonplace packaging and distribution methods for application software? Distro repos, tarballs, Homebrew, AppImage, Flatpak, etc.
All AI generated, not something I can trust.
Yes, to some extent because AI only assisted the developer achieve their goal. But the developer is clearly talented, no doubt about that. They know their stuff very well. Having tried writing a text editor myself, I could quickly tell they know their stuff by analysing the program design
OP, I'm playing around with it a bit, but notice it only supports mouse input when running in terminal emulator under X, and doesn't support mouse events from GPM (in the way that mcedit does, for example).
Looks like an interesting project! OP, I'm playing around with it a bit, but notice it only supports mouse input when running in terminal emulator under X, and doesn't support mouse events from GPM (in the way that mcedit does, for example).
How complete is the LSP feature support? Could we also get support for tree-sitter parsers and DAP (Debug Adapter Protocol) for an integrated debugging experience, just like the old Turbo and "Quick" text-mode IDEs?
Tree-sitter is supported and used internally for a subset of languages for syntax highlighting (other languages use textmate grammars). What exactly do you mean by support for tree-sitter parsers?
I wasn't aware of Debug Adapter Protocol! I'll take a look at that.