A dockable 'Sam' tool view runs the plan9 sam command language against the
active document, or project-wide via X/Y. Each Run is one undo step.
Engine (src/sam/, pure, 27 unit tests, no Kate dep):
- SamEngine::run(program,text,dotStart,dotEnd) -> edits (original-offset,
non-overlapping, sorted), dot, output, applied text. Addresses computed
against the original snapshot per sam semantics.
- Recursive-descent parser + evaluator mirroring plan9port src/cmd/sam
(cmd.c table, address.c lineaddr/charaddr, xec.c s_cmd/looper).
- Language: #n n 0 $ . ' /re/ ?re? and compound + - , ; ; commands
a c i d, s (sN, g, &, \1..\9), p =, m t, k, loops x y g v (nestable),
{ } groups, shell < > | ! via sh -c.
- peelFileLoop(): recognises a leading X/Y file loop (sam allows one per
command) for the Kate layer to drive.
Kate layer:
- SamPanel (src/plugin/sampanel): program editor + Run + output log.
- OllieView creates the tool view (MainWindow::createToolView) and owns
runSamProgram/applySamToDocument/runSamFileLoop. Single-doc edits apply
inside one Document::EditingTransaction (atomic undo). X/Y enumerates the
project index (ProjectIndexer::cachedFiles), opens each matching file, and
applies the inner program; undo is per-file (no global multi-file undo).
Regexes use QRegularExpression (PCRE), not plan9 regexp(7); documented. Out of
scope: b B n D menu, e r w f file I/O, "re" file-addressing, sam u (Kate undo).
17/17 ctest green.
Native C++ 9P2000 client over QLocalSocket (no libplumb/lib9pclient
link) talking to a running plan9port plumber:
- ninep: Tversion/Tattach/Twalk/Topen/Tread/Twrite/Tclunk, LE wire,
msize negotiated from 8192; cancellable split read (beginRead +
recvReadReply) so the edit-port reader thread honours a stop flag
without a second outstanding Tread or any cross-thread socket touch.
- plumbmsg: PlumbMsg pack/unpack with libplumb attribute quoting;
unit-tested against golden bytes captured from a live plumber.
- plumbresolve: plan9 addr (N / N:C / N.C, 1-based) -> 0-based cursor.
- plumber: send() via the send port; PlumbReader QThread on the edit
port emits edit(file,addr,wdir) via a queued signal. Namespace socket
is $NAMESPACE/plumb or /tmp/ns.$USER.$DISPLAY/plumb (plan9 getns).
Plugin: F2 (ollie_plumb) plumbs selection/wordAt(cursor) through the
send port, falling back to internal URL/file resolution; incoming edit
messages open via openUrl + activateView + setCursorPosition.
Tests: test_plumbmsg + test_plumbresolve headless; test_plumb_live does
a real send->rules->edit round-trip against a running plumber and
skips+passes when none is reachable. 16/16 ctest green; live 4/4.
QCursor::setPos is a no-op on Wayland, so cursor-follows-focus did
nothing there. Add WaylandCursorWarp (src/plugin/waylandcursorwarp.{h,
cpp}): on Wayland, lock the pointer to the top-level window's wl_surface,
set_cursor_position_hint to the target pane centre (surface-local), commit,
then release — the compositor warps to the hint on unlock (the mechanism
plan9port/acme use). Panes are children of one window = one surface, so
it is a warp within that surface. Handles come from QWaylandApplication +
QPlatformNativeInterface 'surface'. X11 keeps QCursor::setPos.
Build: pointer-constraints client glue generated via ECM and compiled as
a C static lib (kcoreaddons_add_plugin silently drops .c sources); enable
C language in project(); link Qt6::GuiPrivate + wayland-client. All
guarded + a stub when the Wayland bits are absent. 13 ctest suites pass.
When a radial slice fires a go_*_split_view action (Focus Left/Right/Up/
Down/Next/Prev), warp the OS pointer onto the center of the newly active
view so the mouse follows the keyboard focus. Deferred via a 0ms timer so
Kate finishes activating the target view first. Scoped to the six pane-
focus actions only — other radial activations and ordinary view changes
(clicks, file opens) do not move the pointer.
All three palettes now span the window width. positionPalette drops its
fullWidth parameter (the centered path had no remaining callers) and
always full-widths.
Add OllieView::positionPalette(palette, fullWidth) and route all three
palettes through it. The Go-to-File and Go-to-Symbol switchers now span
the window width (minus a 12px margin) — long project-relative paths and
scope-qualified symbol labels fit without truncation. The M-x command
palette keeps its compact centered width. Replaces three duplicated
center-positioning blocks.
Add ProjectIndexer (project_lib, QtConcurrent + QFutureWatcher, 6 tests):
runs listFiles/listSymbols on the thread pool, delivers results on the UI
thread via filesReady/symbolsReady, caches per project root, and drops
stale results via a per-root generation counter.
Switchers now open the palette immediately — cache hit is instant, miss
shows a transient 'Indexing…' placeholder — and repopulate when the
background job finishes. The ~0.5-1s ctags stall on Alt+G no longer
blocks the UI thread. Cache invalidated on KateProjectBridge::
projectChanged. Register QList<Symbol> metatype; link Qt6::Concurrent.
Item building factored into buildFileItems/buildSymbolItems (shared by
the cache and async paths).
Kate's project plugin already opens folders and shows a file tree, and we
now build on it via KateProjectBridge, so the parallel Ollie-side model
was redundant. Remove the Alt+O 'Open Folder as Project' action, the
sticky m_projectRoot + its $XDG_CONFIG_HOME/olliepalette/project
persistence (load/save), 'Close Project', and the ollie:project:* palette
entries/handlers. currentProjectRoot() is now two-tier: bridge baseDir
-> VCS discovery. Frees Alt+O. 12 ctest suites still pass.
Read kateprojectplugin's view through the meta-object system (no link
dependency): projectBaseDir/projectName/projectFiles properties plus
projectMapChanged/projectFileNameChanged/pluginProjectAdded|Removed
signals relayed to one projectChanged(). OllieView attaches on
construction and follows MainWindow::pluginViewCreated/Deleted.
currentProjectRoot() becomes three-tier: explicit sticky folder ->
bridge baseDir (Kate's loaded project) -> VCS discovery from the active
doc. 7 headless tests via a stand-in QObject mirroring the plugin's
property/signal surface.
Replaces reliance on Kate's project plugin with our own folder-as-project
model. ProjectIndex::resolveRoot(explicit, start) honours an existing
explicit pick EXACTLY (no walk-up, VSCode/Sublime semantics) and
otherwise derives via findRoot with cwd fallback (3 new tests, 15 total).
Plugin: Alt+O 'Open Folder as Project...' pops a dir chooser, sets a
sticky m_projectRoot persisted to $XDG_CONFIG_HOME/olliepalette/project
and restored on load (if still present). 'Close Project' reverts to
auto-derive. Both in the M-x palette. Switchers now scope to
currentProjectRoot() instead of recomputing from the active document.
FrecencyStore (palette lib, Qt::Core, 11 tests): per-id {count,last}
persisted as JSON at $XDG_CONFIG_HOME/olliepalette/frecency.json via
QSaveFile. bonus() = recency bucket x capped visit count, in [0,100] —
below the substring tier (400) so it nudges/tie-breaks without overriding
a stronger textual match, and floats habitual choices up on an empty
query.
Plugin: OllieView loads the store, records every activation (M-x
runAction + file/symbol switcher lambdas) and sets PaletteItem::frecency
before showing each palette. File/symbol frecency keys are
project-qualified so usage does not bleed between repos.
SymbolIndex (project_lib): parseTags reads Exuberant Ctags 5.9 extended
tab format (name/file/line/kind/scope); listSymbols runs
ctags -f - -L - --fields=+nK --excmd=number --sort=no with the file list
on stdin, paths relative to root. 7 unit tests incl. a live ctags run.
Plugin: Alt+R 'Go to Symbol (project)' opens a PaletteWidget of project
symbols (label Scope::name, hint 'kind file'), opens the pick via
MainWindow::openUrl and jumps to its line. Also in the M-x palette and
reachable from a radial by objectName ollie_goto_symbol.
ProjectIndex (project_lib): findRoot walks up for a VCS marker and falls
back to the start dir; listFiles prefers git ls-files (--cached --others
--exclude-standard) and falls back to a bounded recursive walk skipping
noise dirs/symlinks. 12 unit tests.
Plugin: Alt+P 'Go to File (project)' opens a second PaletteWidget of the
project files, scoped to the active document's root (fallback cwd), and
opens the pick via MainWindow::openUrl+activateView. Also surfaced in the
M-x palette and reachable from a radial by objectName ollie_goto_file.
Add src/commands/: texttransforms (pure, unit-tested string transforms) and
olliecommands (a KTextEditor::Command registering sort, rsort, case, b64enc,
b64dec, rot13, uuid, pipe). Verbs act on the selection in place, or the whole
document when nothing is selected. 'pipe <shell>' runs sh -c <shell> with the
selection on stdin and replaces it with stdout (the user types the command,
so shell execution is intended). The command object is created once by
OlliePlugin and auto-registers with the global editor.
15 transform unit tests; 6 ctest suites green overall. Verbs are reachable
from Kate's command line; surfacing them in the M-x palette is a follow-up
(they are Commands, not QActions).
Registering QActions for Ctrl+A/E/H/U/W kept colliding with Kate's own
actions (Select All, Close, …) — Qt reported ambiguous shortcuts and the
per-view shortcut-stripping sweep was fragile and incomplete.
Drop the QActions and the clearConflictingShortcuts machinery entirely.
Handle the keys in the application event filter: accept QEvent::ShortcutOverride
for our combos (so Kate's registered shortcut never fires) and act on the
following QEvent::KeyPress, consuming it. No shortcut is registered, so there
is nothing to be ambiguous with, and new views need no special handling.
All 5 ctest suites green.
Adding our Ctrl+A/E/H/U/W actions alongside Kate's own (Select All, Close,
lowercase, …) left both claiming the same sequence, so Qt reported ambiguous
shortcuts. clearConflictingShortcuts() now walks every GUI-client action
collection and removes our sequences from any foreign action, also clearing
their KActionCollection default shortcuts so they are not restored. The sweep
runs at setup, once more deferred to the event loop (after the GUI factory
merges all clients), and on every viewCreated so new documents don't
re-introduce the conflict.
Also implements the five Acme motions against the View/Document API with
semantics ported from plan9port acme text.c. All 5 ctest suites green.
Double-clicking next to a bracket ()[]{} now selects the text strictly
between the matching pair, across lines and honouring nesting. The event
filter catches MouseButtonDblClick inside the view, maps the click to a
document cursor via coordinatesToCursor, inspects the characters on both
sides, and scans with depth counting (stepForward/stepBackward wrap across
line ends) to find the match. Openers select forward, closers backward;
with no bracket adjacent it falls through to Kate's default word-select.
All 5 ctest suites green.
The paste chord (Acme 1-3) now works: with the left button held, a right tap
pastes over the selection via edit_paste (standard KDE clipboard). This is
conflict-free because the radial gesture is already suppressed while the left
button is held — right alone opens the radial, right while left-held pastes.
The paired right release is swallowed so it doesn't leak a context menu or
other action. All 5 ctest suites green.
The X11 primary-selection paste was leaking through on the middle-button
release because only the press was consumed. Now the middle button is
consumed inside the editor on BOTH press and release (tracked via
m_swallowMiddleRelease), fully suppressing primary paste there. The chord
Cut uses edit_cut, which writes to the standard KDE clipboard (Klipper), so
paste is the normal Ctrl+V / palette paste. All 5 ctest suites green.
Left-button chords only (right button stays the radial). With the left
button held while selecting, a middle-button tap cuts the current selection
and is consumed, so it does not also trigger a primary-selection paste;
middle-click without the left held still pastes as usual.
Implemented in the shared application event filter: track the left button
held inside the active view, and on a middle press while held trigger
edit_cut. The filter is now installed unconditionally (it serves both the
radial gesture and the chord). All 5 ctest suites green.
The opening RMB press leaves an implicit mouse grab on the editor view, so
move/release events during the hold were delivered there, never to the
popup's grabMouse(). Hover froze and the release resolved at a stale
position (always landing on 'More').
Drive the whole gesture from the plugin's application event filter instead,
which reliably sees those events: on press show the radial and set
m_gestureActive; forward each MouseMove to driveHoverGlobal() and the
MouseButtonRelease to driveReleaseGlobal(), both in global coordinates
mapped locally by the widget. The widget's own mouse handlers are gated off
during this external drive (m_externalDrive) to avoid double-handling, and
the manual grabMouse()/releaseMouse() is removed. Key-triggered radials keep
using the widget's local click handling. All 5 ctest suites green.
RMB is the natural radial trigger. The plugin now installs an application
event filter (gated to the active view) that, on an RMB press inside the
editor, pops the radial at the pointer and consumes the press plus the
following ContextMenu event, suppressing Kate's context menu (an
intentional, user-approved trade-off). The radial grabs the mouse on popup
so an in-progress RMB drag is tracked and the release selects the slice.
Config gains a per-radial "button" field (RightButton/MiddleButton)
alongside the key "trigger"; the built-in editing radial binds both Alt+R
and RightButton. All 5 ctest suites green.
- RadialModel: pure tree + geometry (angle hit-test, dead zone, far-flick
snap, descend/ascend). 14 tests.
- RadialMenu: frameless translucent widget painting the current ring with
wedges, labels, branch markers and a central back/cancel hub; mouse hover
highlights, release/click activates a leaf, descends a branch, or
ascends/cancels from the hub; Esc ascends/cancels.
- RadialConfig: JSON -> radial tree parser with a built-in default, so
multiple radials can bind to different triggers. 8 tests.
- Plugin wiring: one trigger action per configured radial (default Alt+R ->
editing radial), popped at the caret via cursorPositionCoordinates().
Slices reference Kate actions by objectName (resolved via findActionByName);
the special ollie_command_palette slice opens the palette.
Honours the agreed model (keys/weapon-wheel triggers now; config carries a
per-radial trigger for mouse-button/gesture triggers later). All 5 ctest
suites green (36 tests).
The same QAction is often reachable through multiple GUI clients; those
are true duplicates and are now collapsed by pointer identity. Distinct
actions that merely share a visible label (common across plugins) are kept
but disambiguated by appending the owning component's display name, and
every entry is assigned a unique, stable id so activating a row always
triggers the intended action rather than whichever one won a hash key.
- OlliePlugin (KTextEditor::Plugin) + OllieView, built as olliepalette.so
via kcoreaddons_add_plugin, installed under kf6/ktexteditor.
- M-x bound to Alt+X (single modifier, adjacent keys on a compact layout,
ApplicationShortcut so it is always live).
- On trigger, aggregates every enabled/visible QAction from the window's
guiFactory()->clients() action collections (keyed by objectName) and
shows them in PaletteWidget; the chosen row triggers the QAction. The
action's current shortcut is surfaced in the group column.
- Enable position-independent code for linking the static palette lib into
the shared plugin module.
- Plugin metadata verified valid via KPluginMetaData.
Frecency wiring deferred (model supports it; plugin passes 0). All three
ctest suites remain green.
Levi Neely