Android allows parents to monitor and control what apps children use, and for how long, on their devices.
So I block chrome, and require my permission to install any app. They get thirty minutes a day on devices that lack a browser or social media apps. Not even any YouTube.
They can browse the web on PCs that are visible to the whole living room.
That’s all in the right direction. I think there are other things OS vendors can do too - screen sharing and a logged timeline history of events would also be useful for parents.
We have tools to do this already - authentication apps, and so on - but it’s my firm opinion that these need to be built in to the OS. I’m happy to hear Android allows this to an extent already ..
Velocity is important because we all eventually die.
I've been following Haiku since it was announced. In that time a couple of personal friends have passed on, and a number of family members. In that time children have been born, gone to school, grown into adults, and had children of their own.
Projects that drag on forever make for an interesting artistic statement, but if their goals in any way include utility then velocity is important because time is important.
Not everything has to happen in your or my lifetime. Not everything will happen in our lifetimes. If time is so important, Haiku was never going to work for you anyways on account of it being niche, which adds friction, which adds time. Velocity isn’t going to fix this either
As I mentioned, projects that take a long time make for interesting artistic statements. But if the goal isn't performance art but is utility, then alacrity matters.
Many other niche projects have enjoyed enough velocity to have meaningful utility, in my lifetime. Linux was still niche when I started using it in '94.
Some people enjoy building things. It's not performance art, it's a hobby. Can Haiku not be a hobby for people who enjoy hacking away at BeOS? (You might think I'm splitting hairs here, but performance art is precisely the wrong analogy to use, since performance art is for the benefit of others. Performance art is inherently public and assessable in terms of how it reaches others, unlike hobbies. Performance art is env=PROD.)
Was the purpose of Haiku ever utility? What do you define as utility? If I spend a day building a shelf, does that have more or less utility than buying a shelf from IKEA? What if I like making shelves? What if I like making OSes? Does the shelf (/OS) that I build have less utility than the one from IKEA (/MS)?
In economics, utility is a measure of individual satisfaction. The person who likes tinkering with Haiku is deriving cold hard economic utility from Haiku right now. What should it matter to this person whether you find Haiku web scale and production ready? John Q Public is never going to run Haiku, no matter how much polish you throw at it. Why rush to some goal line that doesn't exist in the first place?
Tree sitter support is half baked in the same way official LSP support is, only kind of worse.
Eglot won't help you get your system ready for LSP work, it will only avail itself if what's there. It doesn't even auto detect and configure that, either. There's no user prompting, so you'll have to read the docs to know that this even needs to be done.
Similarly, tree sitter support doesn't include the grammars! And those aren't typically sitting in your package repository, so users have to find a grammar and compile it themselves. There's not even a good recommendation given by Emacs on where to get them, leaving users to hope that whatever repository showed up on a Google search is both in good working order and safe to use.
I speak only for myself and not the Emacs team, but ... IMO it shouldn't do this by default - unless there is a clear "winner" among all the choices.
IIRC, for eglot I had to install a Python language server. There are a bunch of them. Why would I want it to pick one by default?
I don't know if Emacs will ever have an IDE with TS and LSP working "out of the box" without some configuration. From my experience with Eglot, if it were enabled by default, it would confuse the heck out of some users who just want to, say, edit a Python script.
There are always opinionated releases like Doom Emacs or Spacemacs that can set whatever nice defaults you think should be there. Leave vanilla Emacs to be, well, vanilla. Emacs, while it can be a decent IDE, is not an IDE and shouldn't default to being one.
Typescript is a perfect example of why Emacs shouldn't own that setup. Typescript version 6 uses the "typescript-language-server" which is a totally stand alone nom package for lsp support.
Typescript 7, is incompatible with typescript-language-server and the compiler itself now acts as a lsp.
If Emacs handles that all by default it then needs to handle versioning of each language server itself across all operating systems, handle cases when different machines have different npm version managers, upgrades, etc...
It's not impossible but it's a lot to ask, and it requires more frequent version upgrades just to keep things in sync.
I couldn't even use the built in version of eglot and had to use ELPA version for bug fixes that affect c# LSP support that were committed to the package back in December.
Emacs makes many opinionated choices about defaults; if it didn't, it would launch to little more than an elisp REPL by default.
What's important is that _you can change it_. Good defaults ensure that Emacs doesn't repel new users and casual users and users who are not interested in fiddling.
And this isn't a matter of color theme default, or font default; this is a shipped feature that _does not function_ without changes to the defaults! By default, it does not work.
> if it didn't, it would launch to little more than an elisp REPL by default.
I'm confused. Have things changed? The scratch buffer it starts with is for writing elisp.
> this is a shipped feature that _does not function_ without changes to the defaults!
Do you know how many shipped features come with Emacs that don't function without changes to defaults?
A huge number of them! Stuff like hippie-expand, ibuffer, etc. This isn't something new - it's been that way for decades.
> Good defaults ensure that Emacs doesn't repel new users and casual users and users who are not interested in fiddling.
This has been argued to death forever. While even I think they can and should change some defaults, the reality is that Emacs as an ecosystem is doing just fine without so many new/casual users, and will continue to do so. They don't want to be something for everyone.
And while I don't have the latest Emacs, in my experience with eglot - it's simply not ready for the masses. I frequently get timeouts, and would often have to shut down and restart eglot. It's been a while since I had to, so perhaps they've fixed all the issues, but it's simply not as robust as what you'd get with other IDEs. I'd rather they address those issues than the ease of use.
It launches with a scratch buffer, menu bar with populated menus, a functional mini buffer, and so on. All of this is opinionated defaults and configurable with elisp.
And yes, much of Emacs is broken out of the box and it's been that way a long while. That's not a good thing.
Emacs isn't ready for the masses. Broken defaults, and a brittle experience once features are made working is standard.
I've used Emacs for thirty years now. I don't recommend it to new users.
It never will be. It's simply not a goal they have. It's tiring to keep hearing people point it out. Emacs is also not ready to be your web server. Or your Jira replacement. It's not a lot of things - we don't need to itemize them all.
I've written a lot of stuff. Some of it I released publicly. None of it is for the masses. There are better tools for the masses - let them use those!
> I don't recommend it to new users.
"New" to what? In general, I don't recommend Emacs unless someone shows genuine curiosity. I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."
Nevertheless, some not technically savvy users do use Emacs today because they needed help editing files on a remote machine and I couldn't teach vim because Emacs was all I knew :-)
> I always tell people "Give me any task, and I'll find a better tool than Emacs." And "If you want to get up and running quickly for your task, Emacs is not a good choice." Followed by "What makes Emacs worthwhile is you get it all in one package where they can interact with one another." And "It's a lifelong journey."
That is the proper response. These tools are designed for someone that does need them as they are, not for someone that just need some tools. Software like vim and emacs are in fact a whole workshop that you need to make your own. If you just want a tool, there are better software out there, but people that usually go for emacs wants a workspace, not just one tool.
The best tool is the one that makes completing tasks better: faster, easier, cheaper, or superior.
It takes significant usage and training to overcome the overhead that Emacs imposes. There are other tools that are fast, free, and capable which do not have this problem.
Even tools which are reasonably extensible. Like VSCode. There's good reason that all the new agentic development environments aren't forks of Emacs or NeoVim.
> There are other tools that are fast, free, and capable which do not have this problem.
You are merely mirroring what I said.
> There's good reason that all the new agentic development environments aren't forks of Emacs or NeoVim.
And there's nothing wrong with the fact that Emacs will never be the tool people fork for agentic (or IDE, or for any other purpose). That's not a mark against Emacs.
Because it's the question that I'm interested in. I use Emacs still because it's astoundingly mediocre at all things that I use it for; but always mediocre and never terrible. I would like to know if there's something it's the best at, besides being predictably mediocre.
I think eglot often just works now. I recently started doing c++ stuff, and it just detected clangd and I was off to the races with no config. Same with rust-analyzer for rust projects.
“ask” mode for installing tree-sitter grammars is the default setting. Tree-sitter modes broadly aren’t enabled by default, but that seems at least consistent with eMacs defaulting to very few modes enabled by default.
If it can't find an LSP binary, Eglot will prompt you to pick one, and tell you which one it was looking for. That seems reasonable to me. I wouldn't want Emacs to download and install random binaries on my system automatically.
My experience with Emacs 30 is that Eglot will prompt and show nothing of meaningful assistance beyond a name. That leaves me to run a google search to find whatever binaries fit the description.
They host binaries already; why not host all of the binaries necessary for the supported features to function?
Should they install make for you too (default command for compilation-mode) or the various sql client (for the sql-mode) pr a lisp runtime (for the repl)?
Firefox will continue to exist and be maintained by open source efforts.
I often wonder if the current model has been driving away contributors, since it _feels like_ contributing effort to support someone else's paychecque.
Continue to exist in what form? Seamonkey aka Netscape Navigator still exists. Firefox can keep existing but not get updated enough to be a viable alternative to Chromium anymore.
I wrote the initial support for chicken some 11 years ago; it wasn't _great_, but I see that Jao and others have worked on it some since then. Glad to see it's working well!
- Strings and symbols passed to foreign code are not copied, they are
passed directly, any mutations done by external code will be visible on the
Scheme side.
- Complex numbers, C structs and unions can now be passed directly as
arguments and returned as results when interfacing to C code.
Those were major bottlenecks for any FFI-heavy Chicken Scheme app, and would often result in brittle and unsafe abstractions to work around. Glad to see this changed.
My local library has access to Kanopy, Libby, and Blackstone. And as a Canadian, I've got CBC gem as well.
The available library of films, documentaries, books, and so forth is enormous. All bereft of ads, and mostly bereft of slop.
reply