sueden.social

Nick AndersonAgentic LLM use in Emacs using Model Context Protocol (MCP) in org-mode with gptel <a href="https://youtu.be/Hkih7jaqOnE?si=czWDmYqsT4NBYnNA" rel="nofollow noopener" translate="no" target="_blank">https://youtu.be/Hkih7jaqOnE?si=czWDmYqsT4NBYnNA</a><a href="https://fosstodon.org/tags/emacs" class="mention hashtag" rel="nofollow noopener" target="_blank">#emacs</a> <a href="https://fosstodon.org/tags/orgmode" class="mention hashtag" rel="nofollow noopener" target="_blank">#orgmode</a> <a href="https://fosstodon.org/tags/gptel" class="mention hashtag" rel="nofollow noopener" target="_blank">#gptel</a>

Phil<code>gptel-org-tools</code> update. 1. Cloned to <a href="https://codeberg.org/bajsicki/gptel-org-tools" rel="nofollow noopener" target="_blank">https://codeberg.org/bajsicki/gptel-org-tools</a>, and all future work will be happening on Codeberg. 2. Added <code>gptel-org-tools-result-limit</code> and a helper function for it. This sets a hard limit on the number of characters a tool can return. If it's over that, the LLM is prompted to be more specific in its query. Not applied to all tools, just the ones that are likely to blow up the context window. 3. Added docstrings for the functions called by the tools, so LLMs can look up their definitions. 4. Improved the precision of some tool descriptions so instructions are easier to follow. 5. Some minor improvements w/r/t function names and calls, logic, etc. Basic QA. Now, as a user: 1. I'm finding it increasingly frustrating that Gemma 3 refuses to follow instructions. So here's a PSA: Gemma 3 doesn't respect the system prompt. It treats it just the same as any other user input. 2. Mistral 24B is a mixed bag. I'm not sure if it's my settings or something else, but it fairly consistently ends up looping; it'll call the same tool over and over again with the exact same arguments. This happens with other models as well, but not nearly as frequently. 3. Qwen 2.5 14B: pretty dang good, I'd say. The Cogito fine-tune is also surprisingly usable. 4. Prompting: I have found that a good, detailed system prompt tends to /somewhat/ improve results, especially if it contains clear directions on where to look for things related to specific topics. I'm still in the middle of writing one that's accurate to my Emacs set-up, but when I do finish it, it'll be in the repository as an example. 5. One issue that I still struggle with is that the LLMs don't take any time to process the user request. Often they'll find some relevant information in one file, and then decide that's enough and just refuse to look any further. Often devolving into traversing directories /as if/ they're looking for something... and they get stuck doing that without end. It all boils down to the fact that LLMs aren't intelligent, so while I have a reasonable foundation for the data collection, the major focus is on creating guardrails, processes and inescapable sequences. These will (ideally) railroad LLMs into doing actual research and processing before they deliver a summary/ report based on the org-mode notes I have. Tags: <a href="https://fed.bajsicki.com/tags/Emacs" rel="nofollow noopener" target="_blank">#Emacs</a> <a href="https://fed.bajsicki.com/tags/gptel" rel="nofollow noopener" target="_blank">#gptel</a> <a href="https://fed.bajsicki.com/tags/codeberg" rel="nofollow noopener" target="_blank">#codeberg</a> <a href="https://fed.bajsicki.com/tags/forgejo" rel="nofollow noopener" target="_blank">#forgejo</a> <a href="https://fed.bajsicki.com/tags/orgmode" rel="nofollow noopener" target="_blank">#orgmode</a> <a href="https://fed.bajsicki.com/tags/orgql" rel="nofollow noopener" target="_blank">#orgql</a> <a href="https://fed.bajsicki.com/tags/llm" rel="nofollow noopener" target="_blank">#llm</a> <a href="https://fed.bajsicki.com/tags/informationmanagement" rel="nofollow noopener" target="_blank">#informationmanagement</a> <a href="https://fed.bajsicki.com/tags/gptelorgtools" rel="nofollow noopener" target="_blank">#gptelorgtools</a> PS. Links should work now, apparently profile visibility affects repo visibility on Codeberg. I would not have expected that. PPS. Deleted and reposted because of strong anti-bridge sentiment on my part. Screw Bluesky and bots that repost to it. Defederated: newsmast.*

Phil<code>gptel-org-tools</code> update. Edit: there's some kind of issue with <a href="https://social.anoxinon.de/@Codeberg" class="u-url mention" rel="nofollow noopener" target="_blank">@Codeberg@social.anoxinon.de</a> which prevents the link from working (returns 404). The old (but up to date) repo is here: <a href="https://git.bajsicki.com/phil/gptel-org-tools" rel="nofollow noopener" target="_blank">https://git.bajsicki.com/phil/gptel-org-tools</a> 1. Cloned to <a href="https://codeberg.org/bajsicki/gptel-org-tools" rel="nofollow noopener" target="_blank">https://codeberg.org/bajsicki/gptel-org-tools</a>, and all future work will be happening on Codeberg. 2. Added <code>gptel-org-tools-result-limit</code> and a helper function for it. This sets a hard limit on the number of characters a tool can return. If it's over that, the LLM is prompted to be more specific in its query. Not applied to all tools, just the ones that are likely to blow up the context window. 3. Added docstrings for the functions called by the tools, so LLMs can look up their definitions. 4. Improved the precision of some tool descriptions so instructions are easier to follow. 5. Some minor improvements w/r/t function names and calls, logic, etc. Basic QA. Now, as a user: 1. I'm finding it increasingly frustrating that Gemma 3 refuses to follow instructions. So here's a PSA: Gemma 3 doesn't respect the system prompt. It treats it just the same as any other user input. 2. Mistral 24B is a mixed bag. I'm not sure if it's my settings or something else, but it fairly consistently ends up looping; it'll call the same tool over and over again with the exact same arguments. This happens with other models as well, but not nearly as frequently. 3. Qwen 2.5 14B: pretty dang good, I'd say. The Cogito fine-tune is also surprisingly usable. 4. Prompting: I have found that a good, detailed system prompt tends to /somewhat/ improve results, especially if it contains clear directions on where to look for things related to specific topics. I'm still in the middle of writing one that's accurate to my Emacs set-up, but when I do finish it, it'll be in the repository as an example. 5. One issue that I still struggle with is that the LLMs don't take any time to process the user request. Often they'll find some relevant information in one file, and then decide that's enough and just refuse to look any further. Often devolving into traversing directories /as if/ they're looking for something... and they get stuck doing that without end. It all boils down to the fact that LLMs aren't intelligent, so while I have a reasonable foundation for the data collection, the major focus is on creating guardrails, processes and inescapable sequences. These will (ideally) railroad LLMs into doing actual research and processing before they deliver a summary/ report based on the org-mode notes I have. Tags: <a href="https://fed.bajsicki.com/tags/Emacs" rel="nofollow noopener" target="_blank">#Emacs</a> <a href="https://fed.bajsicki.com/tags/gptel" rel="nofollow noopener" target="_blank">#gptel</a> <a href="https://fed.bajsicki.com/tags/codeberg" rel="nofollow noopener" target="_blank">#codeberg</a> <a href="https://fed.bajsicki.com/tags/forgejo" rel="nofollow noopener" target="_blank">#forgejo</a> <a href="https://fed.bajsicki.com/tags/orgmode" rel="nofollow noopener" target="_blank">#orgmode</a> <a href="https://fed.bajsicki.com/tags/orgql" rel="nofollow noopener" target="_blank">#orgql</a> <a href="https://fed.bajsicki.com/tags/llm" rel="nofollow noopener" target="_blank">#llm</a> <a href="https://fed.bajsicki.com/tags/ai" rel="nofollow noopener" target="_blank">#ai</a> <a href="https://fed.bajsicki.com/tags/informationmanagement" rel="nofollow noopener" target="_blank">#informationmanagement</a> <a href="https://fed.bajsicki.com/tags/gptelorgtools" rel="nofollow noopener" target="_blank">#gptelorgtools</a>

PhilSo currently I'm hosting <code>gptel-org-tools</code> on my own forge... <a href="https://git.bajsicki.com/phil/gptel-org-tools" rel="nofollow noopener" target="_blank">https://git.bajsicki.com/phil/gptel-org-tools</a> I can't seem to find a good way for people to create issues. I thought that creating issues via email was a thing with Forgejo, but it appears not. So here's a poll. Despite my hatred of Microsoft, is it for the best to move the repo to GitHub? Or is there some way to federate with GitHub users so I don't need to open public sign-ups on my git? I'm not exactly clear on what the move is here. <a href="https://fed.bajsicki.com/tags/Emacs" rel="nofollow noopener" target="_blank">#Emacs</a> <a href="https://fed.bajsicki.com/tags/gptel" rel="nofollow noopener" target="_blank">#gptel</a> <a href="https://fed.bajsicki.com/tags/gitforge" rel="nofollow noopener" target="_blank">#gitforge</a> <a href="https://fed.bajsicki.com/tags/forgejo" rel="nofollow noopener" target="_blank">#forgejo</a> <a href="https://fed.bajsicki.com/tags/github" rel="nofollow noopener" target="_blank">#github</a> <a href="https://fed.bajsicki.com/tags/microsoft" rel="nofollow noopener" target="_blank">#microsoft</a> <a href="https://fed.bajsicki.com/tags/foss" rel="nofollow noopener" target="_blank">#foss</a>

PhilAnd just a day later, here's a git repo with more philosophy than good code. I think the philosophy part is more important personally, the code we can fix later. <a href="https://git.bajsicki.com/phil/gptel-org-tools" rel="nofollow noopener" target="_blank">https://git.bajsicki.com/phil/gptel-org-tools</a> TL;DR: Emacs (and its ecosystem) makes the whole vectorization/ RAG/ training stuff entirely redundant for this application. Yes, this code fails still... a bunch, especially given the current lack of guardrails. But the improvement I've seen in the last few days makes me cautiously believe that with enough safeguards and a motivating enough system prompt, an active assistant may be possible. Image attached isn't nearly as good as I've seen, but it's an off-hand example that demonstrates it working. The only thing missing for me to be happy with this is one of those organic, grass-fed LLM models whose existence isn't predicated on theft. <a href="https://fed.bajsicki.com/tags/emacs" rel="nofollow noopener" target="_blank">#emacs</a> <a href="https://fed.bajsicki.com/tags/orgmode" rel="nofollow noopener" target="_blank">#orgmode</a> <a href="https://fed.bajsicki.com/tags/gptel" rel="nofollow noopener" target="_blank">#gptel</a> <a href="https://fed.bajsicki.com/tags/orgql" rel="nofollow noopener" target="_blank">#orgql</a> RE: <a href="https://fed.bajsicki.com/notes/a6jw3n155z" rel="nofollow noopener" target="_blank">https://fed.bajsicki.com/notes/a6jw3n155z</a>

PhilSo... I strongly disagree with LLMs (mostly with the marketing and the training data issue), but I found a use-case for myself that they may actually be 'alright' at. I organize my life in <a href="https://fed.bajsicki.com/tags/Emacs" rel="nofollow noopener" target="_blank">#Emacs</a> <a href="https://fed.bajsicki.com/tags/orgmode" rel="nofollow noopener" target="_blank">#orgmode</a> It's great. But over the years, my notes and journals and everything have become so large, that I don't really have a grasp of all the bits and pieces that I have logged. So I started using org-ql recently, which works great for a lot of cases, but not all. Naturally, I wanted more consolidation between the results, and better filtering, as well as a more general, broad view of the topics I wanted to look up in my notes. So I started writing some tooling for <a href="https://fed.bajsicki.com/tags/gptel" rel="nofollow noopener" target="_blank">#gptel</a>, to allow LLMs to call tools within Emacs, and leverage existing packages to do just that. It's in its inception, and works only 20-25% of the time (because the LLM needs to write the queries in the first place), but it works reasonably well even with smaller models (Mistral Small 24B seems to do alright with 16k context, using llama.cpp). In general: - It kinda works, when it wants to. - The main failure point at the moment is that the LLM isn't able to consistently produce proper syntax for org-ql queries. - The context window sucks, because I have years of journals and some queries unexpectedly explode, leading to the model going stupid. So far it's been able to: - retrieve journal entries - summarize them - provide insights on habits (e.g. exercise, sleep quality, eating times) - track specific people across my journal and summarize interactions, sentiment, important events It doesn't sound like a lot, but these are things which would take me more time to do in the next year than I already spent on setting this up. And I don't need to do anything to my existing notes. It just reads from them as they are, no RAG, no preprocessing, no fuss. At the same time, this is only part of my plan. Next: 1. Add proper org-agenda searches (such that the LLM can access information about tasks done/ planned) 2. Add e-mail access (via mu4e, so it can find all my emails from people/ businesses and add them as context to my questions) 3. Add org-roam searches (to add more specific context to questions - currently I'm basing this entire project around my journal, which isn't ideal) 4. Build tooling for updating information about people in my people.org file (currently I do this manually and while there's a bunch of stuff, I would love if it was more up to date with my journal, as an additional context resource) For now, this is neat, and I think there's potential in this as a private, self-hosted personal assistant. Not ideal, not smart by any means (god it's really really not smart), but with sufficient guardrails, it can speed some of my daily/ weekly tasks up. Considerably. So yeah. I'm actually pretty happy with this, so far. PS. <a href="https://fed.bajsicki.com/tags/orgql" rel="nofollow noopener" target="_blank">#orgql</a> because org-ql doesn't show as an existing tag.

oatmeal<a href="https://front-end.social/@DodoTheDev" class="u-url mention" rel="nofollow noopener" target="_blank">@DodoTheDev</a> in respect to mobile, I guess it depends on what you’re doing with the mobile client? Mostly viewing or you need to edit too? Syncthing should solve syncing any type of non virtual file, and now has an astounding iOS client. If you write in markdown any client should do on iOS for basic editing, and there are couple of org clients for basic editing or task management (orgro, scratch, plain org, journelly, beorg). I rarely edit on my phone. Emacs learning curve can be mitigated by starting with a configuration framework like doom or other. It’s not different than learning any other new software you pick up. Hopefully not being to use Ctl-c Ctl-v in emacs is not a showstopper, though there’s a package for that too… The return on the initial investment in learning <a href="https://kolektiva.social/tags/emacs" class="mention hashtag" rel="nofollow noopener" target="_blank">#emacs</a> is unmeasurable. Just have a look at the expanding ecosystem of <a href="https://kolektiva.social/tags/ai" class="mention hashtag" rel="nofollow noopener" target="_blank">#ai</a> packages to start with… from <a href="https://kolektiva.social/tags/gptel" class="mention hashtag" rel="nofollow noopener" target="_blank">#gptel</a> to ollama-buddy etc.

faried nawaz<blockquote>I was walking down the street in Riyadh and someone shouted "ya hmar!" at me. What did he mean?</blockquote><a class="hashtag" href="https://p.node.pk/tag/ollama" rel="nofollow noopener" target="_blank">#ollama</a> <a class="hashtag" href="https://p.node.pk/tag/deepseek" rel="nofollow noopener" target="_blank">#deepseek</a> <a class="hashtag" href="https://p.node.pk/tag/gptel" rel="nofollow noopener" target="_blank">#gptel</a>

Magitian<a href="https://mastodon.social/@nixCraft" class="u-url mention" rel="nofollow noopener" target="_blank">@nixCraft</a> AI in a text editor? Oh please, <a href="https://fedia.social/tags/gptel" rel="nofollow noopener" target="_blank">#gptel</a> in <a href="https://fedia.social/tags/emacs" rel="nofollow noopener" target="_blank">#emacs</a>.

Nick AndersonNew release of gptel yesterday: <a href="https://github.com/karthink/gptel/releases/tag/v0.8.5" rel="nofollow noopener" translate="no" target="_blank">https://github.com/karthink/gptel/releases/tag/v0.8.5</a><a href="https://fosstodon.org/tags/emacs" class="mention hashtag" rel="nofollow noopener" target="_blank">#emacs</a> <a href="https://fosstodon.org/tags/orgmode" class="mention hashtag" rel="nofollow noopener" target="_blank">#orgmode</a> <a href="https://fosstodon.org/tags/gptel" class="mention hashtag" rel="nofollow noopener" target="_blank">#gptel</a> <a href="https://fosstodon.org/tags/generativeai" class="mention hashtag" rel="nofollow noopener" target="_blank">#generativeai</a>

yugaego 🌍I've been occasionally using the gptel <a href="https://fosstodon.org/tags/LLM" class="mention hashtag" rel="nofollow noopener" target="_blank">#LLM</a> client in Emacs for several weeks now. It provides a sufficiently nice interface, and is configurable. It took me a couple of days to get used to it, and I'm looking forward to customizing (personalizing) UX a tiny bit more.Earlier, I was testing communication with <a href="https://fosstodon.org/tags/ChatGPT" class="mention hashtag" rel="nofollow noopener" target="_blank">#ChatGPT</a> via macGPT application. IMO, <a href="https://fosstodon.org/tags/gptel" class="mention hashtag" rel="nofollow noopener" target="_blank">#gptel</a> is a more flexible solution with a convenience of having it all under the hand in <a href="https://fosstodon.org/tags/Emacs" class="mention hashtag" rel="nofollow noopener" target="_blank">#Emacs</a>. <a href="https://github.com/karthink/gptel" rel="nofollow noopener" translate="no" target="_blank">https://github.com/karthink/gptel</a>

Frühere Suchanfragen

Suchoptionen

Verwaltet von:

Serverstatistik:

#gptel