While packages like orderless provide flexible “any word, any order” completion, sometimes you want something lightweight and easy to tweak (well I do anyway). In this post, I’ll show you how to implement a simple orderless-like completion style using only Emacs Lisp, and how to integrate it smoothly into your workflow.

I created a new package!, here are the details: Bank Buddy is an Emacs package that provides financial analysis and reporting capabilities for your bank statements. It processes CSV bank statement data, categorizes transactions using customizable patterns, and generates detailed reports in Org-mode format.

There have been quite a few updates recently. The main highlights include support for attachments, so you can push a file to the chat directly from dired for potential inclusion in your next query. Vision support has been added for models that can handle it. If you supply the path to an image file in the chat, it will be processed. This means you can now, for example, extract text from images using models like o:gemma3:4b. I've also introduced the ability to save user system prompts. If you have a favorite prompt, or have crafted one that works especially well for you, you can now save it by category and title in a simple Org format for later recall. Prompt recall now works the same way as Fabric patterns and Awesome ChatGPT prompts. This makes it much easier to display the currently used system prompt concisely in the status bar, as it will be based on the prompt title (and thus likely the role). What else? Oh yes, I received a request for better context tracking. Now, when context is nearing full capacity, or has exceeded it, it will be indicated in the status bar! That’s probably it for the major changes. There was also some refactoring, but you probably don't care about that. Anyway, here is the full list of changes:

If you’re an Emacs user (which I know you are), especially one who lives in dired-mode, you’re probably familiar with the quick power of isearch for finding files or directories. But if you’re like me, you might have noticed a tiny speed bump in the workflow: after finding a file or directory with isearch, you would typically have to hit <enter> to exit the search, and then <enter> again to open the entry. That’s two steps for something that feels like it should be one and this has been a very minor annoyance for me for a very long time now.

While exploring Emacs-solo, I was struck by how closely its philosophy aligned with my own Emacs-DIYer project. The parallels were sometimes uncanny, for example, we had independently chosen identical keybindings like "M-s g" for grep functionality. I had been also considering "M-s f" for my find variant and was looking for a home for recentf, potentially at "M-g r". There were also some ideas around using other finding tools such as ripgrep and fd as a callout to some external tools and there were many other similarities.

More improvements to ollama-buddy https://github.com/captainflasmr/ollama-buddy

Several improvements in the latest Ollama Buddy updates (versions 0.9.21 through 0.9.35):

I'm having issues with isearch! I've been using fido-mode for a while now (I'm one of those weirdos who transitioned from the Vertico/Marginalia/Orderless stack back to an Emacs built-in) and have become accustomed to the flexible matching that fido offers. For example, I often shorten commands to find them, such as:

• Added ollama-buddy-awesome.el to integrate Awesome ChatGPT Prompts.

ollama-buddy-awesome is an ollama-buddy extension that integrates the popular Awesome ChatGPT Prompts repository, allowing you to leverage hundreds of curated prompts for various tasks and roles right within your Emacs environment, I thought that since I have integrated the fabric set of curated prompts, so then why not these!

I’ve added experimental support for Claude AI, aligning its implementation with my support for ChatGPT, to pave the way for external AI templating which should make it easier to integrate new models in the future. Like the ChatGPT implementation, it doesn’t stream tokens in real time but instead outputs the final result all at once. However, after testing it further, I’m actually starting to prefer it. The response speed is so fast that not seeing a real-time “Typing” indicator isn’t a big deal. I think that streaming feels more relevant for local LLMs running through ollama, where token generation is slower, making real-time output more useful.

This week in ollama-buddy updates, I have mostly been experimenting with ChatGPT integration! Yes, it is not a local LLM, so not ollama, hence entirely subverting the whole notion and fundamental principles of this package! This I know, and I don't care; I'm having fun. I use ChatGPT and would rather use it in Emacs through the now-familiar ollama-buddy framework, so why not? I'm also working on Claude integration too.

This week in ollama-buddy updates, I have been continuing on the busy bee side of things. The headlines are :

• Transient menu - yes, I know I said I would never do it, but, well I did and as it turns out I kinda quite like it and works especially well when setting parameters.
• Support for fabric prompts presets - mainly as I thought generally user curated prompts was a pretty cool idea, and now I have system prompts implemented it seemed like a perfect fit. All I needed to do was to pull the patterns directory and then parse accordingly, of course Emacs is good at this.
• GGUF import - I don't always pull from ollama's command line, sometimes I download a GGUF file, it is a bit of a process to import to ollama, create a model file, run a command, e.t.c, but now you can import from within dired!
• More support for the ollama API - includes model management, so pulling, stopping, deleting and more!
• Conversation history editing - as I store the history in a hash table, I can easily just display an alist, and editing can leverage the sexp usual keybindings and then load back in to the variable.
• Parameter profiles - When implementing the transient menu I thought it might be fun to try parameter profiles where a set of parameters can be applied in a block for each preset.

More improvements to ollama-buddy https://github.com/captainflasmr/ollama-buddy The main addition is that of system prompts, which allows setting the general tone and guidance of the overall chat. Currently the system prompt can be set at any time and turned on and off but I think to enhance my model/command for each menu item concept, I could also add a :system property to the menu alist definition to allow even tighter control of a menu action to prompt response.

Continuing the development of my local ollama LLM client called ollama-buddy… https://github.com/captainflasmr/ollama-buddy The basic functionality, I think, is now there (and now literally zero configuration required). If a default model isn't set I just pick the first one, so LLM chat can take place immediately.

I've been a busy little bee in the last few days, so quite a few improvements to ollama-buddy, my Emacs LLM ollama client, they are listed below:

Some improvements to my ollama LLM package… With the new multishot mode, you can now send a prompt to multiple models in sequence, and compare their responses, the results are also available in named registers.

Seems to be a common post at the moment, so I thought I would quickly put out there how I updated to Emacs 30.1. I use an Arch spin called Garuda, running SwayWM, so as its on wayland, this for me is simple, just update the system using pacman -Syu and emacs-wayland will pull in 30.1 automatically!

 ___ _ _      n _ n      ___       _   _ _ _
|   | | |__._|o(Y)o|__._| . |_ _ _| |_| | | |
| | | | | .  |     | .  | . | | | . | . |__ |
|___|_|_|__/_|_|_|_|__/_|___|___|___|___|___|

https://github.com/captainflasmr/ollama-buddy A friendly Emacs interface for interacting with Ollama models. This package provides a convenient way to integrate Ollama’s local LLM capabilities directly into your Emacs workflow with little or no configuration required. Latest improvements:

• Chat buffer now more prompt based rather than ad-hoc using C-c C-c to send and C-c C-k to cancel
• Connection monitor now optional, ollama status visibility now maintained by strategic status checks simplifying setup.
• Can now change models from chat buffer using C-c C-m
• Updated intro message with ascii logo
• Suggested default "C-c o" for ollama-buddy-menu
• defcustom ollama-buddy-command-definitions now will work in the customization interface.
• The presets directory on github contains elisp files that can be evaluated to generate a role-based menu.
• Added to MELPA, install using the following:

(use-package ollama-buddy
  :bind ("C-c o" . ollama-buddy-menu))

• and to add initial model:

(use-package ollama-buddy
   :bind ("C-c o" . ollama-buddy-menu)
   :custom ollama-buddy-default-model "llama3.2:1b")

I am currently using vc-mode for my source code configuration needs. I wouldn’t call myself a die-hard vc-mode user, (at least not yet!). To earn that title, I think I would need years of experience with it and scoffing at this newfangled thing they call magit, while my muscle memory recoils at the thought of reading and interacting with a transient menu!

I have been playing around with local LLMs recently through ollama and decided to create the basis for an Emacs package to focus on interfacing to ollama specifically. My idea here is to implement something very minimal and as light-weight as possible and that could be run out-of-the-ollamabox with no configuration (obviously the ollama server just needs to be running). I have a deeper dive into my overall design thoughts and decisions in the github README and there are some simple demos:"hello" https://github.com/captainflasmr/ollama-buddy

In my continuing quest to replace all my external use packages with my own elisp versions so I can still follow my current workflow on an air-gapped system, I would like to replace a single function I use often from embark embark allows an action in a certain context, and there are a lot of actions to choose from, but I found I was generally using very few, so to remove my reliance on embark I think I can implement these actions myself.

In this post, as part of my ongoing mission to replace all (or as many as possible) external packages with pure elisp, I’ll demonstrate how to implement a lightweight alternative to the popular rainbow-mode package, which highlights hex colour codes in all their vibrant glory. I use this quite often, especially when "ricing" my tiling window setup.

Navigating through lengthy org files can sometimes feel cumbersome. To address this I have tweaked org-goto to be a little more usable through the minibuffer completion system to jump to any org heading. I have been aware of the org-goto command for a while now, which technically, allows for the efficient navigation through an org file. Every now and then I give it a go, but it just feels clunky and some of the keybindings don't quite feel intuitively Emacs for some reason. Now my org files are getting more elaborate, I would like a better way to navigate and especially through the hierarchy of headings. What about org-imenu-depth I hear you say! Well as far as I can tell, this allows stepping through to a defined subheading level but while going through multiple menu/hierarchical selection steps. For efficiency, I would like a way to flatten the subheadings for a one-shot completion selection method. This is where org-goto can actually be adapted to satisfy this need, and I think leverages the org refile menu system.

ediff is one of my favourite tools in Emacs and I have recently found myself not only using ediff-buffers and vc-ediff often but also now having the need to compare two regions. For example, when developing new Elisp functions, I generally modify the bottom of my tangled init file and then evaluate/edit as necessary, or sometimes through the scratch buffer. However, for something more complex, for example, at the moment, I am trying to generate an RSS feed from my Hugo-based blog's Org file through org-publish. In this case, I prefer creating a separate directory where I can experiment with example files, generated files, and temporarily manage everything under version control. At the end of development, I could simply paste my function(s) back into my main configuration, however, as a software engineer, I am accustomed to using merging tools, so what better way to handle this than with ediff Given my development functions and my init file, I can't compare entire files to copy/merge the changes across, and VC in this case is not helpful. So, how do I compare two regions? In fact, is it even possible in Emacs? Well, yes, yes it is! (of course)

ediff-regions-linewise Run Ediff on a pair of regions in specified buffers. BUFFER-A and BUFFER-B are the buffers to be compared. Regions (i.e., point and mark) can be set in advance or marked interactively. Each region is enlarged to contain full lines.