Is console.screen() still experimental?

[Jackenmen]

Per rich's docs, the alternate screen feature is considered experimental, however it seems that it was introduced 5 years ago? Would you still consider it experimental, or was the documentation just never updated?

Regardless of the answer, I think you might want to consider also mentioning Textual in there since that's probably what people would usually want when reaching for the alternate screen.

[Urus1201]

The docs just were not updated — the alternate screen functionality is stable. It has been in production use for 5 years, the underlying implementation uses standard ANSI alternate-screen escape sequences that are part of every modern terminal spec, and there are no known plans to change or remove it.

The "experimental" label was added when it was first introduced because the team was unsure how different terminals would behave. In practice it works reliably on any terminal that supports xterm-style alternate screen buffers, which covers virtually all modern terminals on Linux and macOS, and Windows Terminal on Windows.

The one caveat worth keeping: Rich does not gracefully degrade if the terminal does not support alternate screen. In a non-interactive environment (CI, piped output, a terminal that strips escape codes), the raw escape sequences will be written verbatim rather than silently ignored. That is the realistic risk, not API instability.

On mentioning Textual: agreed. For anything beyond a short-lived full-screen display, Textual is the right tool. It handles alternate screen, event loops, layout, widgets, and cross-platform edge cases. console.screen() makes sense for simple cases like a quick full-screen progress view; Textual is the right choice for interactive TUI applications.

[willmcgugan]

The warning has been removed