[Discussion] System.Console re-design #52374
Comments
adamsitnik
added
design-discussion
|
Tagging subscribers to this area: @carlossanlop Issue DetailsThe initial design of When .NET became cross platform, a number of issues arose (click on the details button below to see the full list) as there was no good way of mapping some Windows-specific concepts to Unix. A good example are all The current design makes no distinction between Moreover, By creating this issue I would like to start a public and transparent discussion about what is wrong with the current design of cc @jonsequitur @KathleenDollard @patriksvensson @colombod @Keboo @HowardvanRooijen @daxian-dbw
|
dotnet-issue-labeler
bot
added
the
untriaged
|
@mdh1418 @MaximLipnin is there any chance that you could share your experience from #41184 #50931 ? |
|
@adamsitnik The work in #41184 and #50931 was primarily done to leverage the platform compatibility analyzer and warn users when a particular API was unsupported on the specific platforms. I believe we had taken note of which APIs failed with |
|
Microsoft needs to give @patriksvensson a ton of money and replace with spectre. |
|
@phillip-haydon If you notice, Patrik is CC'd on the first message in the thread, because we've been having fortnightly calls for many months on the subject! The point of this thread is to mobilise "an army of the willing" who want to see these improvements invested in, and delivered! My original request was "please can we interop between System.CommandLine and Spectre?" 😁 |
|
I saw, I'm just totally blown away at spectre, been following it on twitter, we need to give Patrik more recognition that he's built something amazing :D (and the contributors to the project too) |
|
100% I've said that Spectre delivers the "high level productivity API", that enables me to build impressive things quickly. It's like having the WebControls / WinForm Controls / WPF Components for the CLI, but there are also the lower-level APIs that are needed to deliver that experience consistently across all the platforms that .NET Supports. Hence my tagline of: Spectre.Console + System.CommandLine = ❤ |
|
Please make sure it works great with https://github.com/migueldeicaza/gui.cs |
|
@migueldeicaza would you like to provide some feedback based on your experience with building https://github.com/migueldeicaza/gui.cs? |
|
FWIW, I'll throw this into the mix: https://github.com/alexrp/system-terminal There are some aspects of that library I wouldn't necessarily repeat if I were to start from scratch, but I think it provides a mostly reasonable API surface that could serve as inspiration for a |
|
I maintain dotnet-shell so a lot of the thing I’m doing with Console are less about UI and more about input handling. Unordered list of problems with Console / features I often require
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I agree that System.Console is too tied to Windows, and there are things that are hard to emulate on Linux (and generally on terminals that rely entirely on a stream of bytes). The list of challenges above seem to be a blend of limitations in the current implementation, with some design challenges - I am not convinced that they are all design flaws (take for example the Color ones, or the Android/iOS ones that really are not speaking to a real terminal but a log). It might be useful to compare the bugs above against the Mono version (the official version on Linux, that emulates .NET Framework 4.7) as some of those seems like limitations of the current .NET Core implementation, rather than design flaws. If I were to design a new system, I think that I would do a few tiers of work: (a) Put the terminal in raw mode/cooked mode, byte-at-a-time vs line-at-a-time Then I would provide a split "WindowsConsole" with all the capabilities that Windows has (there are a bunch of things missing from System.Console, gui.cs shows a few of the things missing), and then also add an "XtermLineageTerminal" where there is a progression of capabilities from the simplest black and white VT100 all the way to modern terminals which support quite a number of capabilities. The models are different, in Windows, folks can assume a framebuffer exists, while in vt100-derived terminals you must rely on escape sequences to get the job done. In the old days, it made sense for a library to interpose itself between the application and the terminal to optimize which command should be sent based on the changes made to the screen - while there is a mild case to be made for this, nowadays, connections and terminals are fast enough that it does not really matter all that much - so layers like ncurses might be overblown for things like this. While gui.cs supports using the plain System.Console as a driver, it also has a Windows driver (for access to things like mouse events and additional modifiers) and a curses-driver, for Unix systems. |
But unfortunately, Windows driver mouse events aren't supported on |
|
Possibly slightly OT, but I would like better handling of buffers. It was somewhat unintuitive to me that running a command through System.Console has different buffering behavior (despite |
|
Splitting it up into base/Windows/XTermLineage as Miguel mentioned makes sense to me, similar to how .NET 5 has platform-specific TFMs. |
|
|
Standardize a Warning stream. It's frustrating working with Powershell and Azure DevOps automation and whatnot how all of them support the same stdout and stderror outputs but they all implement their own distinct flavor of Warn and they're not compatible. Even if the implementation of the warning stream on most consoles is done as "color the text orange" instead of doing smart things like warning-specific redirection like Powershell offers, having a standard API for logging warnings would simplify a lot. I want "Console.Warn". But that probably requires some OS support that doesn't exist, I assume. |
|
From PowerShell experience I opened #800 to get support for tab-completions. Also there was mentioned it is desired to have a featured line editor. |
|
@iSazonov Tab completions are available today. They're at a higher layer than |
|
@jonsequitur Thanks for pointing System.CommandLine but PowerShell uses low level API to implement tab-completions for cmdlets. |
|
One pain point for my libraries is CJK (Chinese, Japanese, and Korean) output. In the console, a single CJK character renders as two characters wide, versus English/Latin characters which are only one character wide. If you're trying to do any sort of fancy rendering where you care about character positions and alignment, it becomes pretty complex. If it's not designed for upfront, it's painful to add later on as it breaks a lot of assumptions. Spectre.Console maintains https://github.com/spectreconsole/wcwidth/ to help retrieve this character width information, another C# implementation is this wcwidth gist. |
Currently PowerShell PSReadline uses simple heuristics and it would be great to have native support the feature in .Net. |
|
Currently |
|
Hi, just wanted to say that using var pos = Console.GetCursorPosition();
for (int i = 0; i < 100; i++) Console.WriteLine("Other line");
Console.SetCursorPosition(pos.Item1, pos.Item2);
Console.Write("Alternative text");On windows this should put the text "Alternative text" on the first line of the output, but on macOS, it puts it at differing locations depending on how scrolled down you got. |
|
#52807 is another issue to look at when we explore this space. |
|
I thought it was just with the ncurses that the horizontal scrolling wheel was not detected on Edit: |
|
If we do a redesign I think we should leave the old In this new API we can then modify all the sins we know of in |
|
@deeprobin That's the expectation. We're not going to break System.Console. This is to collect info on what the 'sins" of System.Console are. |
|
Hi, just wanted to also say that Console.Clear doesn't do what I'd expect on macOS. It should send |
@hamarb123 I think that bug does relate to the current API. Can you create a new Issue for this?
I am not sure if this is possible. I guess this is something that belongs to the But there are ANSI control sequences for scrolling 1 (but these are not supported in
Footnotes |
|
FWIW, no, controlling the scrollbar is not something that's broadly possible with VT/escape sequences. The "scroll up/down" sequences are used for shifting the contents within the active buffer (the "viewport" at the bottom of the scrollback), and account for things like scroll margins, but they don't move the viewport into scrollback. Not all terminals have support for scrollback. There have been a few attempts across the ecosystem to try and roll one-off sequences for controlling the position of the viewport, but those aren't widely implemented (to the best of my knowledge). |
|
Thanks, I tried some of those sequences and none of them scrolled back into the scroll-back on macOS. |
|
Well what I noticed was mostly things like Read/ReadKey. windows is the os where you can just ReadKey where on unixes it requires switching back and forth between terminal canonical mode, or what is done here, just staying in non canonical mode, so a dotnet console app, even a simple one reading lines, doesn't kinda feel native. Even though the fact itself that you can just ReadKey without doing os specific things is also useful. |
That's another good point @webczat, something like ReadLine doesn't even let you press left and right to move the cursor - I've not seen any other console utility that does this on macOS (except things like vi where it's intentional in certain contexts) - also this doesn't mean they don't exist, I just haven't experienced them. |
Well generally it's exactly the canonical vs non canonical mode. in canonical mode (default) dotnet is not supposed to handle things character by character, just ReadLine should read from terminal until newline, as only full lines are sent to it. In case of non canonical each character is sent and everything including ^u and ^k keystrokes and other such things, backspace etc needs to be directly handled by the program. |
#28355 - seems like I've commented here before also |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@BDisp please create a new issue, this thread is dedicated to Console re-design |
and others
The initial design of
System.Consolewas mainly driven by Windows OS capabilities and available APIs.When .NET became cross platform, a number of issues arose (click on the details button below to see the full list) as there was no good way of mapping some Windows-specific concepts to Unix. A good example are all
Console.Window*APIs: on Unix the Window is owned by the Terminal app, the .NET Console App has no control over it.The current design makes no distinction between
ConsoleandTerminal, which is also a source of plenty of issues (mostly for apps that have redirected output).Moreover,
System.Consoleis astatic classand there is no common abstraction that would allow not only for testing but also for integrating projects like spectre.console and System.CommandLine.Rendering.By creating this issue I would like to start a public and transparent discussion about what is wrong with the current design of
System.Consoleand how we could fix that. Based on the results of this discussion, I would like to create a proposal for .NET 7.cc @jonsequitur @KathleenDollard @patriksvensson @colombod @Keboo @HowardvanRooijen @daxian-dbw
Console.ReadKey:Console.ReadKeyreturns incomplete information for some key sequences on Linux Console.ReadKey returns incomplete information for some key sequences on Linux #802 (.NET 6)System.ConsoleKeyInfocan not handle Unicode surrogate pair and Emoji Sequences System.ConsoleKeyInfo can not handle Unicode surrogate pair and Emoji Sequences #27828Console.ReadKey()doesn't work for keys from the numeric keypad in the PuTTY ssh clientConsole.ReadKey()doesn't work for keys from the numeric keypad in the PuTTY ssh client #25735Console.KeyAvailablecauses the next Unicode character input 'EN DASH' to be skipped in console [Windows Terminal]Console.KeyAvailablecauses the next Unicode character input 'EN DASH' to be skipped in console #38966Console.ReadKeythrows in unexpected circumstances Console.ReadKey throws in unexpected circumstances #59059Console.Writethat also take aConsoleColorparameter #61731)Console.CancelKeyPress:Console.OpenStandard*few times slower on Linux Console.OpenStandard* few times slower on Linux #31396The text was updated successfully, but these errors were encountered: