There is still a "community" on platforms such as Mastodon, reddit, various repo's. But I don't think there is a single community that can be pointed to as "The Emacs community". This would also be "wrong" from a Libre Software point of view.
I understand your point of view, but as far as the Emacs community is concerned there is no problem.
Emacs is not an editor. Emacs is not an IDE.
Emacs is a platform to develop your own tooling. Text is the main interface Emacs offers.
I don't speak for the Emacs community, there isn't even such a thing except maybe semi related groups that share viewpoints, usage and interests. But on the whole, I don't think the "Emacs community" is looking for users or is looking to attract users. At least not users who are looking for "text editor experiences" that mimic or take inspiration from VS Code and the likes.
I generally try to avoid adding external links as I found that those resources tend to get lost very fast.
Of course, this is not always feasible, but whenever I can try to copy over the contents into my notes.
I agree that there is a steep learning curve compared to Github pull requests or Gitlab merge requests, but like many things the steep learning curve actually hides a very powerful tool. A famous example is the Linux Kernel, a project of such a size that simply can not work with the Github/Gitlab model.
Personally I find the information density of text to be the "killer feature". I've tried voice interaction (even built some AI Voice Agents) and while they are very powerful, easy to use and just plain cool, they are also slow.
Nothing beats skimming over a generated text response and just picking out chunks of text, going back and forth, rereading, etc.
Text is also universal, I can't copy-paste a voice response to another application/interface or iterate over it.
My personal view is that the search for a better AI User Interface is just the further dumbing down of the humans who use these interface. Another comment mentioned that the most popular platforms are people pointing fingers at pictures and without a similar UI/UX AI would never reach such adoption rates, but is that what we want? Monkeys pointing at colorful picture blobs?
Sure to protect your machine, but what about data security?
Do I want to allow unknown code to be run on my private/corporate data?
Sandbox all you want but sooner or later your data can be exfiltrated. My point is giving an LLM unrestricted access to random code that can be run is a bad idea.
Curate carefully is my approach.
Correct, I wouldn't use it myself as it's a trivial addition to your implementation. Personally I keep all my work in this space as provider agnostic as I can. When the bubble eventually pops there will be victims, and you don't want a stack that's hard coded to one of the casualties.
I was referring to letting LLM's search github and run tools from there. That's like randomly searching the internet for code snippets and blindly running them on your production machine.
The example given by Anthropic of tools filling valuable context space is a result of bad design.
If you pass the tools below to your agent, you don't need "search tool" tool, you need good old fashion architecture: limit your tools based on the state of your agent, custom tool wrappers to limit MCP tools, routing to sub-agents, etc.
The "Tool Search Tool" is like a clever addition that could easily be added yourself to other models / providers. I did something similar with a couple of agents I wrote.
First LLM Call: only pass the "search tool" tool. The output of that tool is a list of suitable tools the LLM searched for.
Second LLM Call: pass the additional tools that were returned by the "search tool" tool.
Sending the whole context on each user message is essentially what the model remembers of this conversation. ie: it is entirely stateless.
I've written some agents that have their context altered by another llm to get it back on track. Let's say the agent is going off rails, then a supervisor agent will spot this and remove messages from the context where it went off rails, or alter those with correct information.
Really fun stuff but yeah, we're essentially still inventing this as we go along.
I didn't glace at it, I read it :-)
The architecture is a 'unified memory bus', so yes the GPU has access to that memory.
My comment was a bit unfortunate as it implied I didn't agree with yours, sorry for that. I simply want to clarify that there's a difference between 'GPU memory' and 'system memory'.
The Frame.work desktop is a nice deal. I wouldn't buy the Ryzen AI+ myself, from what I read it maxes out at about 60 tokens / sec which is low for my use cases.
Qwen has some really great models. I recently used qwen/qwen3-next-80b-a3b-thinking as a drop-in replacement for GPT-4.1-mini in an agent workflow. Cost 4 times less for input tokens and half for output, instant cost savings.
As far as I can measure, system output has kept the same quality.