Hidden Power Query Advanced Editor Shortcuts

Introduction
Still editing the same M expression three times, one line at a time? A few Power Query Advanced Editor shortcuts can make those small changes much easier. This guide shows you how to comment code, duplicate a transformation, place multiple cursors, and navigate a longer query. You’ll practise on a small text-cleaning example and learn an equally useful habit: checking which editor a shortcut actually belongs to.
Why This Matters
Imagine a monthly clinic export with inconsistent location names, extra spaces, and mixed-case status labels. You already know the transformation you want. The repetitive part is adapting it across several columns without dropping a quote, brace, or comma.
Keyboard editing helps with that authoring work. It doesn’t make a query refresh faster, fix an incorrect business rule, or replace checking the output. Treat the shortcuts as editing tools, then validate the resulting M code as carefully as you would code typed by hand.
Before You Start: Desktop and Online Are Different
The walkthrough targets Windows users of the traditional Advanced Editor in Excel or Power BI Desktop. Several less-visible combinations below are documented in practitioner demonstrations of that editor. They are not a Microsoft guarantee for every current build, keyboard layout, or newer editor experience. The walkthrough and reconstructed images were not executed in a live Power Query application for this article.
Power Query Online has its own official shortcut list. It documents Ctrl+Shift+M to open Advanced Editor and Ctrl+M to toggle Tab behaviour inside the multiline editor. Don’t assume the opening shortcut works in every Desktop version. Start from the ribbon’s Advanced Editor command if it doesn’t.
Create a blank practice query rather than changing a production report.
Keep a copy of the original M text before experimenting.
Click inside the code area before using editing shortcuts.
Use the Windows combinations shown here; don’t infer macOS equivalents.
A Focused Shortcut Cheat Sheet
Task | Windows combination | Where to use it |
Toggle line comments | Ctrl + / | Traditional Advanced Editor |
Toggle a block comment | Alt + Shift + A | Traditional Advanced Editor |
Indent / outdent selected lines | Tab / Shift + Tab | Traditional Advanced Editor |
Duplicate a line or selection | Shift + Alt + Down / Up | Traditional Advanced Editor |
Delete a whole line | Ctrl + Shift + K | Traditional Advanced Editor |
Place additional cursors | Alt + Click | Traditional Advanced Editor |
Jump to a line number | Ctrl + G | Traditional Advanced Editor |
Request function parameter hints | Ctrl + Shift + Space | Traditional Advanced Editor |
Open Advanced Editor | Ctrl + Shift + M | Power Query Online |
Toggle Tab behaviour | Ctrl + M | Power Query Online multiline editor |
The traditional-editor entries are supported by the walkthroughs linked at the end. Test them in your installed version. The same keys can perform different actions when focus is in the data preview, query pane, browser, or code area.
Step-by-Step Solution
Step 1: Start with a self-contained practice query
Create a blank query and open Advanced Editor. Paste the following Power Query M query into that window. It creates two synthetic rows, so you don’t need a workbook table, file path, gateway, or database connection.
let
Source = #table(
type table [Clinic = text, City = text, Status = text],
{
{" Rosenheim ", " rosenheim ", " active "},
{" Munich ", " munich ", " pending "}
}
),
Cleaned = Table.TransformColumns(
Source,
{
{"Clinic", each Text.Trim(_), type text}
}
)
in
CleanedThe initial transformation removes leading and trailing whitespace from Clinic only. City and Status deliberately remain unchanged. The underscore represents the current cell value passed to the transformation function. This gives you a clear starting point for comparing later edits.
Step 2: Add useful comments without changing the logic
Add a plain explanation above Source, then use Ctrl+/ on that line to turn it into a line comment. For a longer explanation, select the text and try Alt+Shift+A. M uses // for line comments and /* ... */ for block comments.

Comment the reason for the transformation, such as standardising labels before comparison. Avoid commenting out a step that later expressions still reference. Removing executable text can also leave a stray comma. If you disable a step temporarily, review its consumers and the expression after in.
Step 3: Duplicate the transformation pattern
Place the cursor on the Clinic transformation line and try Shift+Alt+Down. Adapt the duplicate for City, then repeat for Status. Afterward, keep commas after the first two entries and remove the comma after the last one.

You’re duplicating text, not creating an automatically connected transformation. Read each column name after the edit. Three syntactically valid copies of Clinic would not express your intended three-column cleanup.
Step 4: Try multiple cursors for a repeated insertion
Hold Alt and click immediately before Text.Trim on each of the three transformation lines. If your editor supports the demonstrated behaviour, typing inserts the same text at all three positions. Try adding Text.Upper( to wrap the existing expression.

Finish each wrapper so the expression reads Text.Upper(Text.Trim(_)). Inspect any automatically inserted parentheses rather than adding another closing bracket blindly. Return to a single cursor before continuing. If multiple cursors aren’t available in your build, make the same three changes individually.
This exercise uses uppercase deliberately so the change is obvious. In a real customer list, preserving a person’s preferred name casing may matter more than applying one rule everywhere.
Step 5: Make the code easier to navigate
Select the transformation entries and use Tab or Shift+Tab to adjust indentation. Try Ctrl+G to move to a specific line, and Ctrl+Shift+Space while entering a function call to request parameter hints. Suggestions depend on the editor and cursor context.
Use Ctrl+Shift+K only when you intend to remove a whole line. Afterwards, inspect neighbouring commas. Moving the cursor to a line is an editing action; it doesn’t select or evaluate the corresponding Applied Step.
Step 6: Validate the finished transformation
Use this complete Power Query M query as your comparison target in the same blank query. It trims the three text columns and then converts their values to uppercase. The explicit text types keep the intended output schema visible.
let
// Standardize text before comparing labels.
Source = #table(
type table [Clinic = text, City = text, Status = text],
{
{" Rosenheim ", " rosenheim ", " active "},
{" Munich ", " munich ", " pending "}
}
),
Cleaned = Table.TransformColumns(
Source,
{
{"Clinic", each Text.Upper(Text.Trim(_)), type text},
{"City", each Text.Upper(Text.Trim(_)), type text},
{"Status", each Text.Upper(Text.Trim(_)), type text}
}
)
in
CleanedCheck the editor’s syntax feedback, accept the edit, and inspect the data preview. A syntax check is only the first check: the transformation must also return the expected values. This example was reviewed against the function documentation; the table below is the expected result, not a captured Power Query execution.
Practical Example: Check the Output
Clinic | City | Status |
ROSENHEIM | ROSENHEIM | ACTIVE |
MUNICH | MUNICH | PENDING |
You should still have two rows and three text columns. Outer spaces disappear, and all six values become uppercase. Text.Trim doesn’t remove spaces inside a name, so a multiword label should retain its internal separation.
Before reusing this pattern on a real export, list the columns that actually need normalisation. Check their data types and decide how blanks, nulls, and unexpected values should be handled. The small example intentionally contains ordinary text only; it doesn’t establish a cleanup policy for every source.
Keep a representative before-and-after sample. Include a value that should change and one that should remain unchanged. That makes an accidental column edit easier to notice than simply checking that the preview opens.
A small acceptance check for the monthly export
Write down the intended change before you edit: trim and uppercase Clinic, City, and Status while preserving the row count. After applying the query, compare that statement with the preview. If a column is unexpectedly missing, stop and compare your code with the full version rather than adding another transformation to compensate.
For a recurring report, keep the original source column names in your notes. A later export might rename City to Town. The transformation list still names City, so the source schema has become part of the query’s contract. Decide whether that change should raise an error or be handled explicitly; silently skipping a required column can hide a reporting problem.
If you share the query with a colleague, record the application and editor experience you used. Share the complete M code alongside the shortcuts. Your colleague can reproduce the intended transformation even if a key combination behaves differently on their machine.
Bonus Tips and Common Mistakes
Keep keyboard-layout assumptions out of your documentation
On a German keyboard, the slash and bracket keys differ from a US layout. If a combination doesn’t trigger the expected command, check the editor’s available help and the active keyboard layout. Don’t replace the documented key with a guessed alternative and share it as a universal fix.
Distinguish a step name from a text value
Renaming a step in raw M text requires checking its references too. A label with spaces may use a quoted identifier such as #"Cleaned Text". By contrast, "Clinic" inside the transformation list is a text value identifying a column. Similar-looking quotation marks serve different purposes.
Don’t turn editing speed into a refresh claim
These changes make repeated authoring more convenient. Whether a production query folds to its source or refreshes efficiently is a separate question. Measure those behaviours with the relevant tools and a representative source; this two-row inline table provides no performance benchmark.
If a Shortcut Doesn’t Work
Confirm focus: click in the M code, not the data preview.
Confirm environment: Online, traditional Desktop, and newer experiences can differ.
Try a single harmless edit in the practice query before changing several lines.
If Tab moves focus instead of indenting, inspect tab-navigation behaviour. Online documents Ctrl+M for toggling it.
Use the ribbon or edit the text directly when a shortcut is unavailable.
Final Thoughts
Start with three habits: comment why the rule exists, duplicate a pattern carefully, and compare the output after editing. Add multiple cursors once those checks feel routine.
The useful result is a query you can understand and maintain next month. Pick one shortcut, practise it on the sample, and keep the ones that work reliably in your actual editor.




Comments