dupe

[frankischilling]

Slow PATH searches and clipboard-tool probes can delay micro's first frame in WSL. This starts detection through clipper.GetClipboardAsync, with the worker and result synchronization owned by clipper. Micro uses the existing Clipboard interface and handles its own mode selection and internal fallback.

Depends on zyedidia/clipper#6. This branch pins the published fork revision 3095b365e472 through a documented go.mod replacement so reviewers and CI can build it without a local workspace. Replace that pin with an upstream clipper revision before merging.

The custom micro-clip command keeps its priority. Internal registers, terminal clipboard access, and their multi-cursor operations remain available during detection. Failed startup detection is logged on first external clipboard use and falls back to internal storage. Explicit initialization refreshes detection and restores internal storage on failure without overwriting a later method selection.

README guidance covers Windows Terminal's OSC 52 option, and option help explains the remaining wait on first system clipboard use.

Closes #4209.

Validation

• Full micro test suites pass on Windows and natively in Ubuntu WSL with GOWORK=off and the published dependency pin.
• Micro's clipboard package and clipper pass go test -race -count=20 on Windows and Linux.
• All 30 existing buffer benchmarks complete on each platform with go test -run '^$' -bench . -benchmem -count=1 ./....
• Windows and Linux editor builds pass. Go formatting and whitespace checks pass.
• A controlled PTY test confirms that upstream waits for a blocked custom probe before drawing, while the previous and revised PR versions display the buffer during detection and paste correctly once it finishes.
• The nonblocking-constructor and explicit-initialization fallback regressions were observed failing before their fixes.

The broader Windows cmd/micro race test still reports buffer hashing/highlighting races, and full micro vet reports existing warnings. Both reproduce on unchanged upstream 393cf248. Clipper's Windows vet warning at winapi.go:90 also reproduces in unchanged v0.1.1; its other vet checks and Linux vet pass.

Startup measurements

Rerun on September 8 with Go 1.27.1. The three Linux binaries use the same -trimpath -buildvcs=false build flags with CGO disabled: upstream 393cf248, the previous PR revision 33548404, and this revision using clipper 3095b365e472.

The runner measures process launch to the first buffer-content output in a controlling PTY. WSL is already running; settings and input files are identical; one warmup per build/case is excluded; and build order rotates evenly. No tests or builds ran alongside the timing samples. These are real clipboard probes, without artificial delays. PATH has 53 entries, including 44 Windows paths, and this environment selects xclip, not the reporter's PowerShell backend.

Executable location / clipboard	Runs per build	Upstream median	Previous PR median	Revised median
WSL Linux filesystem / external	12	132.76 ms	11.70 ms	11.96 ms
WSL Linux filesystem / terminal	9	11.09 ms	10.50 ms	10.21 ms
Windows-mounted /mnt/c / external	12	416.06 ms	297.00 ms	296.16 ms
Windows-mounted /mnt/c / terminal	9	275.94 ms	291.86 ms	291.11 ms

The revised Linux-filesystem/external runs ranged from 9.86 to 16.22 ms, compared with 9.57 to 24.09 ms for the previous PR and 100.06 to 180.74 ms for upstream. Moving detection into clipper shows no meaningful startup slowdown in this sample. The roughly 91% lower median applies to this measured case. Mounted-filesystem results are noisy with overlapping ranges, and the first external clipboard operation can still wait for detection.

[JoeKar]

While it more or less duplicates #4105 + #2245 I'm unsure if it is worth the additional complexity in micro.
From my perspective this must be tackled inside clipper, what I already respond with #4209 (comment).