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.

Previously, my/quick-window-jump was geared mostly toward managing two or more windows. The behaviour was straightforward:

• If two windows were open, the function would directly jump to the other window.
• For more than two windows, a key selection interface would allow you to pick a window to switch to.

However, the function didn’t handle a single-window scenario intelligently. A horizontal split from a single window is something I do very frequently, by frequently, I mean at least every minute! This split is currently bound to its own keybinding, but couldn't my ace-window defun clone do this? For example, I find that the transition from a single window to a split never happens vertically for me, so why not make my/quick-window-jump perform a horizontal split from a single window and then move the point to that window?

In addition, it is very rare for me to vertically split into more than two columns. I could probably drop my current horizontal split keybinding now. If I do require another horizontal split, the default C-x 3 is already bound to muscle memory.

Lets take this function to the next level of convenience, with a very simple change, simply an extra (length window-list) and the relevant logic.

As someone who enjoys using Emacs for almost everything, I recently began exploring an alternative Emacs-native method for publishing static websites.

Currently, I use [ox-hugo](https://github.com/kaushalmodi/ox-hugo) to build a static site from a single Org file, and it works beautifully for exporting content to Hugo-compatible Markdown. However, I wanted to create a backup web generation system entirely within Emacs that doesn't rely on external tools like Hugo and might fit into my overarching Emacs Enhancements project concept.

My Emacs Enhancements project focuses on replacing significant external packages that I commonly use with a collection of simple Elisp functions and built-in functionality. This approach is ideal for situations where I run Emacs on an air-gapped system or even on Windows, where I have found package management to be somewhat unreliable. You can check out my progress on [GitHub](https://github.com/captainflasmr/Emacs-enhanced).

Just a very quick one today.

I recently needed to find the number of days between two dates. I thought this would be easy in Emacs, and indeed it was, but as with most things in Emacs, you need to know exactly what you're doing. Here is the method I used:

The original implementation of my/quick-window-jump worked perfectly for multi-window setups. It enabled you to assign character labels to each window, display them as overlays within the windows themselves, and jump to your desired window by typing its corresponding key. However, for setups with just two windows (a very common scenario in Emacs), this process felt unnecessarily complicated. Why go through the entire label-assignment process when a single key press could suffice?

Already I think I can improve my/quick-window-jump: which was a window jumping mechanism I created in my previous post which uses a unique key identifier for window navigation just like ace-window but condensed into a minimal elisp defun implementation.

I thought I would share a simple concept that I have found very beneficial: creating an Emacs init file that remains almost fully functional for my use but doesn't include any external packages!

This post is more of a note to myself, something I can store in my single emacs blog org file, so if I forget again, I can quickly search.

I keep forgetting the keybinding to shrink and expand an org table.

I often define tables to have a narrower width than content using the <num> concept in the top line of the table, but when I want to expand, I just can't remember the keybinding.

A search in *help* for org-table-shrink and org-table-expand reveals nothing!

Just a quick one today.

In keeping with the ongoing effort to reduce friction in the venerable Emacs text editor, I realized that a common action I often perform is copying the entire contents of the buffer, usually for pasting elsewhere.

In this post, I'll walk you through how I use an Org Babel block to generate a dynamic Org table based on Org headings.

This approach is handy for anyone who wishes to programmatically extract information from an Org file (such as TODO states, tags, and content) and automatically format it as a neatly structured Org table. You can then export this table to various formats — like HTML, Markdown, or LaTeX — with built-in Org mode support.

A crucial aspect of maintaining organized and up-to-date notes is the use of Org Capture templates.

I have currently always hard-coded/set the current year in my org capture templates for use when exporting/constructing my web pages and as a tag for some filtering / web index generation. Of course the main disadvantage of this is that I have to remember to update the year each year, of which I often fail miserably. ☹️

I have enhanced selected-window-accent functionality with blending options to blend colourize the selected window (see below):

I am of course using org mode for organizing my tasks, notes and other paraphernalia.

In my previous post about creating simple functions to create a new directory and file in dired, I received an interesting comment suggesting another way to bypass the potential messiness of completion and pass through the literal text input.