Fix auto-scroll and SIGINT/Ctrl+C on macOS

[botsdown]

This PR contains two fixes for macOS:

1. Fix auto-scroll timer for drag selection

When drag-selecting text past the terminal edges, the view should auto-scroll. This fix addresses multiple issues:

1. Added timer management:

   • autoScrollTimer property to hold the timer reference
   • startAutoScrollTimer() to create timer with .common run loop mode
   • stopAutoScrollTimer() to invalidate and clean up
   • Timer start/stop calls in mouseDragged() and cleanup in mouseUp()

2. Fixed scroll direction in scrollingTimerElapsed():

   • Was calling scrollUp() in both branches
   • Now correctly calls scrollDown() when autoScrollDelta > 0

3. Added selection extension during scroll:

   • Calls selection.dragExtend() after scrolling to include newly visible rows

4. Fixed scroll-down detection in mouseDragged():

   • calculateMouseHit() clamps row to valid range, so scroll-down condition was never triggered
   • Now uses raw pixel coordinates from mouse event to detect when mouse is outside view bounds

Uses .common run loop mode to ensure timer fires during mouse tracking.

---

2. Fix SIGINT/Ctrl+C by forcing forkpty on macOS

Problem

On modern macOS with swift-subprocess available, LocalProcess.startProcess() uses the startProcessWithSubprocess() path. This breaks Ctrl+C (SIGINT) because:

1. The Subprocess path uses POSIX_SPAWN_SETSID which creates a new session without a controlling terminal
2. Without a controlling terminal, the kernel's line discipline doesn't convert ETX (0x03) to SIGINT
3. tcgetpgrp(childfd) returns -1 (ENOTTY) because there's no controlling terminal
4. shellPid is never set in the Subprocess path (remains 0)

The result: pressing Ctrl+C shows ^C but doesn't interrupt the running process.

Solution

Force the forkpty path on macOS. The forkpty function internally calls login_tty() which:

• Calls setsid() to create a new session
• Calls ioctl(TIOCSCTTY) to set the PTY slave as the controlling terminal
• Properly sets up stdin/stdout/stderr

This is a minimal change - just a #if os(macOS) conditional to prefer forkpty on macOS while preserving the Subprocess path for other platforms.

Testing

1. Run a terminal with SwiftTerm on macOS
2. Execute sleep 100
3. Press Ctrl+C
4. Before fix: ^C appears but sleep continues
5. After fix: Process terminates immediately, echo $? shows 130 (128 + signal 2)

References

• The TTY demystified - Explains controlling terminal requirements
• PTY man page - Documents signal generation requirements

[migueldeicaza]

How does Control-C work, I am using it just fine, can you show me what seems to be the problem?

[migueldeicaza]

The auto-scroll seems sensible, I think I can add that.

[migueldeicaza]

Btw, I tried the reproduction steps you have, and for me, I get exactly that without your change:

[botsdown]

Interesting. Let me revisit that one and make sure I had the latest version downloaded before testing again. Thanks!

…

On Sat, Jan 10, 2026 at 12:40 PM Miguel de Icaza ***@***.***> wrote: *migueldeicaza* left a comment (migueldeicaza/SwiftTerm#430) <#430 (comment)> Btw, I tried the reproduction steps you have, and for me, I get exactly that without your change: image.png (view on web) <https://github.com/user-attachments/assets/c40721fe-b4b3-4c27-87b8-cbe221b8c3e5> — Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVJGVEPCRQCIRM4S3J57Y2D4GFBQTAVCNFSM6AAAAACRHS7XVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZTGM2TKMZUGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[botsdown]

After more research, I think the difference might be which code path SwiftTerm takes at compile time. The current logic is: #if canImport(Subprocess) startProcessWithSubprocess(...) #else startProcessWithForkpty(...) #endif swift-subprocess was added to the Swift toolchain relatively recently. If you're on an older Xcode/Swift version where canImport(Subprocess) evaluates to false, you'd get the forkpty path automatically. Ctrl+C works fine there because forkpty establishes a proper controlling terminal. In my particular environment, Xcode 16.2 / Swift 6, canImport(Subprocess) is true, so we take the Subprocess path. The issue I am seeing is that the Subprocess implementation: 1. Creates a PTY pair with openpty() 2. Sets POSIX_SPAWN_SETSID to create a new session 3. But never calls ioctl(TIOCSCTTY) to establish the PTY as the controlling terminal Without a controlling terminal, the kernel's line discipline doesn't know where to send SIGINT when it receives ETX (0x03). The character gets written to the PTY, but no signal is generated. Could you check which path you're hitting? Adding this would confirm: #if canImport(Subprocess) print("Using Subprocess path") #else print("Using forkpty path") #endif If you are on the Subprocess path and Ctrl+C still works for you, There may be something else I'm missing or something unique about my environment.

…

On Sat, Jan 10, 2026 at 1:30 PM Austin Lowry ***@***.***> wrote: Interesting. Let me revisit that one and make sure I had the latest version downloaded before testing again. Thanks! On Sat, Jan 10, 2026 at 12:40 PM Miguel de Icaza ***@***.***> wrote: > *migueldeicaza* left a comment (migueldeicaza/SwiftTerm#430) > <#430 (comment)> > > Btw, I tried the reproduction steps you have, and for me, I get exactly > that without your change: > image.png (view on web) > <https://github.com/user-attachments/assets/c40721fe-b4b3-4c27-87b8-cbe221b8c3e5> > > — > Reply to this email directly, view it on GitHub > <#430 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BVJGVEPCRQCIRM4S3J57Y2D4GFBQTAVCNFSM6AAAAACRHS7XVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZTGM2TKMZUGM> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[migueldeicaza]

I am on the aubprocess path

[botsdown]

Well, not sure what the difference is then. Let me dig a little deeper tomorrow. It must be something on my end. Thanks, Miguel!

…

On Sun, Jan 11, 2026 at 2:13 PM Miguel de Icaza ***@***.***> wrote: *migueldeicaza* left a comment (migueldeicaza/SwiftTerm#430) <#430 (comment)> I am on the aubprocess path — Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVJGVEK3HCZYDUFIOE7ZFDL4GKVE5AVCNFSM6AAAAACRHS7XVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZVGY3DINZWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[migueldeicaza]

I bet I know what it is.

Did you remove the Sandbox entitlement? I bet the sandbox is failing.

[botsdown]

I don't think so... but I will check on that today!

…

On Wed, Jan 14, 2026 at 4:58 PM Miguel de Icaza ***@***.***> wrote: *migueldeicaza* left a comment (migueldeicaza/SwiftTerm#430) <#430 (comment)> I bet I know what it is. Did you remove the Sandbox entitlement? I bet the sandbox is failing. — Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVJGVEMMI6KVNJYX5DLAQ2D4G3C2XAVCNFSM6AAAAACRHS7XVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJSGA4DQMRYGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[migueldeicaza]

Any updates?