MS Windows console support by lukstafi · Pull Request #12 · ocaml-community/notty-community

lukstafi · 2025-11-11T12:53:16Z

This PR fixes #2 (winsize) drawing from the two commits mentioned there -- incorporates contributions from Antonin Décimo.

This PR also provides proper console support on the Windows OS -- courtesy of Claude. I verified the behavior via my project ppx_minidebug.

Vibe-coded using Claude Code.

lukstafi · 2025-11-28T13:42:54Z

I am seeing errors in some runs in a CI suite across a wide range of targets, e.g.: https://ocaml.ci.dev/github/ahrefs/ocannl/commit/5c2fd68319a965307de8ed1eb719d98fde824116/variant/fedora-42-5.4_opam-2.4

The upside is that when this CI suite becomes green, I get more confidence in this PR.

Edited to add: this is fixed now.

Alizter · 2025-11-28T22:07:57Z

I did not have the time to look at this yet. cc @MisterDA who may also want to have a look.

dinosaure · 2025-12-01T14:58:54Z

    | C0 '\x1b'        -> key `Escape []
    | C0 ('\b'|'\x7f') -> key `Backspace []
-    | C0 '\n'          -> key `Enter []
+    | C0 ('\n'|'\r')   -> key `Enter []


We can probably affine the pattern matching with Sys.os_type.

Isn't this reversed, too? The line ending is CRLF, \r\n.

@MisterDA This is pattern alternative of characters, not string matching. Is there an actionable item here for me? It feels innocent to map '\r' to the Enter key but I could make it a when Sys.os_type = "Win32".

This is pattern alternative of characters, not string matching.

Right, my mistake!

Is there an actionable item here for me?

Not sure. Have you observed the \r behavior on Windows?
In any case yes, you could restrict it to Windows and/or Cygwin.

Why do we need to generate such keypresses for carriage returns in the first place? Shouldn't the new line be enough?

In raw mode on Windows, the console delivers the actual carriage return character (\r) when Enter is pressed.

Here is how Claude defends my stance that the Sys.os_type condition would be less clean: "making it unconditional is simpler and accepting \r as Enter on all platforms seems harmless. Historically, \r (carriage return) was the "return" key anyway, so it's semantically correct.

Arguments for keeping it unconditional:

Simpler code, no platform checks needed

\r is rarely sent by itself on Unix terminals in practice, so there's minimal risk of false positives

More robust - handles edge cases like users running Windows terminal emulators on Unix, WSL scenarios, or unusual terminal configurations"

Ok but I prefer to have a comment at least, specially about a possible false positive for unix platform. I think that in the long run, we’ll probably come across this line of code again. Otherwise, I ok to merge it.

MisterDA · 2025-12-07T19:42:00Z

If this PR incorporates some of the code I submitted, I would appreciate being listed as a commit co-author.

This commit adds native Windows support to the notty-community library: - **winsize.c**: Implement Windows console API support using GetConsoleScreenBufferInfo - Use srWindow (visible area) instead of buffer size for accurate terminal dimensions - Return 0 from winch_number on Windows (no SIGWINCH signal) - Add portable unused parameter macro for C23/GNU/other compilers - Include Haiku compatibility for platforms with ioctl in unistd.h - **notty_unix.ml**: Handle winch_number returning 0 on Windows - Prevent signal registration errors when SIGWINCH is unavailable - Return no-op revert function for platforms without window resize signals - **dune**: Add compiler-specific C flags - GCC/Clang: -Wall -Wextra -O3 - MSVC: /W2 /Ox - Use ocaml-config:ccomp_type to select appropriate flags Co-authored-by: Antonin Décimo <antonin@tarides.com> Co-authored-by: Ali Caglayan <alizter@gmail.com>

Signed-off-by: lukstafi <lukstafi@users.noreply.github.com>

On Windows, Unix.tcgetattr raises Invalid_argument instead of Unix_error(ENOTTY) when terminal control functions are not implemented. This caused crashes when using notty-community TUI tools on Windows. Add exception handler for Invalid_argument to gracefully handle Windows platforms where terminal attributes cannot be configured. Fixes: Error: Invalid_argument("Unix.tcgetattr not implemented") Co-authored-by: Antonin Décimo <antonin@tarides.com>

…ality This commit enables full terminal UI features on Windows 10 and later by activating the Virtual Terminal processing mode through the Windows Console API. **New file: win_console.c** - Implements caml_notty_setup_windows_console() to enable VT processing - Sets ENABLE_VIRTUAL_TERMINAL_PROCESSING for output (colors, cursor control) - Sets ENABLE_VIRTUAL_TERMINAL_INPUT for better keyboard input handling - Disables line input and echo for raw terminal input - Enables window input for resize event detection - Gracefully handles older Windows versions and non-console outputs **Updated: notty_unix.ml** - Calls setup_windows_console() when TERM variable is not set (typical on Windows) - Uses ANSI capabilities (Cap.ansi) when VT processing is successfully enabled - Falls back to dumb terminal mode if VT processing unavailable **Updated: dune** - Added win_console to the list of C stubs to compile **Benefits:** - ✅ Colors and text attributes now work on Windows - ✅ Cursor positioning and screen clearing work properly - ✅ Double-buffering via alternate screen buffer - ✅ Improved keyboard input handling - ✅ Window resize event detection Requires Windows 10 TH2 (v1511) or later. Older Windows versions will continue to work with degraded functionality (dumb terminal mode). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>

Windows terminals send carriage return '\r' (0x0D) for the Enter key, while Unix terminals send line feed '\n' (0x0A). Previously, '\r' was being misinterpreted as Ctrl+M due to the C0 control code fallback logic. Updated the Enter key pattern match to accept both '\n' and '\r', ensuring Enter key works correctly on both Windows and Unix platforms. Fixes: Enter key producing 'M' character on Windows 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>

Remove parentheses from the C23 [[maybe_unused]] macro expansion. The parentheses caused GCC to interpret the parameter as a type name, triggering -Wimplicit-int errors on Fedora 42/43 and openSUSE 16.0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>

lukstafi · 2026-01-24T17:04:25Z

Idea originators are now credited in the revised commits.

Alizter · 2026-01-24T17:05:18Z

Do mouse and keyboard events work? I believe @MisterDA's patch doesn't handle that but it was displaying.

lukstafi · 2026-01-24T17:08:30Z

Do mouse and keyboard events work? I believe @MisterDA's patch doesn't handle that but it was displaying.

I have not attempted nor verified mouse events and keyboard events beyond regular typing, arrow keys, and [Enter].

Looking at the code, Claude says that events should work in general:

"Based on the code, yes, both mouse and keyboard events should work on Windows 10+.

The crucial piece is in win_console.c:48, where the code enables ENABLE_VIRTUAL_TERMINAL_INPUT:

inMode |= ENABLE_VIRTUAL_TERMINAL_INPUT;

This is the key that makes Windows Console emit ANSI escape sequences for both keyboard and mouse input, rather than Windows-specific console events. Without this flag, the Windows Console won't send the CSI sequences that the mouse event parser in notty.ml:790-809 expects.

The mouse handling enables several ANSI mouse modes on notty.ml:553-554:

; mouse = (fun x b -> b <| if x then "\x1b[?1000;1002;1005;1015;1006h"

These enable various mouse tracking protocols (button press, drag, SGR mode, etc.). To summarize:

Keyboard events: Yes, work via ANSI escape sequences once VT input is enabled
Mouse events: Yes, work via ANSI escape sequences (CSI codes) once VT input is enabled
Caveat: Only on Windows 10+ (which introduced Virtual Terminal support)
Pre-Win10: The setup_windows_console() call will fail and return 0, falling back to dumb capability mode (no mouse/keyboard events)"

lukstafi · 2026-02-07T11:19:33Z

Friendly ping? Anyone feel free to create a new PR if there are any worries about this one.

dinosaure · 2026-03-17T11:25:28Z


-#define __unit() value unit __attribute__((unused))
-
-CAMLprim value caml_notty_winch_number (__unit()) {


I'm not sure that this thunk should be a part of this PR, can you remove it (and probably propose such change into another PR)?

dinosaure · 2026-03-17T11:31:33Z

We probably should add a CI also for Windows with this PR. Let me know if you have time to add it, I have a little free time to participate, merge this PR and probably release the package on opam-repository.

dinosaure

On cb1bed6, we probably should just copy/paste these lines which is used for several years now on many projects.

dinosaure · 2026-03-17T11:35:16Z

And a last thing, is it possible to keep ASCII charset on commit messages?

Alizter self-requested a review November 11, 2025 14:13

lukstafi marked this pull request as draft November 28, 2025 13:43

lukstafi marked this pull request as ready for review November 28, 2025 20:20

dinosaure reviewed Dec 1, 2025

View reviewed changes

lukstafi and others added 6 commits January 24, 2026 12:18

Missing homepage

ef547c5

Signed-off-by: lukstafi <lukstafi@users.noreply.github.com>

lukstafi force-pushed the master branch from 708e36b to cb1bed6 Compare January 24, 2026 11:22

lukstafi requested review from MisterDA and dinosaure March 2, 2026 11:21

dinosaure reviewed Mar 17, 2026

View reviewed changes


		#define __unit() value unit __attribute__((unused))

		CAMLprim value caml_notty_winch_number (__unit()) {

Conversation

lukstafi commented Nov 11, 2025

Uh oh!

lukstafi commented Nov 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Alizter commented Nov 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MisterDA commented Dec 7, 2025

Uh oh!

lukstafi commented Jan 24, 2026

Uh oh!

Alizter commented Jan 24, 2026

Uh oh!

lukstafi commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lukstafi commented Feb 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dinosaure commented Mar 17, 2026

Uh oh!

dinosaure left a comment

Choose a reason for hiding this comment

Uh oh!

dinosaure commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

lukstafi commented Nov 28, 2025 •

edited

Loading

lukstafi commented Jan 24, 2026 •

edited

Loading