Nice, but problem with all these AI coded TUI's is we will have hundreds of them, best to stick to the built in linux commands, add aliases/abbreviations (fish) if required, do you need a TUI for everything? Sometimes the answer to "Should I write this?" Is no
I do agree with some of your sentiment. But by that logic, nothing would ever be made.
The same goes with aliases. Why not just use the actual commands. You give it your best shot, and sometimes something good comes out. And sometimes it's crap. That's life.
And I made it for fun and to learn something. And it wasn't AI coded. It's like 200 lines. I wanted to learn termbox2.h a bit more than I already had.
Yea I was pleasantly surprised by how simple the code is when I read it. Honestly a great example of what termbox2 is capable of. Very nice!
And now I know about termbox2, which looks very cool. Looking through the example projects[1] in the README I also found ictree[2], which does exactly what I was looking for yesterday (turning the output of `find` into an ncdu-like/interactive tree interface). I didn't manage to find something for that through googling around or asking LLMs, but thanks to you posting this here I did, so thanks!
I absolutely fail to see the problem and I think the whole "best to stick to built in linux commands" is an utterly dinosaur-esque take that can, and will, and should, go extinct in the age of AI-assisted coding.
It is interesting that somehow every conversation now pivots to LLM's. It's almost like people are paranoid or something. I have no issue with AI. But it should be used carefully when learning/working so you don't miss the little details that usually make a big difference later. But to each their own.
It is just getting tiring that people assume more and more that things were written with AI for everything. It's like, OMG, can you stop it for a second. And who cares, really. Do your due diligence, check the code and decide for yourself. But maybe, this is just projection. Or a nice way of insulting/dismissing people, which I find quite funny.
And like you said, the age of AI-assisted coding is already here. There is beauty in piping core utils together and being really productive with them. No doubt about it. But there are also new ways of computing emerging, and we should learn about that too.
Not a fan of these "Coding for fun" things. Code for a job to earn money, yes, a side project where there is an end goal, yes. This seems like a waste of time for working developer.
Maybe it's useful for people trying to learn but also becoming pointless now as all Junior dev roles can be done with AI.
I mean do plumbers have an advent of plumbing where they try and unblock shit filled toilets for fun?
> I mean do plumbers have an advent of plumbing where they try and unblock shit filled toilets for fun?
Yes, plumbers and other types of craftspeople and technicians do also have these little fun competitions. Why shouldn't they?
I think the reason some of us programmers do these things, is likely because many (myself included) entered the field as enthusiasts and hobbyists in the first place.
>I mean do plumbers have an advent of plumbing where they try and unblock shit filled toilets for fun?
No, but you’ll see it for writers, musicians, and the like.
Engineering (software or not) can be an intellectually rewarding experience for many. I don’t know why some people find this something to scoff at, would you rather have no pleasure derived from your work?
I can't find it, but this question got asked somewhere (Reddit maybe) about 8-10 years ago, and a plumber took the time to respond that many plumbers are actually very passionate about what they do. They don't specifically unclog toilets for fun, but there are plumbers that spend a lot of their free time on plumbing forums, and even some who have projects experimenting with different ways to install certain things.
> mean do plumbers have an advent of plumbing where they try and unblock shit filled toilets for fun?
You've obviously never watched "Drain Cleaning Australia" on YouTube!
Yes, some people find this stuff fun, because they find coding fun, and don't typically get to do the fun kind of coding on company time. Also, there'd be a hell of a lot less open source software in the world if people didn't code for fun.
Let people enjoy things. Just because you don't like that par of your job as much as them doesn't mean they're wrong.
Scaling got us here and it wasn't obvious that it would produce the results we have now, so who's to say sentience won't emerge from scaling another few orders of magnitude?
Of course there will always be research to squeeze more out of the compute, improving efficiency and perhaps make breakthroughs.
Another few orders of magnitude? Like 100-1000x more than we're already doing? Got a few extra suns we can tap for energy? And a nanobot army to build various power plants? There's no way to do 1000x of what we're already doing any time soon.
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.
That's not the point - McDonald's has 40000 joints - the most popular restaurant in the world. Still doesn't make it the best food option.
Yes, Emacs is not popular, but if you look deeper, you may find unsurprisingly that most Emacs coders are strong developers. That correlation isn't coincidental - you don't stick with Emacs unless you're willing to learn; it effectively teaches you about Lisp, extensibility, and programming in general.
Yet, they are not talking about general popularity of editors among devs, but about people who ever tried Emacs - the argument is that the majority of them try, fail and abandon it. For which obviously there's no polemical (or otherwise) data points.
I've installed emacs now on ArchLinux Wayland system and its window refuses to resize (on purely default settings), and freezes the contents until I move it. Very refreshing indeed.
I bet this is some kind of a known issue, but that just reinforces my original point above.
I never had what you describe. The variability there could be almost random - which version of Emacs you're installing? How are you installing it? Are you trying to build it from source? What renderer are you using - there are several: Lucid, Motif, GTK, NS, W32, Haiku, Android, Cairo, Pgtk. Perhaps it's installing different renderer instead of using pgtk. Maybe it's not a bug with Emacs but with the package that bundles it for your distro?
> how it's not an Emacs issue if it only happens with emacs?
It does seem to be an Emacs issue. But it is a specific issue that happens on the combination of your hardware and your OS configuration.
Yes, I'm always having "special" problems. It's probably due to the fact that I jump around platforms a lot between Linux, macOS and Windows, mixed GUI and ssh.
For example, macOS emacs always starting at the bottom of the window stack instead of the top. macOS emacs having different font notation than Linux emacs, so maintaining common config is hard. Terminal emacs -nw having its own set of rules, and M-x needs to be addressed with ESC x. Etc, etc.
Yeah, I admit, fair complaints. Emacs can be tricky to render things exactly how you like - I use it on Mac, Linux, GUI and terminal and do have different semantics for each.
The tradeoff is that Emacs does let you handle it all - you're not forced to accept platform defaults like in some editors. Most editors have their UI/behavior largely baked in by the platform. You can customize colors and keybindings, but the fundamentals - window management, font rendering, how system keys work, terminal integration - are mostly dictated by whether you're on Mac, Windows, or Linux.
So when you have mac Emacs behaving differently than Linux Emacs, it's not because the software forced you into that corner - it's because the underlying systems are different and Emacs exposes that difference rather than hiding it behind a unified abstraction layer.
Emacs gives you the rope to make things consistent across platforms, but also the rope to hang yourself. Other editors pre-tie the knot for you.
> one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work
I use over 300 hundred packages in my Emacs setup. I honestly not sure if I can install even half of that number of VSCode extensions and expect it to still run smoothly, maybe people do that, I just don't know.
They are called "packages" and not "extensions" for a reason - an extension that e.g., ships with a browser has limitations. In Emacs I can reuse functions of one package in another - in VSCode they have to be explicitly exposed via public API, must be activated in order, they need to be aware of their extension IDs, there's no discovery mechanism - in Elisp, I don't have to deal with any of that.
in Emacs I can explore, modify and bend the source code of any package - built-in or third-party. I can do it in a way that is simply impossible anywhere else. I can granularly change selected behavior of any command without having to rewrite it fully.
That "just works™" part I don't ever buy it - all software is faulty by nature. In Emacs, when something fails - I know exactly how to troubleshoot it, to the specific line in the specific package code; I can profile; debug and trace it. I can modify code in question in a scratch buffer and immediately check how it affects things. Not only I don't have to restart anything, I don't even have to save that code anywhere.
You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing - for what the most "modern" alternatives simply have no answers.
I agree, Emacs is not for the faint-hearted - many people (maybe most) lack the patience required to grok it. Yet make no mistake, those who have tamed this beast are not staying in it simply because "they don't know any better". They know - something better is yet to be made, if ever. VSCode is great, yet still not better.
Learning Emacs has liberated me from experiencing tool-FOMO ever again - I can switch to VSCode without abandoning Emacs, and I can even probably figure a way to control one from another if I get annoyed enough; I just never found a pragmatic reason to use VSCode more. So really, I have zero envy or crave to even become a full-time VSCode user; if anything, I might be forced into it by circumstances, but that's a different story.
> In Emacs I can reuse functions of one package in another
You say like it's some kind of feature, but for me it sounds like a potential for name clash, and using private API which is prone to change/break.
> You call it "a legacy editor" without the slightest clue of what Emacs hackers are capable of doing
The thing is that is was VSCode which has brought us LSP, not "emacs hackers". It was VSCode which has brought us LLM Agent mode. All editors are catching up to VSCode, not the other way around.
LSP, LLM, ssh/docker/podman remote development, what's the Emacs answer to those? (I mean, nowadays vim+emacs have their own LSP clients built-in, years after VSCode)
I'd prefer Emacs Lisp had Common Lisp style packages (with namespaces and exports), but in practice it's not much of a problem. Emacs is intended to be programmed by its users, so you don't have "private APIs" in the same way proprietary systems do. Actually internal functions and variables are usually marked with naming conventions these days.
LSP is a great thing to have, but it's actually much less capable than something like SLIME. If you've used SLIME, you'll see there's no comparison. LSP is a lot better than the nonsense I had to go through to get Java completions in the early 2000s, and I'm thankful to have it.
Oh, you just have no idea. It feels absolutely empowering and immensely liberating to have access to EVERY single line of code running and affecting your system editor. Whenever I need to solve a problem, I don't need to ask permissions, send PRs, dig through API documentation, google for answers, yell at LLM for not giving me answers - I can modify any behavior of any function on the fly and just move on. All that "it just works™" promise of other editors quickly evaporates when I, as a programmer, feel out of control of whatever happens on MY computer. Sure, yes, there's always a possibility that my "stupid hacks" just break for no apparent reason. Except, it rarely happens in practice, and when it does, I know how to quickly fix or put a workaround, because I precisely can pinpoint the exact line of code. Last time when something broke and it took me more than ten minutes to figure it out was about two years ago - the combination of multiple upstream updates and my lousy customization on top confused me for some time - it's all about trade offs, I'm happy to spend 15 minutes once every few years to fix some shit, if that gets me complete and total control over my environment.
I'm a hacker, not a florist - I want precision and complete transparency, not pretty buttons. I don't want any magic - I can't trust some extension to "just work" on a button click, without precisely knowing what it installs, where, and to what extent.
> what's the Emacs answer to those?
Ah, just like I said before, you're talking about things as if you're staring at the surface of the calm water of a lake. Except for an ocasional splash, it may seem lifeless to you, yet you don't have the faintest idea of its depths or what lies beneath.
There's currently an implosion of different LLM packages for Emacs - gptel, gptel-agent, ECA, agent-shell, claude-code, claude-code-ide, monet, claude-repl - and numerous others I haven't even heard of, these are just off the top of my head.
Emacs community may not be big enough and may lack incentives to constantly innovate, but they have no problem borrowing ideas from other places.
> All editors are catching up to VSCode
Wake me up when they figure out things like indirect buffers and executable source blocks in different PLs that can pipe data into one another, or when someone uses VSCode to control their window manager. Or when I can use literate programming to manage my dotfiles. And I haven't even gotten to the REPL part, even with Joyride it still falls short - there's no "I can hook to everything and redefine anything" in Code.
A lot of Apple products are designed to best work with other Apple products, that's part of their selling point. Would it not be easier to just buy non Apple headphones if you are not in the Apple eco system?
No, they’re designed to work worse with non-Apple products to keep people in the Apple ecosystem. Sure, if you’re not already in the ecosystem it does make sense to buy other products. But if you already own AirPods then you’re reluctant to switch to Android or Linux/Windows, because you either have a degraded experience or have to shell out for new stuff.
It’s convenient only as long you stick to their closed ecosystem. Requiring a device to identify as an Apple device to expose all features is an anti-feature. The devices should expose all features regardless, and leave it to the device/platform vendor to implement the config software.
If it’s vertical integration producing results, that’s all right.
If it’s consciously kneecapping the device for all manufacturers except yours, it’s not a practice beneficial to anyone but monopolies, so consumer laws should prevent it.
This repo seems to prove the case of AirPods is closer to the latter.
“Work best” is giving Apple the benefit of the doubt here. The point of standards like Bluetooth is to avoid vendor lock-in and promote interoperability. If Apple chooses to leverage the spec to produce a product that has degraded functionality when used with other vendors, that goes against the spirit of the spec and makes it worthless.
You might argue, well why did Apple choose to use Bluetooth at all if they’re not going to participate in the interoperability motive? Because initially (think early iPhones) Apple did not design wireless communication modules and benefits from buying COTS from existing vendors.
So would it be easier to just participate in vendor lock-in? Let me ask you, do you enjoy being able to fill up a car at any gas station, or charge your car at any 120V outlet? Standards usually benefit everyone.
Yet if someone likes the sound quality, fit, or ANC of AirPods (which are genuinely good), why should they lose out on functionality just because they're not using an iPhone?
I'm all for everything being compatible with everything, but why should apple invest resources in testing/debugging android compatibility for something that they make?
There is a vast difference between testing and debugging and not intentionally making your product worse when on a standard BT connection which is basically what Apple is doing.
There is zero business sense in making it work as good on non Apple phones. There are plenty of other headphones to choose from that work well with android etc.
I decided to not buy another iPhone when I changed phone because I dislike how Apple both overprices the phone in Europe yet refuse to ship features and keep lying through their teeth about the impact of regulation. I would still like to keep using my AirPods which work fine and I have already paid.
You must not use Kagi because a "human slop" system is available on both Kagi and HN. It's called a downvote and the article has an image how you can downvote links in search results. Just an FYI why you're getting downvoted for posting a dire comment yourself.
Then people can downvote AI slop or Human slop equally. Why do we need to discriminate against digital intelligence which is often leagues above the average mouth breathing Joe.
Because digital intelligence isn’t leagues above the average mouth breathing Joe. With out the Joe there is zero digital intelligence. Llms being trained on the internet and a bunch of media aren’t the smartest brain in the world. It’s just compression of intelligence and a lot of media is trash. Likely Llms are dumber than the average Joe just more well read.
This. There's just as many human commenters and content creators that generate plenty of human slop. And there are many AI produced content that is very, very interesting. I've subscribed to a couple of newsletters that are AI generated which are brilliant. Lot's of project documentation is now generated by AI which can, if well-prompted, capable of great docs that are deeply rooted in the code-as-primary-source and is eadier to keep up to date. AI content is good if the human behind it is committed to producing good content.
Hack, that's why I use Chatgpt and other LLM chat, to have AI generate content taylored for my reading pleasure and specific needs. Some of the longer generations of AI research mode I did lately are among my personal best reads of the year - all filled with links to its sources and with verified good info.
I wish people generating good AI responses would just feel free to publish it out and not be bullied by "AI slop detectors by Kagi" that promise to demote your domain ranking. Kagi: just rank the quality and veracity of the content, independently of if it's AI or not. It's not the em-dashes that make it bad, it's the sloppy human behind the curtain.
reply