it came up in the SBCL mailing list as well, and its author has been commenting there as well. seems like it has some legs! would be a very nice feature to have.
"Secure" workplaces means that you have to have the appropriate clearances and background checks to be allowed in and out. I'm sure there are more secure workplaces, but the security of your average SCIF largely depends on the people allowed inside of it not being bad actors.
Outside of strip searches upon arrival and leaving I'm not sure how you could eliminate that risk.
I agree with you on multithreading. But for most Emacs users, the rich and highly customisable keyboard-driven UI (including packages like embark, which-key, transient, hydra, ivy/helm/vertico, etc.) is one of its strengths over traditional GUI IDEs. It doesn't need to be "state of the art" to be good, and there's a reason that Emacs has remained popular despite its age. Sure, it's not going to appeal to most VS Code users, but that isn't the point of Emacs.
Emacs isn't popular. It might've been in the 90s, but its star has faded now. It has niche appeal at best. Virtually everyone I interact with professionally views it as a dim memory best left in the past, or as something just inscrutably weird. Part of the reason why is "it's the UI, stupid". It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.) Most developers these days were brought up with Windows or Mac; they don't want to pretend to be using a PDP-11 or Lisp machine. One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.
> It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.)
> ...
> One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.
I started using Emacs on a Mac recently and was pleased to discover that it is, in fact, consistent with other programs.
- Cmd-C/X/V work as expected (copy/cut/paste from system clipboard)
- Cmd-Z undoes,
- Cmd-O brings up the open-file dialog, Cmd-T opens a new tab,
- Cmd-F invokes search and Cmd-L goes to line, and so on.
It uses the same global menu bar as other programs, and setting the font from the menu works. The only thing that didn't work is using Cmd-Shift-? to search through menu bar options. This is GNU's official MacOS build, not the custom-built emacs-mac or emacs-plus packages.
Last year I helped a non-programmer get started with Emacs (for the first time) on a Mac. After a couple of weeks their only remarks were that the customize interface looks a little dated and the config/custom file has a weird format. They never brought up the keybindings or other UI as an issue. Now I understand why -- Emacs is a reasonably good citizen on MacOS.
On macOS some of the Emacs keybindings also work system-wide. You can e.g. use C-a/e, C-k, and C-n/p/f/b in every macOS text field, like e.g. in browser text fields. This is one of the main macOS features I miss on GNU/Linux. (Actually, that subset of Emacs keybindings even works on iPad with an external keyboard.)
Aside from keybindings, there are also some packages that provide deeper integration with macOS. For example, org-mac-link can save Org-mode links to currently open emails in Mail.app. And the built-in `C-x m` can author emails that are then sent to Mail.app for further processing, if you’re not able to use mu4e and similar (e.g. strict Exchange email servers).
It's popular in the sense that there's still a large community which actively uses it, develops packages for it, writes about it, etc. I didn't mean to imply that it's popular in the sense that it has widespread or mass adoption.
I think the point you're missing is that Emacs just isn't meant to appeal to people who want a mouse/visual based UI. More traditional editors are "better" for those types of people, but that doesn't make them "better" in any kind of absolute sense like you are implying. There are plenty of people for whom a traditional editor is far worse than Emacs. "Better" is subjective.
I love Emacs, and while that tour doesn't quite look 1978, it sure doesn't look 2026 either. Maybe somewhere in the middle.. yup, 2002 seems about right.
Don't get me wrong, I don't mind old aesthetics, but... yes? Well I wasn't exactly alive in 1978 but all the screenshots look like they are at least 20 years old
Firstly, the original comment was about UI rather than aesthetics. Secondly, as with everything else in Emacs, you can customise the appearance however you want. Those screenshots are from vanilla Emacs which is admittedly rather ugly. Most people heavily customise, or use an Emacs distro like Spacemacs (https://www.spacemacs.org/) or Doom (https://github.com/doomemacs/doomemacs?tab=readme-ov-file) which have more sensible default appearance configs.
he is not saying he doesn't want to do bookclubs he is saying he does not want to spend more time to do bookclubs than he previously did, it is not beyond the wit of man to efficiently pick out a genuine request, but even with efficiency time and effort required is not null.
If there is more slush and the fraudulent slush increases in quality and scope it must mean that the wit, effort and time required must also increase to deal with the problem.
Dealing with problems that do not give one a return on the investment seems not worth doing, especially when it turns out the most efficient way to deal with this particular problem is to absolutely refuse to do any book club stuff.
It's not a hard problem to solve. Post a blog post, say include this word in the subject line if you want your request to be considered, route those emails to a separate folder.
Whether there's a thousand spam or a million spam is not at all relevant.
Based on the example emails he posts, the AI bot is NOT scraping his website to individualise the messaging. It isa bulk approach based on ai summaries of the actual books
These scams are a variation of the Nigerian prince scam; they rely on volume mostly
Developers never had "intellectual property". Under capitalism, only billion-dollar corporations do. So the problem with AI isn't that it violated some license. The real problems are that people are losing jobs, that the Internet and our community gets clogged up with more low-effort slop competing for our attention than ever before, and that the products we are all forced to use are becoming worse because corporations are trying to shove AI-features into them and put quotas on engineers to vibe-code as much as possible. There are definitely others. "Copyright" is not even scratching the surface of real problems with LLMs, and many of the people leading the charge in pointing out the evil and hypocrisy of AI companies are themselves copyright abolitionists.
HN was never the place to add trendy, unnecessary "features" and I doubt there would be a point in adding this one, considering how it seemingly goes against the entire ethos of the community: engaging with the substance of what the people are saying.
reply