Editing Magik grep results in Emacs with wgrep

Searching through a sprawling Magik codebase often feels like panning for gold along the Murray River — you know the nuggets are in there somewhere, but sifting through thousands of lines of Smallworld session code can be tedious. Developers working with GE Smallworld regularly need to rename a method, fix a typo across a collection of files, or audit every call to a particular proc. Doing that one match at a time wastes hours that could be spent on the actual logic of the change. The standard workflow of running grep, jotting down a list, and then hunting each match by hand has long outlived its usefulness.

Enter wgrep, an Emacs extension that turns the read-only buffer produced by grep, ag, or ripgrep into an interactive editing surface. Once activated, every match becomes a regular Emacs buffer line that you can modify, delete, or replace just like any other file. The original files are not touched until you explicitly commit the changes, which gives you a safe staging area for the kind of bulk edits that used to require sed scripts or custom Magik refactoring tools. For Smallworld developers juggling multiple GIS databases and session files, this kind of in-place editing is genuinely transformative.

The Magik language has its own quirks — case-insensitive method names, the underscore-based method dispatch, the way procedures and iterators are woven across many source files. A standard grep workflow treats each match as a string, but wgrep understands the buffer context, so you can use the same Emacs editing muscle memory that you apply to actual Magik files. That means your search buffer can take advantage of syntax highlighting, parentheses matching, and even Magik-specific modes if you load them in the result buffer.

This walk-through assumes you are running a recent stable Emacs — 27.2 or 29.x are common in Australian consulting shops — and that you already use a project search tool such as projectile-grep, helm-grep, or consult-grep. The techniques apply whether you are sitting in a Brisbane office debugging a water network dataset or reviewing code from a coworking space in Hobart, because Emacs travels well across time zones and networks.

Installing wgrep in your Emacs configuration

wgrep is available on MELPA, the package archive that most Australian Magik developers use because it mirrors quickly to local university and ISP networks. The simplest install path is to add (package-install 'wgrep) inside your use-package block, or to call M-x package-install RET wgrep RET from inside Emacs. If you manage your configuration with a straight.el or a manual init.el, drop the package in your load-path and (require 'wgrep).

For developers who prefer a fixed, auditable setup — common in regulated utilities where every change is reviewed by a change advisory board based in Melbourne or Sydney — pinning wgrep to a specific commit through quelpa or a local git clone is the safer route. That way your search-and-replace behaviour stays identical across the team, even if a new wgrep release changes a default keybinding. The package is small, has no Magik-specific dependencies, and loads in well under a second on a modern laptop.

After installation, wgrep will not announce itself; you have to trigger it. Most users bind it to a convenient key, such as C-c w or C-c e, so the command is close to other editing bindings. If you already use general.el or which-key, you can group the binding under a prefix like C-c g to keep it near your grep launching keys. Adding a discoverable binding is more useful than relying on M-x wgrep-change-to-wgrep-mode each time, especially when you are racing through a refactor before a morning standup in Adelaide.

Activating wgrep on a Magik grep buffer

When you run a project-wide search, the result buffer opens in grep mode. By default it is read-only, so any attempt to edit a line raises an error. Calling M-x wgrep-change-to-wgrep-mode flips the buffer into an editable state. The mode line updates to show Wgrep in lighter text, and the keys you normally use for killing, yanking, and query-replace start working against the displayed lines rather than the underlying file path column.

A practical tip for Magik users: keep your grep command line consistent. Searching for def_method\|proc\|iter with the -i flag works well because Magik keywords are case-insensitive, and the resulting buffer will have enough context for you to spot whether a def_method is actually inside a method or merely a comment. If you launch your searches through consult, the resulting *grep* buffer is recognised by wgrep automatically, so no extra configuration is required. Users of the classic grep build-in command will need to ensure grep-highlight-matches is loaded so that the match text stands out while you edit.

It is worth practising the activation in a throwaway project first. Open a few Magik files, run a search for a unique string such as your own copyright comment, then flip into wgrep mode and try a small change. Once you are comfortable with the cycle of edit, commit, and revert, you can take the same workflow into a live Smallworld session repository without anxiety. Many Sydney-based Smallworld integrators keep a sandbox copy of a database export for exactly this kind of experimentation.

Editing matches interactively

The real power of wgrep shows up when you start treating the grep buffer like a Magik file. You can narrow to a subset of lines with keep-lines or flush-lines, which is handy when you only want to modify a particular class of matches. For instance, after searching for write_string, you might flush all matches that occur inside condition blocks because you only want to edit the ones in the main flow. Standard Emacs keys work: M-% for query-replace, C-M-% for regex replacement, and C-x u to undo before things get out of hand.

Regex replacement is where Magik refactors become manageable. Suppose you are migrating from an old Smallworld collection API to a new one, and every call looks like a_collection.an_element() but should become a_collection.element_at(). A single wgrep session can produce a buffer where each line is reviewed, edited, and saved. Because the buffer shows the file path on the left, you can use C-c C-p to jump to the next file group, which makes it easy to commit changes one source file at a time and run a quick syntax check between groups.

If a match spans multiple lines, wgrep handles it as a single logical record, so you will not accidentally edit only half of a multi-line method call. That is a subtle but important guarantee when you are working with Magik's block syntax, where an iter loop and its corresponding _endblock keyword can stretch across many lines. For teams spread across time zones from Perth to Cairns, this also makes the workflow easier to hand over — a colleague in another state can pick up the buffer, see exactly what was changed, and commit only after a quick review.

Saving changes and reverting safely

Once you are happy with the edits, M-x wgrep-finish-edit writes the changes back to the source files and marks the buffer as finished. The original files are updated in place, and Emacs reverts them so the on-disk version matches what you see. If something goes wrong, M-x wgrep-revert throws away your in-buffer edits and reverts to the state captured when wgrep mode was activated. This two-stage commit is the safety net that makes bulk editing feel low-risk.

A useful habit is to run the same search again after committing, just to confirm the buffer is empty or only contains matches you intentionally left untouched. This double-check is a small price to pay for the confidence that a hundred-line refactor did not introduce a stray typo. In Australian Magik teams where change windows are often scheduled for early-morning AEST slots to minimise disruption to operational GIS systems, that quick verification can save a roll-back during business hours.

For multi-file refactors, you may want to commit one file at a time using C-x C-s against an individual file, but wgrep is built around the idea of editing the buffer as a whole. If you only want a subset of the changes, mark the lines you want to keep with C-SPC and use M-x wgrep-mark-region before finishing the edit. The package will only write back the marked lines, which is a tidy way to split a large refactor into a series of smaller, reviewable commits.

Advanced patterns for Magik codebases

When your search spans dozens of repositories — common for consultancies that maintain one Smallworld instance per utility client — performance matters. wgrep is not a bottleneck, but the underlying grep tool is. Using ripgrep (rg) instead of GNU grep can cut search times from minutes to seconds, which keeps your editing context alive. The *grep* buffer produced by rg through consult is recognised by wgrep without extra plumbing, so you can keep your existing search bindings.

Another advanced pattern is to combine wgrep with Magik's own symbol-at-point facilities. Running a search for the current method name — for example, C-x C-e after typing (concat "def_method\\." method_name) in the minibuffer — gives you a buffer of every definition in the codebase, and you can then rename all of them in one pass. This is a much lighter-weight approach than building a full Magik language server, and it works with the version of Emacs already running on every consultant's laptop.

If your team works in a regulated environment, pair wgrep with a version control hook so that every commit triggered by a wgrep save goes through the same pre-commit linting as a manual edit. Some Melbourne-based teams use a wrapper that runs a quick Magik syntax check on changed files before allowing the commit, which adds maybe two seconds of latency in exchange for catching a missing _endmethod keyword that would otherwise crash a live Smallworld session. For project tracking and accountability, many Australian Magik developers explore additional tooling that complements this kind of automated verification.

Integrating wgrep into a daily Magik workflow

The most sustainable way to adopt wgrep is to fold it into the search commands you already use. If you launch project searches with projectile, add an :after-advice that calls wgrep-setup so the buffer is ready to edit the moment it appears. If you use Magit's grep interface, wgrep slots in the same way. The goal is to remove the friction of typing M-x wgrep-change-to-wgrep-mode so the editing step feels like a natural extension of the search step.

For Smallworld developers, that integration pays off in the kind of work that often gets pushed to a Friday afternoon: bulk comment cleanups, copyright header updates, or migrating deprecated proc calls. Tasks that used to take half a day can be finished in an hour, with enough time left to grab a flat white before the lifts turn off in your Sydney office tower. The change feels small at first, but the cumulative time savings across a quarter are noticeable in any honest time-tracking sheet.

If you want to go further, explore the wgrep-el extensions on the maintainer's GitHub. There are extras for narrowing the buffer to specific file types, sorting matches by file, and even exporting the diff before commit so you can share it with a colleague in another office for a quick sanity check. Combined with Magik's own development cycle, wgrep becomes a quiet but powerful part of the toolkit — a tool that rewards repetition and turns a search buffer into a proper editing surface.

If you maintain a Magik codebase and want to see wgrep in action on your own repositories, request a screen-cast walk-through from HydePark Consulting and bring along a recent grep buffer from one of your projects — the team will show you how to turn a messy search result into a clean, reviewable commit before your next standup.