Customizing Magik Indentation to Match Your Project Style

Consistent indentation makes Magik code easier to scan, review, and maintain. In a large Smallworld application, visual structure often communicates the relationship between methods, conditional branches, loops, procedures, and error-handling blocks before a developer has read every statement.

Emacs can provide a strong starting point through the Magik major mode, but the default layout may not match the conventions used by your team. A project might use two spaces, four spaces, or tabs for indentation. It may also have established preferences for continuation lines, method declarations, comments, and nested collection operations.

The most reliable approach is to separate the language rules from the project’s presentation rules. Magik mode should understand where a block starts and ends, while your project configuration should define the width, whitespace behaviour, and any local exceptions.

This matters particularly when developers work across Australian offices and remote sites. A team split between Melbourne, Sydney, Brisbane, and Perth may share code through Git while using different Emacs configurations. A small, version-controlled style setup prevents formatting differences from becoming a recurring source of review noise.

Identify How Magik Mode Indents Code

Start by checking which Magik major mode your buffer is using. Open a Magik source file and run M-x describe-mode, or press C-h m. The mode name and documentation normally reveal the indentation command, relevant customisation group, and variables controlling the layout.

Emacs also makes it easy to inspect active settings. C-h v followed by a variable name displays its current value, documentation, and location. If you are unsure which variable controls indentation, use M-x customize-group and search for magik, or inspect the mode’s source with M-x find-function when the command is available.

A useful diagnostic sequence is:

C-h m
C-h v magik-indent-level
C-h v magik-indent-offset
C-h f indent-for-tab-command

The exact variable names can differ between Magik mode implementations and versions. Do not assume that a setting found in an old team configuration still exists in your installation. Confirm the variable in the running Emacs instance before adding it to your init file.

Test the mode on a small sample containing nested Magik constructs. Place the cursor on each line and press TAB. This shows whether the mode is recognising _if and _endif, loops, procedures, protection blocks, and method boundaries correctly. If a line does not move as expected, the issue may be syntax recognition rather than the chosen indentation width.

Choose Spaces, Tabs, and Indentation Width

Most Magik teams benefit from spaces for indentation, especially when source files are reviewed in web-based Git tools. Set the policy locally so that it applies to Magik buffers without changing unrelated languages:

(defun my-magik-style ()
  (setq-local indent-tabs-mode nil)
  (setq-local tab-width 2)
  (setq-local standard-indent 2))

(add-hook 'magik-mode-hook #'my-magik-style)

indent-tabs-mode controls whether Emacs inserts tabs when indenting. tab-width controls how a tab is displayed, while standard-indent is used by many major modes as a general indentation preference. A Magik mode may use its own offset variable as well, so inspect its documentation and set that variable when appropriate.

For a four-space project, replace both widths with 4. The important point is to choose one convention and apply it consistently. A two-space style is compact and can help when Magik methods contain deeply nested logic. Four spaces make nesting more visually prominent and may be preferred by teams maintaining large legacy applications.

Use file-local settings when a repository needs a different style from your personal defaults:

;;; -*- mode: magik; indent-tabs-mode: nil; tab-width: 4; -*-

A .dir-locals.el file is usually better for a complete project because it keeps the policy outside individual source files:

((magik-mode
  (indent-tabs-mode . nil)
  (tab-width . 2)
  (magik-indent-offset . 2)))

Only include magik-indent-offset if your installed mode defines it. An invalid or unsupported variable can generate confusing warnings, particularly when the project is opened by consultants or new developers using a different package version.

Match Continuation Lines and Nested Blocks

Indentation width is only part of a project style. Long method calls, collection expressions, predicates, and chained operations need a predictable continuation rule. Some teams align a continuation beneath the opening expression; others indent it one additional level. Either approach can work if the result remains stable when Emacs reformats the line.

For example, a compact style might look like this:

_method feature_manager.update_record(record, attributes)
  _if record.valid?
    record.apply_attributes(attributes)
  _endif
_endmethod

A project using wider visual separation may choose four spaces:

_method feature_manager.update_record(record, attributes)
    _if record.valid?
        record.apply_attributes(attributes)
    _endif
_endmethod

Magik mode normally handles recognised block delimiters, but it may not know how your project represents every continuation pattern. Avoid forcing alignment through repeated spaces by hand. When a mode does not provide the exact layout you want, use a local wrapper function or a project convention that is easy to apply manually.

Keep comments attached to the code they explain. A comment inside a method should generally follow the current block indentation rather than returning to column zero. Header comments that document a class, subsystem, or public method can use a separate left-aligned convention. The distinction helps readers tell documentation apart from an inline implementation note.

Account for Legacy Syntax and Local Extensions

Mature Smallworld systems often contain older Magik idioms, application framework conventions, and macros created by an individual organisation. These constructs may look like standard Magik to a developer but remain invisible to a generic indentation engine. When Emacs indents them incorrectly, first determine whether the parser recognises the syntax.

Check the fontification as well as indentation. If a project-specific keyword is not highlighted as a declaration, block opener, or terminator, indentation support may require a syntax extension. Avoid solving the problem by adding arbitrary indentation offsets to every line. That can make ordinary methods look correct while producing poor results in nested code.

A small mode hook can provide project-specific behaviour, but changes should be conservative:

(defun my-company-magik-style ()
  (setq-local indent-tabs-mode nil)
  (setq-local tab-width 2)
  ;; Add project-specific settings only after verifying
  ;; that the installed Magik mode supports them.
  )

(add-hook 'magik-mode-hook #'my-company-magik-style)

If the project has custom block keywords, document them alongside the Emacs configuration. Include a short example showing the intended indentation and identify whether the keyword is handled by the mode, a company extension, or a manual convention. This is valuable for Australian teams where a Smallworld installation may be supported by a local council, utility provider, transport organisation, or consulting partner with its own application layer.

Keep Formatting Consistent Across Developers

Personal .emacs files are a poor place for rules that affect shared source code. Put agreed indentation settings in the repository, a team Emacs package, or a documented onboarding configuration. Developers can still override the style temporarily, but the default should come from the project.

A repository-level .dir-locals.el file makes the intended behaviour visible:

((magik-mode
  (indent-tabs-mode . nil)
  (tab-width . 2)
  (fill-column . 100)))

fill-column does not directly indent Magik, but it communicates the preferred line length for comments and long expressions. Keep it aligned with the project’s review and integration practices. A line length that works on a laptop may be less practical in terminals used during field support or remote sessions.

Pair editor settings with repository checks. A pre-commit hook or continuous integration job can detect tabs, trailing whitespace, and accidental line-ending changes. Do not make the check so aggressive that it rewrites entire legacy files whenever a developer touches one method. A focused policy produces cleaner diffs and is easier to adopt.

Line endings deserve attention when code moves between Windows-based Smallworld environments and Unix-like development systems. Configure Git deliberately and ensure Emacs displays the file coding and end-of-line style correctly. This prevents an indentation change from appearing as a complete-file modification during review.

Review and Roll Out the Style

Before adopting a new layout, test it against representative Magik files rather than a single short method. Include nested conditionals, loops, procedures, collection traversals, comments, long argument lists, and the project’s most common framework patterns. A configuration that works in a simple example may be uncomfortable in a heavily nested network or land-information workflow.

Ask several developers to open the same files with the proposed settings. This matters for distributed teams working across Australia’s time zones, including Perth-based operations and eastern-state development groups. Shared settings reduce the chance that a developer formats code one way locally while a reviewer sees a different layout through a web interface.

Use a gradual rollout for an established codebase. Apply the style to new and modified sections first, then reformat older files only when there is a clear maintenance reason. Record the policy in the project’s contributor documentation, including the indentation width, tab policy, line-ending expectations, and the command used to reindent a buffer.

Project profile	Recommended indentation	Emacs approach	Main consideration
Compact application code	2 spaces	Local Magik hook and .dir-locals.el	Keeps nested methods narrow
Large legacy system	4 spaces	Match existing source before changing defaults	Avoids noisy whole-file diffs
Mixed editor team	Spaces only	Set indent-tabs-mode to nil	Gives consistent display in Git and terminals
Remote support environment	2 or 4 spaces, documented	Store settings in the repository	Reduces workstation differences
Custom framework code	Existing project convention	Verify syntax support before extending mode	Prevents incorrect block indentation

A style file should be treated as part of the application’s development tooling, not as an individual preference. When the Emacs configuration, repository rules, and written standards agree, developers can focus on Magik behaviour rather than repeatedly repairing whitespace.

Adopt the chosen settings in your Magik repository, add a tested .dir-locals.el file, and share the relevant Emacs commands with the team. Magik Emacs users can also use HydePark Consulting’s extensions, tutorials, and consulting resources to improve method navigation, debugging, code inspection, and day-to-day Smallworld development.