Hacker Newsnew | past | comments | ask | show | jobs | submit | michaelanckaert's commentslogin

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 agree. I look at Emacs like a lisp interpreter with text editing primitives on which someone has built a decent editor.

There was a "community" about a decade or two ago. On Freenode IRC, there were regulars who hung around in #emacs and it was quite nice. There were no corporate sponsors or random startups trying to hire from there so it was genuinely just a bunch of people who enjoyed using Emacs and were chatting about it. It's a part of the reason I got really hooked into it. I still use Org heavily for meeting minutes etc.


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.


Working on improving AI Nexus - my custom LLM frontend that exposes all AI Models in a single interface: https://getainexus.com/


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.


This is great! We need more ASCII games/simulations and it's only a bonus if it's in Emacs :-)


Do you mind sharing your contact / shop? Email in profile if you don't want to share publicly.



I often use DuckDuckGo in HTML mode (https://html.duckduckgo.com/html/) when I'm using EWW in Emacs.


There's also the even more barebones DDG Lite: https://lite.duckduckgo.com

I use it often when on very slow or metered connections (still find some of those around).


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.


I would use the word "exception" rather than "example".

I doubt the next generation of programmers will have any idea what it means to contribute code "by mailing list".


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?


^ this. Careful design of what tools are passed when is key to good agent design.


Security nightmare inbound...

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.

Ref: GitHub: 35 tools (~26K tokens) Slack: 11 tools (~21K tokens) Sentry: 5 tools (~3K tokens) Grafana: 5 tools (~3K tokens) Splunk: 2 tools (~2K tokens)


Don't see whats wrong in letting llm decide which tool to call based on a search on long list of tools (or a binary tree of lists in case the list becomes too long, which is essentially what you eluded to with sub-agents)


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.


For that, we need sandboxes to run the code in an isolated environment.


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.


For data security, you can run sandbox locally too. See https://github.com/instavm/coderunner


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: