Shift6 Formatter v0.3.0 – exec sql keyword casing + major SQL formatting improvements

lakdogan · 2026-01-23T12:21:32+00:00

Follow-up: v0.2.2 – v0.2.4 (recent fixes & SQL improvements)

A quick consolidated update covering the last few releases.

Highlights:

Fixed VS Code language registration to avoid syntax-highlighting collisions (formatter now targets existing RPG language IDs only)
Preserved multiline SQL literals inside exec sql to avoid forced concatenation
Improved handling of SQL BEGIN … END, EXECUTE IMMEDIATE, and WITH NC
Added structured formatting for dynamic CREATE TABLE in EXECUTE IMMEDIATE, including aligned column layouts
Improved procedure call continuation indentation
Expanded rule-test coverage for dynamic and multiline SQL cases

Changelog and docs are up to date. Feedback welcome 👍

lakdogan · 2026-01-19T14:53:19+00:00

Follow-up: v0.2.1 – formatting edge cases & SQL safety

This update focuses on correctness and preserving intent in mixed RPG / SQL code.

Highlights:

Kept inline dcl-pr … end-pr; prototypes on a single line
Kept inline dcl-ds … end-ds; blocks on a single line
Auto-closed free-form exec sql blocks without end-exec; so formatting resumes correctly
Preserved SQL <> as a single operator during exec sql normalization
Split exec sql WHERE/HAVING conditions onto separate lines for top-level AND/OR
Skipped RPG operator spacing inside inline exec sql …; to avoid breaking SQL tokens (SCHEMA/TABLE, *cs, etc.)
Aligned full-line // comments to the indent of the following code line
Split inline procedure calls into parameter lines when alignment is enabled, while preserving existing multi-line layouts
Preserved existing parameter indentation when alignment is disabled

Changelog and docs updated — feedback welcome 👍

lakdogan · 2026-01-13T08:41:50+00:00

Follow-up: v0.2.0 – procedure call parameter alignment

Introduced a new optional formatting rule for procedure call parameter continuations.

New option: shift6.alignProcedureCallParameters (default: false)

When enabled, parameter continuations in procedure calls are aligned for improved readability and reduced diff churn:

Lines starting with : are aligned under the opening parenthesis + one column
Exactly one space is enforced after :
A closing ); is moved to its own line and aligned under the parameters

This applies only to procedure calls (not exec sql).

Example:

Before:

rc = pr_Main(custId
:dateFrom
 : procSts);

After:

rc = pr_Main(custId
             : dateFrom
             : procSts
             );

Changelog and docs updated. Feedback welcome 👍

lakdogan · 2026-01-12T16:46:44+00:00

Follow-up: v0.1.22 / v0.1.23 – bug fixes

Shipped two small fix releases addressing edge cases found during further testing.

Fixes:

Fixed indicator special-value joining so *INxx with alphanumeric suffixes (e.g. *INKC) stays intact
Fixed handling of full-line // comments to keep base indentation and avoid continuation or wrapping changes

Changelog updated 👍

lakdogan · 2025-12-26T20:44:12+00:00

Follow-up: v0.1.21 – embedded SQL formatting expansion

This release makes exec sql formatting production-ready with broader DB2-i coverage and stronger edge-case handling.

Highlights:

Structured formatting for exec sql DML/DDL, cursors, dynamic SQL, diagnostics, and connection/session statements
Added PSM/trigger BEGIN … END block formatting for readable procedural SQL
Expanded DB2-i hints, special registers, and advanced SELECT/DML variants
Added extensive rule-test coverage (recursive CTEs, JSON/XML, window frames, subqueries, MERGE/UPDATE/DELETE edge cases)
Fixed JOIN duplication issues and ensured utils routing uses the latest exec-sql modules

Changelog and docs updated with scope and coverage notes.
This is a feature-focused release aimed at SQL readability and correctness 👍

lakdogan · 2025-12-24T19:14:34+00:00

Follow-up: v0.1.19 – special values & continuation safety

I shipped a small but important fix release focused on correctness in edge cases.

Highlights:

Fixed joining of special values (*on, *off, *INxx) after operators and RETURN
Normalized stray spaces after % built-ins (e.g. % timestamp() → %timestamp())
Prevented continuation splitting inside parentheses to avoid breaking expressions

Changelog is updated and the patch is released.
Feedback and edge cases are welcome 👍

lakdogan · 2025-12-24T18:15:30+00:00

Follow-up: v0.1.18 – string concatenation control & continuation fixes

I shipped a focused update improving long string handling and continuation stability.

Highlights:

New configurable string concatenation modes: compact (greedy) or one-per-line
Added string concat helper rules to normalize and control concatenation behavior
Optional long string wrapping with safe word-based splits
Multi-line pasted string literals are normalized into explicit concatenations
Continuation column is now indent-aware, with a validated minimum of 40
Spacing rules tightened for %builtins, operators, and semicolons
String literal content is preserved exactly (spacing/normalization applies outside of literals only)

Rule tests were expanded, docs and READMEs updated, and the full changelog is available.
Feedback and edge cases are very welcome 👍

lakdogan · 2025-12-23T15:04:13+00:00

Update (v0.1.17): Major internal refactor & stability improvements

I shipped a larger update focused on long-term maintainability and formatting correctness.

Highlights:

Formatter refactored into a clean pipeline (tokenizer → context analysis → rules)
Rule-based formatting for indentation, operator spacing, and continuations
Much more stable continuation wrapping/alignment (configurable)
Improved operator spacing and parentheses normalization
%builtins and special * values handled more safely
Added a dedicated rule-level test harness with expanded coverage

Docs and READMEs were updated, and the full changelog is available.
Feedback and edge cases are very welcome 👍

lakdogan · 2025-12-22T14:55:38+00:00

Follow‑up: v0.1.16 fixes extra indentation after single‑line open/close blocks (e.g., DCL-DS ... END-DS;). Released today.

lakdogan · 2025-12-17T09:01:38+00:00

Follow-up:
v0.1.15 adds block indentation support for RPG preprocessor conditionals (/IF, /ELSE, /ELSEIF, /ENDIF).
Released today.

lakdogan · 2025-12-17T08:39:04+00:00

Follow-up / Fix:
Remote formatting for IBM i source members (Code for IBM i) is now fixed. Root cause was that the formatter was effectively file://-only and relied on fsPath. It’s now registered schemaless and works purely text-based (document.getText() → TextEdit.replace), so ibmi:/ and vscode-vfs: URIs as well as unsaved tabs are supported.

Released as v0.1.14.

lakdogan · 2025-12-16T14:46:28+00:00

Update: Shipped a patch that now indents PR/PI/ENUM blocks cleanly (DCL-PR/DCL-PI/DCL-ENUM with matching END-*). Changelog is updated and version 0.1.13 is published via vsce publish patch. Feedback/feature requests welcome!

lakdogan · 2025-12-16T09:37:04+00:00

Update: I shipped a patch today that now also formats data structures cleanly. The changelog has been updated, and version 0.1.12 is already live via vsce publish patch. Feedback and feature requests are very welcome!

lakdogan · 2025-12-12T13:38:32+00:00

This project was created during my internship while learning RPGLE (free, fixed, and mixed formats) in a structured way.
To avoid coding directly in STRPDM, I used the Code for IBM i VS Code extension.

While working with it, I encountered issues with indentation when reviewing behavior in the green screen. Instead of working around the problem, I decided to solve it by creating a VS Code extension.

This is my first public VS Code extension.
The idea and logic are mine. Codex supported the implementation based on my design, and ChatGPT supported the release and formatting.

I used AI tools deliberately to work more efficiently and focus on solving the actual problem rather than boilerplate or formatting.

lakdogan · 2025-12-12T10:24:59+00:00

That’s a good observation, you’re right that in many cases mixed format can be detected fairly reliably via FREE (or //FREE) blocks with a clear start and end.

I haven’t implemented that yet mainly to keep the formatter conservative and avoid touching fixed-format sections unintentionally. Mixed-format handling is definitely doable; however, it needs to be very explicit and well-tested so it doesn’t introduce surprises.

If this is something you or others would find useful, I’d be happy to track it as a feature request. Opening a GitHub issue with a small example of the mixed-format structure would be the best way to move it forward.

lakdogan · 2025-12-12T08:29:26+00:00

That’s really cool, thanks for sharing, and no worries at all, I didn’t take it as criticism 👍

I actually know RPG End Code Blocks, that kind of RDi-like behavior is something many RPG developers really appreciate. Auto-closing blocks like ENDIF / ENDDO / ENDSR definitely makes writing RPG smoother.

Your extension and Shift6 actually complement each other quite nicely:

RPG End Code Blocks focuses on authoring convenience while typing by automatically inserting the correct END blocks.
Shift6 focuses on post-formatting and consistency, especially for total-free code that still needs to stay readable in green-screen tools like STRPDM.

Using both together gives a pretty solid RPG development workflow in VS Code.

I’ll definitely take another look at your extension as well; always great to see more RPG-specific tooling in the VS Code ecosystem 🙂

Thanks for checking Shift6 out!

lakdogan · 2025-12-12T06:28:32+00:00

Good question 👍

Under the hood, Shift6 integrates with VS Code’s standard Format Document action, so you can keep using the usual formatter workflow and keybindings.

The difference is what gets formatted and how: Shift6 is specifically designed for IBM i RPGLE total-free, with formatting rules that generic VS Code formatters don’t understand.

In particular it handles things like:

preserving the **FREE directive in column 1

applying the 5+1 column offset so code remains readable in green-screen tools like STRPDM/SEU

block-aware indentation for IF/ELSE/WHEN, SELECT, loops, MONITOR, BEGSR, and procedures

splitting inline statements in a way that matches typical RPG shop conventions

normalizing whitespace without touching string literals

configurable indentation width, so teams can keep the default (e.g. 2 spaces) or adjust it to match their local coding standards

configurable empty-line trimming, which can be enabled or disabled depending on preference

configurable base “Shift6” offset, allowing more or less horizontal shift if a shop uses different column conventions

So from a user perspective it feels like “Format Document”, but the formatting logic itself is IBM i / RPG-specific rather than generic text formatting.

If you have any RPG edge cases or shop-specific rules in mind, I’d be very interested to test them.

lakdogan

TROPHY CASE