Repository navigation
Enable Ctrl+I for Italic formatting in Visual mode
#488
Description
Problem
As of v2.13.2, Ctrl+I is available for Italic formatting in Insert mode, but in Visual mode it still triggers the Go Forward command.
This feels inconsistent because Visual mode already includes a formatting menu with Italic as one of the available actions. Since Visual mode is specifically used for operating on selected text, it would be more useful for Ctrl+I to apply italic formatting than to perform navigation.
Proposed improvement
Bind Ctrl+I to Italic formatting in Visual mode, matching its behaviour in Insert mode.
The Go Forward command can remain assigned to Ctrl+I in Normal mode.
Why this would help
- Makes formatting shortcuts consistent between Insert and Visual modes.
- Aligns the shortcut with the formatting capabilities already available in Visual mode.
- Allows selected text to be italicised with a single shortcut.
- Avoids an unexpected navigation action while editing selected text.
Example
Current behaviour
- Insert mode:
Ctrl+I→ Italic - Visual mode: Select text →
Ctrl+I→ Go Forward - Normal mode:
Ctrl+I→ Go Forward
Proposed behaviour
- Insert mode:
Ctrl+I→ Italic - Visual mode: Select text →
Ctrl+I→ Italic - Normal mode:
Ctrl+I→ Go Forward
Operating System: Linux
Desktop: Hyprland
Activity
Fix(vim): Ctrl+I italicises a visual selection instead of jumping (#488)
adibhanna commentedon Jul 27, 2026
Fixed in
v2.19.0— thanks @ah-yah, and you read the cause correctly.Ctrl+Iin Vim visual mode now applies italic. Normal mode keeps Go Forward, exactly as you proposed.The collision only exists where
Modis Ctrl — Linux and Windows — because there Vim's forward jump and the italic shortcut are literally the same chord. A guard added in #373 gave that chord to the jumplist in every mode except insert, which is right for normal mode and wrong for visual: a selection is standing, every other format chord (Mod+B,Shift+Mod+S, and the rest) already applies to it, and the selection toolbar hovering over the selection offers Italic. So the one chord that navigated away was the odd one out.Two deliberate limits:
Ctrl+Ois untouched in every mode. It collides with no formatting shortcut, so there was no reason to take the jump-back away from it.Ctrl+Iwas never italic (Cmd+Iis), so nothing collides and the jumplist keeps the chord in all modes — including visual, whereCmd+Ialready italicised and still does. The decision now asks whether the chord is also a format shortcut rather than assuming it, which is what keeps this from costing Mac users their jumplist for a conflict they never had.Verified on your platform rather than a stand-in for it.
window.zenis a frozen context bridge, so the page can't be made to report a different OS; patching the built preload'splatformSyncto return"linux"for the run makesModresolve to Ctrl exactly as it does on Hyprland. With the app reportinglinux: normal-modeCtrl+Ileaves the note untouched, and visual-modeviwthenCtrl+IturnsAlpha bold omegaintoAlpha *bold* omega— where before the fix the same keystrokes changed nothing and moved me to another note.Two related things land in the same release, in case they're useful to you: pressing a format shortcut a second time now steps out of the span (#443), and
Alt+]/Alt+[hop the cursor across markers in any direction (#490).Feat(shortcuts): Ctrl+O opens a file on Windows and Linux too
Fix(keymaps): app shortcuts win over Vim's Ctrl chords, and the excep…