Manage Multiple Magik Workspaces with Emacs Projectile

Working with GE Smallworld Magik often means moving between several related environments: a customer application, a shared framework, a test database, and a local branch containing experimental methods. Emacs Projectile gives each of these codebases a clear identity, so file navigation, compilation, search, and project commands remain tied to the correct workspace.

This approach is useful for Magik developers who use Emacs as their main development environment, especially when Smallworld installations sit across separate directories or remote machines. With a few project markers and a sensible .dir-locals.el file, Projectile can make a collection of Magik repositories feel like one organised development system.

Approach	Best use	Main advantage	Limitation
One large Emacs workspace	Small personal projects	Minimal configuration	Easy to run commands in the wrong directory
Separate Projectile projects	Multiple Magik applications	Clear project boundaries	Requires consistent root markers
Projectile plus Emacs workspaces	Several projects open at once	Fast switching between contexts	Needs disciplined buffer naming
Projectile plus remote development	Magik code on servers or VMs	Keeps local Emacs workflow familiar	Remote paths and processes need care

Define A Reliable Magik Project Root

Projectile recognises a project by looking for root indicators such as a version-control directory, a .projectile file, or other configured markers. Git is the simplest option when a Magik application already lives in its own repository. If a Smallworld workspace is not version-controlled, placing an empty .projectile file in its top-level directory gives Projectile an explicit boundary.

A typical arrangement might separate application code, shared methods, configuration, and test data:

customer-mapping/
├── .projectile
├── .dir-locals.el
├── magik/
├── config/
├── tests/
└── docs/

The marker should sit at the directory from which the team normally opens Magik files and launches related commands. Putting it too high can combine unrelated customer systems; putting it too low can cause Projectile to treat individual method libraries as separate projects. A stable root makes projectile-find-file and projectile-grep much more predictable.

For teams in Sydney, Melbourne, or Perth supporting several Smallworld deployments, consistent folder names are valuable when repositories are cloned across laptops and jump hosts. A developer can use the same project-switching habits whether the workspace is under ~/src, an encrypted drive, or a mounted corporate share.

Switch Quickly Between Customer Workspaces

Enable Projectile with:

(projectile-mode +1)
(setq projectile-project-search-path
      '("~/src/" "~/smallworld/projects/"))

The search path tells Projectile where to discover projects. Use C-c p p, provided by the default Projectile keymap, to switch between known roots. The command displays project names and lets you narrow the list by typing a few characters. C-c p f then finds a file within the selected project without requiring a long path through the Smallworld installation.

Project names should distinguish customer, product, and environment where necessary. Names such as waternet-prod, waternet-dev, and roads-test are clearer than three directories called workspace. This matters when a consultant supports utilities in Queensland, transport projects in Victoria, or local-government systems in New South Wales and needs to avoid opening a production-side method by mistake.

Projectile also maintains a project-specific buffer list. C-c p b limits buffer selection to the current project, which is useful when Emacs contains buffers from several Magik sessions. A disciplined naming scheme for shell buffers, logs, and scratch notes can reinforce that separation.

Connect Projectile To Magik Commands

Projectile becomes more useful when its project commands understand the way a Magik application is built and tested. projectile-compile-project invokes the project’s configured compilation command, while projectile-test-project can be adapted for a project-specific test runner. The exact command depends on the Smallworld version, launch scripts, environment variables, and whether the workspace runs locally or through a remote session.

A project-local .dir-locals.el file can provide variables without placing customer-specific values in the global Emacs configuration:

((magik-mode
  . ((magik-project-root . "/opt/smallworld/customer-mapping/")
     (magik-start-command . "./bin/start-magik"))))

The variable names here depend on the Magik extension in use. Some packages expose commands for launching an image, connecting to a running session, evaluating a buffer, or sending a method definition to an inferior Magik process. The important principle is to associate those commands with the current project rather than relying on whichever process was started most recently.

A shell script can act as a stable bridge:

#!/bin/sh
set -eu
cd "$(dirname "$0")/.."
exec ./bin/run-tests "$@"

Projectile can call that script from the project root, which avoids embedding long Smallworld startup commands in Emacs. It also gives the team a documented place to handle licensing variables, image paths, database connections, and test database selection.

Keep Environment Configuration Local

Magik workspaces often depend on environment variables, startup files, image locations, and database connection details. These settings should be explicit enough to reproduce a development session, while secrets and customer credentials must remain outside Git. Emacs directory-local variables are useful for non-sensitive paths, feature flags, and command names; a private shell file or approved credential mechanism is better for passwords and tokens.

For example:

((nil
  . ((projectile-project-compilation-cmd . "./bin/build-magik")
     (projectile-project-run-cmd . "./bin/run-magik"))))

Before enabling directory-local variables, Emacs may ask whether a value is trusted. Review the file rather than automatically accepting every local setting, especially when opening a repository received from another party. This is particularly relevant for consultants who move between internal code, client repositories, and vendor-provided extensions.

Keep generated files out of project searches with a .projectile configuration:

-/logs
-/tmp
-/build
-/generated

The leading minus excludes matching paths from Projectile’s file list. This makes method navigation faster and prevents stale generated code from appearing beside the source that should be edited. It also reduces the risk of accidentally changing a copied file in a build directory.

If a team maintains field-facing dashboards alongside its Magik system, device-specific documentation should remain separate from the workspace instructions; Huawei app guidance belongs in a deployment or support note rather than in the project’s build procedure.

Search And Inspect Magik Code Efficiently

Projectile’s search commands are especially helpful in large Magik codebases, where a method may be defined in one library and invoked through several classes or mixins. C-c p s g runs a project-wide search with grep or a configured alternative, while projectile-grep can locate selectors, class names, schema references, and error messages across the workspace.

A useful routine is to search from the project root, then open the result in the correct Magik buffer. From there, Magik-aware Emacs extensions can provide method navigation, indentation, code folding, and evaluation. Projectile handles the project boundary; the Magik mode handles language structure. Keeping those responsibilities separate makes configuration easier to diagnose.

For larger repositories, configure a fast search tool such as ripgrep if it is approved by the team:

(setq projectile-generic-command
      "rg --files --hidden -g '!.git' -g '!build' -g '!logs'")
(setq projectile-grep-use-git-grep t)

The best setting depends on whether the directory is a Git repository and whether generated or binary files are present. Test the command from an ordinary shell before assigning it to Projectile. A search command that behaves differently inside Emacs can create confusing missing-file results.

Project-specific tags, cross-reference databases, or Magik method indexes can complement Projectile. Use Projectile to locate the relevant project and narrow the file set, then use language tooling to inspect inheritance, method ownership, and references. This is faster than treating every directory in a multi-customer development machine as one undifferentiated source tree.

Work With Remote And Parallel Sessions

Some Magik development environments run on a Linux server, virtual machine, or remote desktop rather than on the developer’s laptop. Projectile can still provide a consistent interface when files are accessed through TRAMP. A remote project can be opened with a path such as:

/ssh:developer@magik-host:/srv/smallworld/roads/

Once Emacs recognises the remote root, commands such as projectile-find-file and projectile-grep operate in that context. Remote compilation may require a TRAMP-compatible command and a shell environment that loads the same Smallworld setup used by the interactive session. Test these commands with a non-production workspace first.

Parallel sessions deserve clear names. A project may have a local editing buffer, a remote Magik process, a log buffer, and a database console open at the same time. Naming shell buffers with the customer and environment, such as *magik-waternet-dev*, makes projectile-switch-to-buffer safer than relying on a generic *shell* buffer.

Australian consulting teams often work across AEST, ACST, and AWST time zones, with handovers between Brisbane, Adelaide, and Perth. A project README should record the expected environment, startup script, test command, and any time-sensitive data refresh procedure. That documentation reduces mistakes when a developer inherits a workspace during an incident or after-hours support shift.

Build A Repeatable Daily Workflow

Start each work period by switching to the intended project with C-c p p, checking the current branch, and opening the relevant Magik method through C-c p f. Run the project’s normal compile or startup command from Projectile rather than from an unrelated shell buffer. When debugging, keep the inferior Magik process associated with the same customer and environment as the source buffers.

At the end of a task, use project-scoped buffer commands to close or bury the active workspace, then switch to the next project. This small habit prevents stale logs and old method definitions from obscuring the current context. It also makes screen-casts and technical support sessions easier to follow because the visible Emacs state reflects one workspace at a time.

A practical baseline is to standardise three files in every Magik project: .projectile for the root and exclusions, .dir-locals.el for safe local settings, and a README for startup, testing, debugging, and deployment notes. Add a project-specific shell script when the native Smallworld command is too long or environment-dependent.

Adopt that baseline across the repositories your team maintains, then bind the Magik evaluation and debugging commands to the same Projectile-aware workflow. With clear roots, predictable commands, and deliberate session naming, Emacs becomes a dependable control centre for multiple Magik workspaces rather than a collection of loosely connected buffers.