_sinelaw_

You still need the distro maintainers to cooperate. And the packaging itself can be highly involved (as in the case of rust dependencies on Debian)

Exactly. It's ironic that the end result is "windows is easier". Ugh.

Still need to handle automatic upgrades. That's my plan. I was wondering if there's a better way...

Flathub (not sure if these are the same people behind Flatpak) makes it clear they don't welcome these types of submissions:

https://docs.flathub.org/docs/for-app-authors/requirements

If I don't make my program easy to install, many people won't even try it.

Being responsive to maintainers doesn't help if maintainers never reach out or even actively refuse to package your software.

It's a problem for my potential users. I don't get this "it's not your job to distribute your own software".

Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update

I do publish deb files in the GitHub release page. Will take a look at aptly / reprepo

"Someone else's job" doesn't help getting the software into my user's hands.

I need a solution that works for my users regardless.

cargo install (the equivalent command here) is available. Downsides:

- very slow

- need to install prerequisites

- not possible on many machines (to weak, not enough disk for running builds)

Many users don't want to deal with this

Hi, I'm the author of this post (and of Fresh). I've spent a lot of time getting it distributed cleanly to Linux users of all distros, and it's an uphill battle. I'm curious how other solo maintainers are dealing with this problem. Is a self updating static binary a reasonable solution?

(Fresh maintainer here)

Fresh itself has a few dozen direct dependencies. About 33 of those already exist on Debian. It boils down to these missing dependencies:

- The entire oxc toolchain — oxc_allocator, oxc_ast, oxc_codegen, oxc_diagnostics, oxc_isolated_declarations, oxc_parser, oxc_semantic, oxc_span, oxc_transformer

- rquickjs, rquickjs-serde (the QuickJS plugin engine)

- ts-rs

- jsonc-parser

- rust-i18n (this one has an open ITP)

If we build Fresh without plugins enabled, it's just the last three.

The harder problem is conflicting design choices, or duplicating similar infra. It means I need to be much more involved in steering individual agents and planning up front (waterfall style), which limits the parallelism further

I did when just starting on a new project, it was working well when I had many new components to implement. But as the project matured and stabilized every new feature is cross-cutting and it's impossible to parallelize the work without running into conflicts (design conflicts, where two agents would add similar overlapping mechanisms, and also the usual code conflicts, touching the same files). Also, with project maturity I'm much more concerned about keeping it stable and correct, which is hard to do with parallel agents running amok.

It even runs Fresh so you can have a mini VSCode-like experience on your phone (pkg update && pkg install fresh-editor)

Let me know if you still have issues, I'll look into it

Is this 'task' feature really useful? I'd say applications like IDEs and text editors should not have automatic arbitrary execution of code in the first place. 'eval' should be blocked and extensions/plugins should have only very limited power to execute external logic (such as processes for LSP) or require allowlisting manually every process.

For Claude, it's enough to prompt "use tmux to test", that usually does the work out of the box. If colors are important I also add "use -e option with capture-pane to see colors". It just works. I used it regularly with Claude and my TUI. For other agents other than Claude I need to use a more specific set of instructions ("use send-keys, capture-pane and mouse control via tmux" etc.)

Since I have e2e tests, I only use the agent for: guiding it on how to write the e2e test ("use tmux to try the new UI and then write a test") or to evaluate its overall usability (fake user testing, before actual user testing): "use tmux to evaluate the feature X and compile a list of usability issues"

I'm also a long time emacs user (>15 years) but got tired of the endless config fiddling, with some packages breaking over emacs versions, other packages which were cool at the time slowly getting stale and need to switch to yet another similar incarnation of the same idea. And most of all having to recover the config every time I use a new computer or just connect to a new VM.

I'm building an alternative, and I haven't opened emacs for a month now

What specifically are you missing from Zed? (not a Zed user but curious to know)

I also got tired of the bloat and also prefer working from the terminal.

I'm building Fresh [0] [1] as an alternative to VSCode that runs in your terminal, with the main goal being ease-of-use out of the box (not a vi-clone modal editor), for example supports mouse, menu, command palette, etc out of the box. LSP as well. I'm focused on making it easy to use with minimum or zero configuration.

[0] https://github.com/sinelaw/fresh [1] https://sinelaw.github.io/fresh/

For a long time I watched TypeScript take over the JavaScript ecosystem as a reasonable way to add structure and safety. But even before TypeScript existed I was thinking about how to approach this differently, ripping out the "bad parts" of JavaScript instead of accommodating them with a complex and partially strict type system.

Also, recently I found out just how expensive (runtime-wise) it is to host a full-blown TypeScript host, such as Deno. This is very cool tech but kind of bloated when all you want is to run some JavaScript, e.g. as a plugin system. It's possible to just pre-compile (transpile) your .ts files and then ship only the JavaScript output and use a lightweight runtime (QuickJS or even the new Micro QuickJS), but then compilation becomes a neccessary step for what could've been purely dynamic, ad-hoc and quick plugins (think elisp in emacs).

minfern is my second shot at this, and I'm exploring just how much JavaScript idioms are "must have" for it to be useful.

Added GPM support, try latest master or release >= 0.1.25 (rolling out now)

Did you try "use option as meta key"? https://superuser.com/questions/1038947/using-the-option-key...

Done, you can pass now file, or file:line, or file:line:column in the cli

zed: ~20 seconds to open the file, 4.7gb RAM

no ansi color rendering

I took the feedback and now you can install binaries in any of these methods:

- Homebrew (MacOS)

- Arch Linux AUR

- Debian/Ubuntu .deb

- Fedora/RHEL .rpm

as well as cargo install (which builds from source), npm, npx or building from source by cloning

It does and it boils down to deno (typescript plugin support)

I hate it, and I'll keep working on reducing it

Either because I move to a new machine, or because new version of emacs breaks some (no longer maintained) packages

LSP is working but requires polish. Go to definition, completion suggestions, inlay type hints and symbol highlighting are all working (probably not as pretty as they should)

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.