phil294

Tangentially, I built something similar a few years back, at link-archive.org: https://web.archive.org/web/20220127233707/https://link-arch...

3B existing URLs extracted from CommonCrawl, with instant search results. It was a fun project but didn't serve much real-world purpose besides curiosity and discovery. So I eventually ditched it, primarily because the link DB was a whopping 500 GiB in size, too much to just keep hosting.

I just used SQLite FTS5 as the backend search engine. Just a few lines of code, but immediate response from a 0.5 TiB DB. SQLite is amazing.

...performance-wise. Not in general. It obviously does more than just opening a file.

Also, you don't get to choose your competitors. SQLite is single-writer focused and an embedded library, but it's a sophisticated database engine after all, so comparisons with other "real databases" are more than appropriate. This meme really needs to die. Even more so when all you're comparing is query plan debugging output where there is no justification for unreadable output.

I would say it mirrors common behavior in the Web, which in turn was largely influenced by old desktop software: Enter in a `<textarea>` inserts a line break, while enter in an `<input>` submits the surrounding form (or does nothing). It is an established idiom after all, many apps just get it wrong.

Things that definitely need interactive prompts before running or fail out of ambiguity otherwise. Let's not pretend these are impossible problems to overcome design-wise.

I like it and would like to see an entire Linux OS being done in a similar manner. Or shell / wrapper / whatever.

A sane homogeneous cli for once, that treats its user as a human instead of forcing them to remember the incompatible invocation options of `tar` and `dd` for absolutely no reason.

    zip my-folder into my-zip.tar with compression level 9
    write my-iso ./zip.zip onto external hard drive
    git delete commit 1a4db4c
    convert ./video.mp4 and ./audio.mp3 into ./out.mp4
    merge ./video.mp4 and ./audio.mp3 to ./out.mp4 without re-encoding

And add amazing autocomplete, while allowing as many wordings as possible. No need for LLMs.

One can dream.

Depends on your definition of "using" JavaScript. The main difference between common TypeScript and TS-based JSDoc is the need for an additional build step. Being able to ftp-upload your `.js` files and then be done with it is a remarkable advantage over Vite/Webpack/whatever in small to medium-sized projects. If editor based type support is sufficient to you (i.e. no headless checks), you won't need to install any TS packages at all, either. tsserver is still used in the background, but so are thousands of other binaries that keep your editor, OS and computer running, so I don't see that as an argument.

> So (TS)JSDoc support is a relic from when Microsoft was trying to get market share from Google.

> Today in 2025, TS offers so much more than the (TS)JSDoc implementation. Generics, Enums, Utility types, Type Testing in Vitest, typeguards, plus other stuff.

None of that is true! Please don't share misinformation without looking it up first.

I see where you're coming from, but "on a phone" hasn't been a valid qualifier for performance benchmarks for a long time. Phones and their GPUs are ridiculously powerful nowadays. We've been smoothly running 3D apps on GPUs with orders of magnitude less MFLOPS 20 years ago already. Apps and games with far more going on than blurry glassy alarm clock, albeit somewhat less beautiful. When I run Fluid Glass on a 10 year old laptop with an integrated GPU and move my cursor, I'm seeing less than 10 FPS. When will we finally start readjusting our expectations for "fast" software and stop blindly following Wirths law?

Neither are humans, so this argument doesn't really stand.

This is a nice idea, but looking back at how not only documentation, but also UX in general has not improved the slightest over the last decades, it's fair to say the only way we'll ever get close to anything like this is by leveraging personal LLM assistants, unfortunately.

What about complex SPAs? Database drivers? Polyfills? TypeScript?

I ran some of these in comparison with Chrome, and Chrome was consistently faster, but only marginally (1-20%). I'm actually quite impressed, an integrated Intel HD 620 / 4x2.4 GHz (!) rendering 10,000 fishes at 30 FPS in a webbrowser.

Great game idea. I'd suggest you limit the questions top international topics though. I got a suggestion for "name a hurricane" - this probably wouldn't generate very interesting responses outside of America.

Pinta *IS* Paint.net, just forked at an earlier stage before the latter became closed source software.

Also, is "washed and bleak" really that big of a problem for an image editor? It just doesn't matter what it looks like as long as the UI is intuitive and has the features that you need. It should also be noted that Pinta very much looks just like your overall Desktop appearance on Unix. I'm on XFCE and it's so incredibly theme integrated it looks like it's part of the system.

Personally, I really like Pinta. Biggest problem is the bugs and crashes. Wish I could use actual Paint.net though, but there's no way to use it on Linux.

In other words, a fork?

Or how does the semantics of patch/changes/update differ in any way from maintaining a fork? The packaging has nothing to do with this. It may not be a well-maintained fork, the maintainers might not see themselves capable of adding features and bugfixes on their own, but a fork is a fork.

I agree with this - you need to change a few settings unless you're an absolute purist - but once you have done that, it's basically a nicer, well-maintained professional Firefox fork

It can have severe performance implications in some areas with very bad internet bandwidth. Also it makes instantiating a global cache more difficult. See: https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... Another POV: https://brr.fyi/posts/engineering-for-slow-internet And https://danluu.com/web-bloat/ also has some minor numbers

Linking to my own comment: https://news.ycombinator.com/item?id=31040629#31043115

I've been working on an extension https://github.com/phil294/search-plus-plus-vscode-extension for instant search results in gigantic repos like this one because it's a recurring pattern that bothers me. And eventually I'd like it to use its index to provide full go-to, autocomplete etc. on a pure plain text basis, because why not? I don't get the obsession with full-fledged language integration when plain text-based search results can get you all the way 9 out of 10 times, whereas a typical language plugin will constantly suffer from brokenness, performance problems and general annoyance, unless maybe you're working in pure JS/TS. And while LSP is great, you still have to fight this battle separately for every language you use. And regular "search" features are dreadful too.

It's one of these things that Jetbrains products are vastly superior in. It's fast, always works, falls back to text matching and also natively allows multiple languages per source file.

I like it, it's surprisingly fun to play. When played in groups (with changing words), this game would be well suited for non-natives learning English.

Because it's infinitely less work than starting from scratch. It's a valid argument.

That doesn't contradict the parent comment though. Engaged users should have an option somewhere to enable it, barely affecting the overall rollout.

> apparently the same people

The only thing these two groups of people have in common is that you don't like them. I fail to see any correlation here whatsoever.

> but it is missing the absolute trash fire that those results are currently

I don't understand your answer. Isn't that a good thing? Why are you missing trash on DDG?

It's exciting, but for both key listening and grabbing, the evdev route is still required, so unless I'm mistaken, this doesn't help us on its own.

It also doesn't help with window management: "One example is xdotool which does window focus and modifier mangling (see below). Window focus notification is not available to a pure libei client and would have to be obtained or handled on a separate channel, e.g. X or Wayland. Having said that, a Wayland client does not usually have acess to query or modifiy the window focus."

Edit: libei supports a "receiver" mode too. Perhaps it'll be useful after all!

I have built this here https://github.com/phil294/vimium-everywhere, and it works okay-ish performance-wise. For example, generating the click hints on this thread on Firefox takes (including FF's UI elements) takes one second, perhaps less on a fast machine. I use it on a daily basis. It needed a lot of optimizations to get to that point though. There are also a few alternatives listed.

And almost all applications support at-spi once you set some env vars! Including electron apps etc., see the readme

> It'd be nice to have something like autohotkey for Linux

I have built this already: https://github.com/phil294/AHK_X11

The X11 variant was fine, but Wayland support is indeed too messy, so the experimental build for that just uses uinput/evdev and ignores anything Wayland-related. I don't think there is a feasible alternative right now for tools like this, and it sucks. At this point I'm honestly mostly hoping for at-spi to rescue us. https://github.com/phil294/AHK_X11/issues/2

You are sure? There are almost none, that's the point!

Interesting thoughts, even though I don't understand half of it. But really, check out: https://news.ycombinator.com/item?id=28432921

This is very cool, looking forward to it! I've been doing the same thing with Spanish Wikipedia articles for a while, using a few lines of Bash + Regex. I was using Apertium for it. https://apertium.org/ It's definitely worse than most ML-based solutions, but it works reliably, deterministic, and fast; you can run it entirely offline. With Spanish translations, the main problem I was facing is lack of vocabulary, so I created https://github.com/phil294/apertium-eng-spa-wiktionary which about doubles the amount of recognized words, albeit with wonky grammar.