General cleanup, safety, and performance work on ConsoleDrivers

Filing an actual issue now that I've gotten to work on things that have been talked about here and there and some discretionary/opportunistic bits along the way.
This one starts with the console drivers.[^NoBullyingTheDrivers]
I'm nearly done with what I'm slapping a round 1 label on and will have a PR ready later today, hopefully.
Things that are addressed so far:

General code cleanup and organization.
Bug fixes

Addressing both theoretically possible bugs based on the intent and usage of the code as well as possible problems pointed out by static analysis, such as potential null reference exceptions.
Tweaks to certain exception throwing and handling to help identify, report, and handle what's going on and to align exception handling closer to design guidelines and conventions.
Preventing the conditions that lead to certain avoidable exceptions.

Type-safety/correctness

Things like generics, mostly.
Also cases related to nullable structs, null checks, polymorphism, and native interop.

Thread-safety

That part (so far) is minor and mostly informational - comments and such.
More specific concurrency work will happen later on, whether here or in a separate issue.

Performance

Various approaches to try to make things a bit leaner where I see a reasonable opportunity to do so.
Things like ref passing, use of ref locals, use of Spans, avoiding run-time values that are still just constants and making them compile-time constants, etc.
Priorities are in this order:

Speed and simplicity, with basically equal priority

Simplicity - I'm not going to do things that are hard to maintain or understand.
Execution speed - Largely avoiding copies and avoidable heap operations.

Memory consumption
Compilation, design-time, and testing performance

Small but non-zero work items to reduce how heavy the solution is on dev and CI machines, overall.

Compiled assembly size

Not really directly addressing (at least not yet anyway), but paying attention to it.

Trim-friendliness

Eliminating uses of reflection.
Use of generics instead of Type values.

This one also falls under performance, and is a type-safety thing, too. Type-typed method parameters are a break in the chain for static type analysis, which is why they aren't trim-friendly.

Nullability context

Turning it on wholesale for most files I'm touching, and in targeted sections in others I'm not interested in fully migrating in this round.

Also using the resulting analysis to improve code in various places where it makes or could make a difference.

This also falls under bug fixes and type safety.

Interop/PInvoke

Migration to source-generated interop.
Using CsWin32 to create more robust native interop types and methods.

Some or potentially all generated code may get copied to permanent files since the APIs used are stable, to enable hand-tweaking and for sake of transparency and simpler debugging.

Some structural reorganization

Moved some files.
Split multi-type files that were worked on into one type per file.

Testing improvements

More parameterization
DRY-er code (largely enabled by generics and things like MemberData)
Use of Assume (from the Xunit.Assume extension package) to differentiate pre-conditions in some tests from the test itself (my god why is Xunit so terrible???).
Better determinism/repeatability.

Removing some uses of CombinatorialRandom, since that makes every test run different where it is used.

Using and re-using new common helper methods to provide simple, clean, and consistent generation of test cases.
Applying attributes such as category traits to various tests and test classes.
Tweaking some tests to provide better accuracy, speed, simplicity, etc

Probably more, but I want to get back to work now.

I've done it as a ton of mostly smaller commits, as usual, to make it easier to follow along through the commit graph. However, one of the biggest changes I made at the start is actually what prompted some of the additional work that got done in this round, and hasn't been committed to the branch yet, so the current head of https://github.com/dodexahedron/Terminal.Gui/tree/v2_d12_some_driver_cleanup_1 will not compile at the moment, though my local copy (which of course DOES have those changes) compiles and passes all tests. I just need to finish the work on it before I can commit and push that part.
PR will come when I push the commits with that work finished.
There are also a few extra bits of work I want to do before round 1 is done, beyond that, but those will come after a draft PR is submitted.
[^NoBullyingTheDrivers]: No specific reason about the code or code quality itself for picking that as a starting point for this work. It was based on the fact that they're alphabetically early in the project folder tree, they're some of the first code that runs, and the first warnings in the list when I turned analysis up a notch locally brought me to one of those files.

Oh another biggie I forgot to stick in the list of stuff that's already (mostly) done, and which falls under more than one of those top-level categories:
The code around use of unmanaged resources like the console file handles used with SetConsoleMode and such has been reworked to use actual SafeHandles (FileHandles, primarily) to enable better/safer/easier use of them, including proper lifetime management/disposal.
That's important because Terminal.Gui's lifetime is in no way tied to the lifetime of the entire application (which is another reason I am particularly against unnecessary use of statics).
As a real-world case of that concept:
My SnapsInAZfs application, which led to me using and then ultimately contributing to TG, ONLY uses TG in a specific scenario, and otherwise the application typically runs as a headless service process or a one-shot process that has no need for a TUI. It's only used for a configuration interface.
The point is that we can't treat TG like it is going to be in use from start to end of the application. That makes proper handling of things like unmanaged resources pretty critical to not make any assumptions aroud.

@tig, a win32 question for you:
Have you ever tried or considered creating additional handles to the stdin/stdout/stderr file descriptors at startup time?
That a method that can be used to grab our own copy of the original file descriptors, which can then be used for the lifetime of TG, regardless of what the consuming application does.
Why do that?
It would fix cases where one or more of those are redirected after the application is launched, which currently causes a crash.

@tig, a unicode output question for you, RE: the NetWinVTConsole class:
It has the same guard against non-BMP runes as the CursesDriver does. Why is that there?
The windows console can display any UTF-8 character your font has a symbol for, including surrogates.
Behold:

// This code:
Console.OutputEncoding = Encoding.UTF8;
ReadOnlySpan<byte> bytes = "👨🏻👨🏼👨🏽👨🏾👨🏿"u8;
using Stream stdout = Console.OpenStandardOutput();
stdout.Write(bytes);
stdout.Flush();

// Has this output:

Also works fine for UTF-16:
Console.OutputEncoding = Encoding.UTF8;
ReadOnlySpan<byte> bytes = "👨🏻👨🏼👨🏽👨🏾👨🏿"u8;
using Stream stdout = Console.OpenStandardOutput();
stdout.Write(bytes);
stdout.Flush();

Console.OutputEncoding = Encoding.Unicode;
Console.WriteLine();
Console.WriteLine();
Console.WriteLine(Encoding.UTF8.GetString(bytes));

For reference, the UTF-8 version of the string is 44 bytes, and the UTF-16 version is 20 chars (40 bytes), in case there's any question of whether those 5 emoji are multi-byte/surrogates or not.

There are a ton of nuances including versions of WT. it's possible they fixed Atlas since I last worked on this.
Happy to have it finally fixed. But I'm skeptical.
If you think you have a fix please test with CharMap.

Yeah I suspected that might be the sort of sticking point.
Mainly, I wanted to either be able to remove the IsBmp check on that or put a remark on it like the one in CursesDriver, for now. This work isn't aimed at changing our unicode handling. That, if/when it comes, will be in a completely different change set.
We do have ways of continuing to drastically reduce allocations and copying and all that around handling of text, but that will also come in time and requires a lot more fine-grained testing than the sort of changes I intend for this and subsequent change sets in the series.

Update:
I Decided to go all the way with the PInvoke improvements for the files being touched in this round.
I let CsWin32 generate the initial interop types, and then I took the generated code and refined it to what you'll see in the PR. I then removed CsWin32 since further benefit from it only really exists if adding new PInvokes, specifically for windows APIs, so may as well not make builds take the extra couple of seconds. 🤷♂
These involve no run-time code generation and only use blittable types for the platform calls, so are thus theoretically fully trim-safe.
I've still got a bit more left to do with it, but I'm working on it right now.

Update:
I Decided to go all the way with the PInvoke improvements for the files being touched in this round.
I let CsWin32 generate the initial interop types, and then I took the generated code and refined it to what you'll see in the PR. I then removed CsWin32 since further benefit from it only really exists if adding new PInvokes, specifically for windows APIs, so may as well not make builds take the extra couple of seconds. 🤷♂
These involve no run-time code generation and only use blittable types for the platform calls, so are thus theoretically fully trim-safe.
I've still got a bit more left to do with it, but I'm working on it right now.

Huge.
I started doing this way back in #2490 but ran out of steam. You doing this will help that effort immensely!

Well, and, as part of it, I compared code generated by CsWin32 against the cod generated by use of LibraryImportAttribute.
CsWin32 tends to generate leaner code in some cases, but it also doesn't really understand some nuances of the underlying APIs, it seems, or at least for whatever reason does not generate quite as robust code around the marshaling of things between managed and unmanaged as LibraryImport does.
They are both source generators targeted at broad usage and compatibility, so of course they both generate slightly sub-optimal code in their own ways.
So what I'm doing is taking cues from the output of each, paring it down to what's actually relevant, cleaning things up to be legible, and whatever other tweaks make sense for these specific API calls and our use of them.
I'm pretty sure I mentioned a long time ago, in another pinvoke-related issue, that LibraryImport doesn't actually fully replace DllImport. DllImport is the mechanism used for PInvoke, at the end of it all, even for source-generated interop. It's just that, if you use DllImport without ensuring that everything has already been marshalled correctly and everything is blittable, the compiler ALSO emits a stub into the IL that triggers run-time generation of the code necessary to do all of that, and that's what is incompatible with trimming, because that's all Reflection.Emit and such.
One thing CsWin32 does that looks, on the surface, like it might be a nice advantage, is that is also generates structs to match native types like HANDLE. Cool, right? Well, yes, in some cases. But not this one.
There are already built-in types specifically for this stuff. In particular, SafeFileHandle and its associated types are much more robust way of wrapping the handles involved. The most basic operations they perform are pretty much the same - wrapping a nint and making them more meaningful than a plain nint. But SafeFileHandle also addresses some subtle but very real concerns, such as stronger reference counting to ensure that unfortunate timing of the garbage collector doing a collection don't result in things getting lost.
It also implements IDisposable and proper finalization, which isn't possible with a struct, because they do not participate in anything related to the GC (the other definition of "unmanaged").
However, CsWin32 did generate some helpful things, like enums for the various DWORD constants used for methods like SetConsoleMode and for the values of the STD_HANDLE constants for stdout, stdin, and stderr. Those things are handy, but aren't generated automatically by LibraryImport, since it only uses whatever types you specified in the partial method signature.
So, I'm keeping those, since they're simpler and more expressive than having a bunch of constants defined, and easier to use when calling things.
For any interop type added, I went to the documentation for those APIs and grabbed the relevant portions to stick into XmlDoc comments so we have a nice and fully-documented set of stuff to work with, without having to constantly go back and reference MS Learn.
CsWin32 makes an attempt to do that, but what it creates is REALLY messy and is just raw markdown taken from the github source for the MS Learn documents, which of course doesn't work well in XmlDoc comments.
So, it's been a little bit of a roller coaster with things being introduced, removed, re-introduced, massaged, etc., so I'm distilling the commits down to a lot fewer, mostly just dropping some that ended up being irrelevant noise in the end.
Another bonus to SafeFileHandle: it is cross-platform. .net has platform-specific code to make it work consistently regardless of operating system. That also opens up possibilities for more code reuse across the different drivers, since that is an abstraction that can then be pulled up to a less-derived type in the hierarchy - potentially even all the way to the base ConsoleDriver class. I am not doing any of that in this change set, however. This is just laying the groundwork.

OK, sooo...
I had a thought based on the win32 API calls used to interact with the console.
So yes, there's the handle. But...Why is it a SafeFileHandle? Because it IS a file handle, and always has been since the DOS days.
The device "files" (same concept as how unix treats it) are streams named CONIN$, CONOUT$, and CONERR$, and when you call GetStdHandle, that then just allocates another handle to point to the current process' stdin, stdout, and stderr streams.
And it does it via CreateFile. And the documentation explicitly says that's a way for you to grab a handle to each.
So I figured ok... There are already .net implementations of all of those APIs. It's only the Set/GetConsoleMode that don't exist as far as I can tell (as far as our usage of the console APIs goes, that is).
So I tried it out. And it works beautifully and also provides a way for us to fix a bug that we have basically just tried to work around by dealing with excptions, in the past: the problem of someone redirecting the console streams.
If you grab a new handle to the desired stream via File.Create(consoleDeviceName) where consoleDeviceName is one of the earlier mentioned special file names, you have a handle that the application can't rip out from under you.
Since doing things that require PInvokes that need handles to console streams appears to be a common question about, around the internet, I figured I'd write it up in a more public place than here, with explanation and code sample. The only answers I saw anywhere always immediately resorted to PInvoke, which tends to lead to at several PInvokes, which this method avoids a few of.
It is provided as this answer on Stack Overflow.
It's going to cut lines of code in this PR down by a fair bit. And any chance to avoid crossing the managed/unmanaged barrier in non-native code (ie our code) is a win, as well.

Continuing the above...
The same concept is valid on unix as well.
The console for the current process is /dev/tty, and it is a bidirectional character device, meaning you only need one FileStream to both read and write to it.
If someone redirects stdin or stdout in the program, your FileStream you opened to it is unaffected, just like in Windows.
Unix systems typically also expose sockets that are essentially just symlinks to the console tty device, but in testing among different distros, versions, and shells, the specifics of that vary wildly enough to not be very attractive to try to figure out, though a "socket" abstraction is still basically the same idea, since it's still just a file like everything else. 🤷♂

And of course they're fully capable of ANSI sequences, just like the original stream from the static methods on Console:

    using FileStream consoleOut = File.Open ("/dev/tty", FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite);

    consoleOut.Write ("\x1b[38;5;190m\x1b[48;5;4mI'm writing colored UTF8 directly to the console!\x1b[39;49m\n"u8);

outputs:

The above was run on an Ubuntu 24.04 system, via ssh, connected from Windows Terminal 1.20.11781.0 on Windows 11 24H2 26100.1457.

Side note: Man, I wish they'd back-port the \e for escape to .net 8. 😅
Something that might make sense for us to do to enable easy switching to that in future versions is to define a constant like const char ESC = '\x1b'; and use it instead of \x1b in strings.
If put into a conditional as follows, it would automatically happen if compiled under .net 9 at least:
#if NET9_0_OR_GREATER
const char ESC = '\e';
#else
const char ESC = '\x1b';
#endif

const string ESEQ = "${ESC}[";

Side note: Man, I wish they'd back-port the \e for escape to .net 8. 😅
Something that might make sense for us to do to enable easy switching to that in future versions is to define a constant like const char ESC = '\x1b'; and use it instead of \x1b in strings.
If put into a conditional as follows, it would automatically happen if compiled under .net 9 at least:
#if NET9_0_OR_GREATER
const char ESC = '\e';
#else
const char ESC = '\x1b';
#endif

const string ESEQ = "${ESC}[";

Why just not using the EscSeqUtils class?
public const char KeyEsc = (char)KeyCode.Esc;
public const string CSI = "\u001B[";

Yes, that's the exact idea. I just forgot we had that, in that moment. 😅
In any case, the conditional to switch it out for \e is still relevant, though completely unimportant.

And of course they're fully capable of ANSI sequences [snip]

One additional potentially major upshot of this is it MAY offer a path to escape the clutches of ncurses, at least partially. 🤔

And note that utf-8 string is not a string.
The u8 suffix makes it a ReadOnlySpan<byte> ONLY containing UTF-8 bytes as a compile-time constant. So that sample was pure UTF8 from code to console.
One unfortunate shortcoming of the current implementation of that is that string interpolation and u8 are mutually exclusive, even though interpolated strings can themselves be constants. 😞

oooo but I just had an idea...
Might be a way to achieve something similar. Gonna try it out later.
This is just a reminder to myself, for when I get back, so I don't forget the idea:
u8 + spread operator + collection initializers?

@tig, a question for you:
How many buffers would you like things to be using? Are we wanting to be double-buffering? Triple? More? We can probably afford to go pretty deep if we want, since we're dealing with fairly small screen space, so long as we refine some things like the PInvokes and the marshalling around them.
As I get into the weeds of this, I'm realizing there are some simple yet important things that can be done in modern .net and c# to drastically reduce the hammering on main memory and cache flushes that come along implicitly with how some of the old stuff works, due to memory barriers and other goodn't things that happen quite bit but which can now be mitigated, and in what end up being remarkably simple ways.

@tig, a question for you:
How many buffers would you like things to be using? Are we wanting to be double-buffering? Triple? More? We can probably afford to go pretty deep if we want, since we're dealing with fairly small screen space, so long as we refine some things like the PInvokes and the marshalling around them.
As I get into the weeds of this, I'm realizing there are some simple yet important things that can be done in modern .net and c# to drastically reduce the hammering on main memory and cache flushes that come along implicitly with how some of the old stuff works, due to memory barriers and other goodn't things that happen quite bit but which can now be mitigated, and in what end up being remarkably simple ways.

Previous to your work here, and my work on ConsoleDrivers last year, it was a true mess. What I focused on was correctness and simplicity of the API enabling reduction of duplicated spaghetti code in the the drivers.
I am not YET concerned about performance.
Until we get wide-char rendering and truecolor working on all drivers, AND we have a driver that works purely with ANSI  escape sequences the concept of how many screen buffers we have is still in flux.
Thus, my recommendation is to hold off unless you have absolute clarity of how the above will be addressed within the scope of your design.
IOW: I am biased towards architectural/API cleanliness, and you are biased towards performance. We both tend to each a bit too hypothetically.  I believe the tie-breaker should NOT be hypothetical performance issues. ;-)

I talk about performance a lot because that's just still pretty low-hanging fruit for us, here.
But the main goals I have nearly always originate from architectural improvements and quality of life improvements for both the consumer and their end users. Performance just goes hand-in-hand with it a high percentage of the time when one can write the same operation a little differently during that work and avoid at least a chunk of what made that particular unit expensive. And around PInvoke, those pitfalls are so numerous (in .net applications in general, just because of how all of that stuff works) that it starts to look more like a crater rather than individual pitfalls, and you just happen to have a giant dirt pile 3/4 the size of the crater right next to it ready to push in with a bulldozer.
As it turns out, a lot of what I'm doing in this work enables a pretty large amount of code re-use between the different drivers, which I know you'll love, and which was another of my main goals when sizing up what I wanted to work on for this change series. Performance just happens to be closely related to the things getting cleaned up, which makes me even happier and more motivated. Plus it's nice to get a tangible result. I've always liked improving products, tools, processes, etc every bit as much as creating new ones. Sometimes even more, since I actually have fun trying to get inside someone's head to see if our combined efforts can result in something even better in the end. 😁
Another of my goals for this that I'm pretty sure will make your day once it's ready is to completely eliminate more than one pretty large internal class, due to the cleaner architecture, by eliminating a ton of duplication and then merging what's left since even in their current states they already overlap quite a bit (for various reasons - organic growth can get that way sometimes).
So, if the performance wins we will get from the work I'm doing anyway don't pique your interest, then I'll slightly re-phrase the question:
The architecture in the console drivers is much more complex than it needs to be and can be greatly simplified by doing a few relatively simple things.[^butStill] One of those things requires me to be briefed on some intentions, or else it'll just be me doing that work unilaterally and then going "SURPRISE!" I would rather get your input, in case you had any insights, plans, prior experiences to watch out for, or even just preferences before I pick a design for that.
Just to save a back-and-forth:
I think double-buffering is plenty, but triple-buffering doesn't really take much additional work and could actually make it feel snappier to the end user, even though there's implicit latency added, because the next two frames can get most of their drawing work done before the current frame has finished getting shoved to stdout, which means much higher chance of having a fully-rendered frame ready on next write, ultimately reducing the incidence of tearing (exactly why it's used in 3D applications, too, especially when V-sync to the monitor is in use, which we kinda-sorta-almost-but-not-really have implicitly, in text mode).
As a side-note[^notEven] slightly more than tangential to the topic (secantial? reentrant? 🤔):
I tend to play the long game, strategically. Even though some of the things I'm doing right now will have very visible results to anyone working on the code of TG itself, some of it lays groundwork to make future work easier. And that's actually one of the biggest reasons behind my tendency to check the rulebook (harp on certain conventions): Because most of the ones I try to stick to have pretty solid backing behind them. But I don't think anyone's ever really pushed back on anything that I've made at least a half-decent case for, here, on technical grounds. But I also think my verbosity for sake of covering as many bases at once that I can comes off as though I feel much more strongly than I really do about a lot of things, because I've just found throughout life that things move along a lot quicker if I don't try to explain the 5 mile long train I'm on and just talk about how this particular car can be pimped out for now and then get to the rest later. 😅
Although my #1 preference is a small and passionate group of people with compatible personalities but at least different approaches/strategies for tackling whatever they're presented with, whiteboards all around the room, a whole package of different colored markers with everyone always having a marker in-hand, and everyone giving their thoughts openly and without fear of judgment, resulting in coming up with something awesome (even if awesome in a given context means remarkably simple/elegant) that everyone already groks from the start because it's got a little bit of each of us in every facet. 🙂
I had the perfect team for that, at one job, and loved it so much before [insert predictable story about ham-handed corporate organizational restructuring by new execs wanting to make a mark here] happened. Haven't quite had the same level of it since then, but there are moments. And that's where it becomes a secant rather than a tangent: It's why, even though, sure, I could just do the work and then modify based on any feedback anyone feels strongly enough to give, but instead ask for input on something fundamental that I already have a half-formed opinion on but want the other perspective on, if there is one - even if it's just spitballing. I like spitballing. Got a straw right here in fact.

[^butStill]: And we'll still get the performance boost "for free," as a result of what the changes fundamentally represent.
[^notEven]: More like side-book?

Oh whoops. Looking for a silly GIF made me forget the last thing I wanted to mention that was also a motivation behind specifically asking you the question, directly:
Regardless of the frequency or force with which someone puts their foot down in a project, I'm always cognizant about the artistic/creative element of what we as software engineers do, so there's an element of deference in the question, insofar as the shape of my work will morph to make something with at least a small metaphorical signature of the project principal. Heck, that could even just be liking "DuckBill" over "SchoolBus" for the name of a bright yellow-orange color or something. 🤷♂

I love all of the 👆. I even read it all. Twice.
I'd like to see a double-buffer that could be extended to 3 design. The things I think / have thought about related to this:
TG needs to provide an abstraction layer above terminals.

Standard implementations are getting better and more standardized, but we will ALWAYS have significant differences between Windows, Linux, Mac, WT, ConHost, iTerm, wizterm, footerm, ConEmu, blahTerm, XTerm, TermX, and GruntledTerminator.
Fonts & Unicode & Color.
Plus we have the dimension of the width and slipperyness (bandwidth and latency) of the pipe to the terminal. It is my intent that TUI developers should not have to think about those things unless they are doing something very bespoke.
Oh, users have preferences. Some like mice. Some like clicky keys. Some like quiet keys. Some like it all. Some have 4 mouse wheels. Some have none.

Some proposed Tenets (in addition to those here: https://github.com/gui-cs/Terminal.Gui/blob/40056a6f2c410996537946a69e0f1b4a43a044db/CONTRIBUTING.md)

Write Once, Run Anywhere.^IAmAHypocrite The abstraction layer that enables all of the above should be hidden, as much as possible, from TUI developers.
Speed Matters Less Than Functionality. Breadth of cross platform support is more important than performance.

What others might you suggest?
Related issues where I've written thots:

https://github.com/gui-cs/Terminal.Gui/issues/3622
https://github.com/gui-cs/Terminal.Gui/issues/2319
https://github.com/gui-cs/Terminal.Gui/issues/2747
https://github.com/gui-cs/Terminal.Gui/issues/1316
https://github.com/gui-cs/Terminal.Gui/issues/2933
https://github.com/gui-cs/Terminal.Gui/issues/2610
https://github.com/gui-cs/Terminal.Gui/issues/2803
https://github.com/gui-cs/Terminal.Gui/issues/3119
https://github.com/gui-cs/Terminal.Gui/issues/3413
https://github.com/gui-cs/Terminal.Gui/issues/457
https://github.com/gui-cs/Terminal.Gui/issues/3302
https://github.com/gui-cs/Terminal.Gui/issues/666

Then there's the whole discussion of by whom and when Adornments should be drawn.
I'm PRETTY SURE I can make the current design work and fix this:

https://github.com/gui-cs/Terminal.Gui/issues/2995

But, if I'm wrong, to get the amazing ability to have lines/text "auto join" even when Views are independent, we may need a compositor mechanism that's not LineCanvas.
I will know for sure when this is tackled:

https://github.com/gui-cs/Terminal.Gui/issues/3407

Great stuff @dodexahedron .

Oh yea:
We need to recognize that by tackling

https://github.com/gui-cs/Terminal.Gui/issues/2610

we are effectively building a new ncurses. It would be nice if ncurses wasn't such a POS, but it was designed and built too long ago and has too much weirdness/baggage as we've learned with CursesDriver.
Right now, the code in the UpdateScreen() implementations starts to lay the foundation for the non keyboard/mouse parts of that. But, as I think you've discovered, it barely works as-is.

Whoops. Apparently I didn't click the comment button hard enough this morning when I wrote this up. 😅
But I'll add a TL;DR, which is: 🥳
TL version follows:

Sounds like we were on the same page and didn't even realize it. 😆

I'd like to see a double-buffer that could be extended to 3 design.

Exactly what I was initially thinking. If it really isn't much more to get triple, when work is being done for that, I probably will just go ahead and go all the way from the start. Otherwise, yeah - I'd go for exactly that idea.

TG needs to provide an abstraction layer above terminals.

1000000%
And that's the most significant underlying goal of this change series, in fact, though not explicitly stated in case I wanted to break out into another change set instead. Probably will, anyway, just for organizational purposes, but the work being done right now is definitely aimed at violently shoving some things in that direction.
Fortunately for us, too, .net itself already does provide at least some abstractions, which are the most visible parts of what I'm adopting in this work. And the facilities for that stuff that are available in .net actively continue to improve in various ways - some subtle and some pretty important. So that's cool for us, but just a side-note here. But meshes with your next bullet, somewhat:

Standard implementations are getting better and more standardized, but we will ALWAYS have significant differences between Windows, Linux, Mac, WT, ConHost, iTerm, wizterm, footerm, ConEmu, blahTerm, XTerm, TermX, and GruntledTerminator.

Absolutely. Even just look at the configuration screens in PuTTY for an abbreviated history and collection of various common quirks. 😅  Or at least I assume it still has that screen - ever since windows got openssh, I haven't used putty ever again.
And even within the same major.minor version of the same program, there can be differences that matter to us because of what TG is. Sucks for us, but that's kind of the point of a library like this. Yeah, we give you standard TUI controls, but we also let you do so the same way across at least a reasonable range of environments by doing that for you.

Fonts & Unicode & Color.

It's almost funny to lump those three together in so terse a way in one little bullet, with how big each one is, even all on its own. 😅

Plus we have the dimension of the width and slipperyness (bandwidth and latency) of the pipe to the terminal. It is my intent that TUI developers should not have to think about those things unless they are doing something very bespoke.

Yep. Although at least some of that we get to rely on the lower layers for (or should, to an extent, anyway). SSH, for example, is already over TCP, so order we receive things in isn't our responsibility (or place) to interpret in any other order than that in which it was delivered to us, since TCP won't be handing us anything not in the same order it was transmitted.
But yes - any session with a high BDP has high potential to deliver a suboptimal experience to the user. To that end, one of the most significant things we can do is one that's already in progress, which is adopting terminal control sequences wherever we can, to cut down on the impact of high BDP.
Later on, we could/should also take a pass over things to determine if there are existing operations that can be made lighter-weight by using more of those, as well.
But another broad thing about abstraction overall, applicable to all of the preceding points, is that the current state of the driver infrastructure/implementation is not extensible outside of TG itself. There are required pieces that are exposed in the public API surface, but impossible to implement due to those pieces having tight coupling with internal types.
That's something I'm fixing during this work, too and is a part of things I've been planning for a long time and have mentioned a few times this past year. That being interfaces.
Once I have gotten a little more done, I'm going to extract interfaces for everything in the driver stack and make it all use those interfaces. Then we can even make the actual implementations themselves internal if we really wanted to (probably shouldn't of course), because it will force de-coupling some things and, more importantly, will ensure that anything that is dependent on anything else in that stack is visible and has a guaranteed API contract.
I happen to have actually already done a bit of that on a separate branch, early on in this work, just to see how much work it would take. It's actually not that bad, now, thanks to other work that's been done along the way for V2 and what's being done related to this change series. The reason I paused that work was actually because that is what showed me a lot of what else needed to be done anyway, and I would have ended up deleting a bunch of work that the rest of this work will obviate. For the most part, though, outside of places where the coupling needs to be fixed, consumption of the interfaces when I was doing that were almost universally as simple as changing ConsoleDriver to IConsoleDriver in consuming code. 🥳

Oh, users have preferences. Some like mice. Some like clicky keys. Some like quiet keys. Some like it all. Some have 4 mouse wheels. Some have none.

Ha yeah. Always fun. Another good place to ensure that we not only provide a solid base functionality, but also make extensibility possible without requiring recompiling TG itself.

Some proposed Tenets (in addition to those here: https://github.com/gui-cs/Terminal.Gui/blob/40056a6f2c410996537946a69e0f1b4a43a044db/CONTRIBUTING.md)

Write Once, Run Anywhere.1 The abstraction layer that enables all of the above should be hidden, as much as possible, from TUI developers.
Speed Matters Less Than Functionality. Breadth of cross platform support is more important than performance.

What others might you suggest?

Those are a solid starting point.
Maybe adding something that meshes with the last point above those, about respecting the user and not forcing things upon them.
Another that I've had to mention a couple times that I think deserves its own bullet: "Terminal.Gui is not the application." It is a library. It is just one frankly insignificant component consumed by an application, and needs to get out of the way for any and all purposes not directly related to user interaction. Thus, any assumptions made absolutely critically must be passed through that filter, or else we are putting the consumer in a frustrating box they didn't need to be put in. So, thread/concurrency-safety, lifecycles of anything that isn't strictly gen 0, resource consumption (of all types), accessibility, type safety, exception throwing and handling, and even simple matters of formality (at least in the public API surface) all should be given their due respect. For the most part, they usually are, or are at least thought about, but I think it is worth reminding any contributor that TG is not the application and needs to act that way.

Related issues where I've written thots:

Apps should never reference ConsoleDriver #3622

Agreed at a high/conceptual level. Which actual type they shouldn't directly be using may not yet be fully fixed (or may just end up being a naming thing). But conceptually, right: No, they should not be directly using any of the low-level internal implementations in TG - only a public interface that lays out the required minimal contract to use them. Not allowing any derivation via a mechanism like that would be needlessly draconian, though, for no benefit to us. But I don't think that's your intent anyway.

Refactor ConsoleDriver to minimize duplicated code in all drivers #2319

Heh yep. This one I guess finally tackles that one.

Build a "debug-tap" for ConsoleDriver #2747

I think the desired result can be achieved by simply utilizing the standardized logging framework abstractions provided by Microsoft.Extensions.Logging, which are pretty much ubiquitous elsewhere and are completely agnostic of framework/implementation.
Just add statements to log the low-level stuff at the appropriate level to an appropriate target and then, if/when needed, enable that in your config and it'll "just work."
Not to engage in post-mortem pugilism with this equine critter too much, but we should do that, regardless.

UnitTests: Need unit tests that test the real drivers #1316

Yep. Ideally this change series will finally make that reasonably possible, or at least make it not impossible, so it can be addressed afterward.

Cell needs much deeper thought to truly support Unicode #2933

I've been eyeing Cell a lot while working on this. I've got a bunch of different thoughts stewing on that topic. Will definitely have to come back to that once this is done.

Refactor ConsoleDrivers to support ANSI sequences natively (e.g. Virtual Terminal Sequences on Windows) #2610

Yep. The main pain point I think we'll have to deal with is that the level of support for VTS varies a fair bit from version to version and from host to host, on the same system. We just need to be sure we account for that in some way, even if it's as simple as sticking to the lowest common denominator for sequences we use, for the easy way out.

I'm pretty tired after the rabbit holes I went down (unrelated to TG) before coming back to this, so I won't give direct commentary on the rest of these bullets, since I have not yet looked them over, but the bullets themselves look like 👍 to me across the board:

Harden EscSeqUtils  #2803
Figure out VK_PACKET/ConsoleKey.Packet and build support for it #3119
Improve redraw performance by making Clip be a Region instead of Rectangle #3413
Colors: Update Color System (TrueColor, Blink, Underline, etc...) for v2 (Master Issue) #457
View drawing APIs should restrict drawing to Viewport #3302
Refactor ConsoleDrivers to remove duplicate code #666

Then there's the whole discussion of by whom and when Adornments should be drawn.
I'm PRETTY SURE I can make the current design work and fix this:

Auto-join of Border is not always working #2995

But, if I'm wrong, to get the amazing ability to have lines/text "auto join" even when Views are independent, we may need a compositor mechanism that's not LineCanvas.
I will know for sure when this is tackled:

Refactor Border to use subviews for title, lines, and close button #3407

And this work may also impact that. If all goes according to plan, life should be easier. 🙂

Great stuff @dodexahedron .
Footnotes

https://blog.kindel.com/2013/02/21/james-gosling-screwed-us-write-once-is-anti-customer/ ↩

Addition not in the original:
Ha. I read the blog post today.

I say scratch the "un" from the second to last word. 😆

I think I'm done with this one for now. I went back to working on continuing work on the next branch, so this one is ready as far as I'm concerned.
Pretty big improvements and consolidation already happening with WindowsDriver/WindowsConsole, so far. 😃

Oh and a minor informational side note:
I also loaded the code of this PR up in Rider on Windows and Ubuntu 24.04.1 to make sure things are still friendly to it, and to make sure tests also work in it as expected.
Went well. I didn't encounter any trouble, so looks like we're still good in Rider.
And I gotta say.... While I still don't care for Rider's overall environment, as it still feels perplexingly less capable than ReSharper somehow, it does work really well in the testing and debugging of testing.
The test runner, its output, the UI around testing, and especially coverage, profiling, and debugging of unit tests in this solution in particular do seem to work more reliably in Rider than it does in VS, on those two machines. 🤷♂

Whoops. I meant for that to go in the PR.
Gonna take care of that...

(@tig you in particular may find this interesting... Or want the following few minutes back... One of those, probably...)

You know...
As I was working on the beginnings of a platform abstraction layer, today, I thought, "OK... There's no way this hasn't at least been partially done already, or else how can System.Console work at all, across platforms?"
So I went diving through the dotnet source on github, at the v8.0.8 tag.
There's a wealth of stuff in there that is exactly what we need/want for quite a few scenarios (or pretty close), some of which I was beginning to write almost verbatim re-implementations of, but won't have to now that I've found them. ...But they're all internal types, in .net 8, with a small number marked public in .net 9. But hey - doesn't mean I can't use it now (yay open source with same license)![^standingOnShouldersOfGiants] There's also plenty in there that, while not necessarily directly useful, provides excellent templates for or at least inspiration for what I do need.
I don't need the full implementations of a lot of it - just some types, marshallers, and a base class or two to cut the code I have to write for the custom marshalling down by... a lot...[^suchShort]
While I'm mostly talking about marshalling and PInvoke, specifically, here, it's not limited to that. But that's a big piece of the puzzle, and I'm eager to get back to work on it, so I'm holding myself to a 20-page limit on this comment.[^veryBrevity] 😛
If I do end up taking any actual code directly from the runtime, I'll keep them API-compatible just in case we are granted any gifts of more of them becoming public in the future.
But...
Shifting gears back to the topic of abstractions...
Platform interop, especially if properly abstracted, is an independent, separable component of the library/framework, and there are tangible benefits to separating it to its own component library, as well as potential negative impacts if that isn't done.
Why?
For source-generated PInvoke ([LibraryImport]) to work fully properly, consistently, and deterministically, and to keep it trim-safe, one must use the [assembly: DisableRuntimeMarshalling] attribute, or else the DllImports that LibraryImport generates can still end up needing runtime code generation, which is not trim-safe. And notice the assembly in that. It's an assembly-wide attribute, and that is the only level it is allowed at (and that makes sense, considering what it is). It's even a code fix built in to Roslyn to insert it for you, since it's kind of a bad idea not to be using it, with source-generated interop (and sometimes even with old-school interop, but mostly (not exclusively) in trimming situations).
Why is it being an assembly-level attribute a problem, though (thus prompting the need for separation)?
Because not only does it affect DllImport and LibraryImport, it has effects on more than just them, as well.
A biggie for those two (so...PInvoke), specifically, is that in, out, and ref parameters are not handled for you anymore, nor are any types that are not already blittable, and thus those things can't be used on the native method (the extern that gets the DllImport, whether you wrote LibraryImport or DllImport).
All non-source-generated marshalling is off, so you have two options:

Use only fully blittable types in c#-land, without being able to use things like [MarshalAs] and make PInvoke signatures only use those types, never as references (so can't use half of the Console methods), the short list of built-in types that are blittable or have marshallers defined, or use pointers directly, which gets ugly quite quickly and should be beneath the abstraction layer, since this is C# and we shouldn't be exposing unmanaged stuff raw like that anyway.
Write the glue marshaling code that the Roslyn generator[^ITerkErJerb] uses during source generation of LibraryImport PInvokes. I'm essentially doing a non-generic version of that work, in what I have pushed so far to the work branches for this so far, so it's actually not really any additional work, plus provides a promise of consistency since type marshalling is handled by a very straightforward system specifying managed type, direction and intent of marshalling, and which marshaller does that stuff.[^manThisGotTooLongForANumberedList]

Aside from the PInvoke impact, it also alters how some delegates are handled internally, and imposes strict limitations on the types used for the extern methods, because they MUST comply with the rules/list here. The flip-side of that is that those restrictions make the rules for what can be used quite simple. As above, things either need to be fully blittable and identical to their native representation, OR there must be a marshaller defined that the source generator can make use of.
In any case, I'm pretty sure it would break some of the existing pre-cached delegate implementation inherited from V1 (which is already on the chopping block anyway, so no loss there), but I'm really not interested in trying to find out what, where, and why things are broken by that, since it can all be avoided by just putting interop into its own assembly and doing things the way the native interop docs describe. Then, interop code can be under the auspices of the [assembly: DisableRuntimeMarshalling] attribute, while the rest of the TG code gets to be blissfully unaware of and free of its edicts.
Another really nice benefit to that is that, if I write it as a base abstraction layer[^interYoFACE], with the platform-specific implementations inheriting from/implementing that API, it becomes naturally pluggable, and consumers can leave out the platform-specific assemblies they don't want or need, if size or attack surface or anything else related to dead code is a concern.
I wrote up a bunch of POCs today in a toy app through which I pass darn near everything I write of this nature[^soLonely], to feel out all the concepts involved in all this and more, including custom marshallers (which will mostly or possibly completely eliminate my explicit hand-written PInvoke code layer), safer memory management, buffer pooling, and various console and platform abstraction concepts to make our and consumers' lives easier. Lots of good results, lots of good learning, and some interesting exposition of issues that need to be addressed even if this whole exercise were to be scrapped and the existing implementation used for the time being - some of which are security-critical to a rather frightening degree[^skyIsFalling], but easy to fix and getting fixed, no matter how the rest of this work evolves.
Alright, I wanna get back to work. This is plenty of stuff to chew on, anyway.
...Hey! I kept it under the character limit![^wow]
[^standingOnShouldersOfGiants]: And it's perfectly trustworthy stuff, too, because it's what the runtime would use for its compile-time code generation by Roslyn (who is delightful) or run-time IL generation by Ryu (which we can't rely on for all deployment types), as applicable to each piece, for native interop.
[^soLonely]: Guarantees isolation from the rest of the library, since it's JUST that code, and I can hammer the hell out of it before using it in the library.
[^ITerkErJerb]: Whose job is effectively what I'm already doing by hand, anyway, so she can have that back.
[^dontWorry]: Not to worry. That doesn't mean consuming code suddenly turns ugly. In fact, the entire point of all this is to make the interop code do all that junk for you, so that you, at the call sites for those methods, no longer even have to do things like providing access flags or using some cumbersome semi-native-equivalent struct. Instead, that work gets done in design/compile-time generated source, which you can even inspect if you want, and you can just use things in a much more natural idiomatic C#/.net way, rather than feeling Win32/ncurses/libc/etc's influence directly. You know... abstraction!
[^suchShort]: Wait... The machine can do some work for the human? SIGN ME UP!
[^veryBrevity]: Well... maybe 21... We'll see...
[^wow]: Clearly, Doge wrote some of the footnote tags.
[^skyIsFalling]: Depending on specific spot in the TG code, we're talking 8-10, in CVSS terms. Mostly 10s. Privilege escalation, arbitrary code execution, and more, and they don't need root to exploit. Though one I wrote a PoC of did get the assembly file deleted immediately by MS Defender upon copying it out of the dev drive, due to what it was doing being pretty clearly suspicious (trying to snoop stuff out of LSASS - a historically popular target or component of a wide range of game over-level attacks).
[^interYoFACE]: I'm going to do that either way, using interfaces and such
[^manThisGotTooLongForANumberedList]: It's actually already explicitly in use in code you can see on the first branch of this, with uses of types like SafeHandleMarshaller<SafeFileHandle>.ManagedToUnmanagedIn and family, which are the built-in "custom" marshaller types for SafeFileHandles, which you've been using in every console application you've written in .net 7+ without even realizing it (again - yay abstraction layers), and something similar before that, but not as pretty. That code deals with all the pointers and allocations and pinning and stuff that you really don't want to have to think about.[^dontWorry]

Very interesting.
🤨
I've not looked at the .Console code. Glad you have.
I'd be curious to know what's going on relative to this:
https://github.com/dotnet/runtime/issues/96490

I've not looked at the .Console code. Glad you have.

It's all over the place throughout coreclr, with pieces in at least 6 different libraries . In fact, a fair amount of the platform interop code is actually separated into specific DLLs for various reasons including that those have DisableRuntimeMarshalling specified, but most of the rest of coreclr does not. A lot of that used to be in C, C++, or C++/CLR, but they've really been making an effort to move as much of everything everywhere into pure C# as they can in the past several years, since pinning is expensive, among other reasons.

I'd be curious to know what's going on relative to this:

Yeah there are definitely some fun bits.
It's kinda interesting/odd to me that all the PInvoke code, including types, functions, constants, and marshalling, where necessary, sometimes even with XmlDoc comments, is already in .net in classes named for the library they're in, such as Interop.Kernel32, which, predictably, has a ton of stuff from kernel32, including the specific console functions used by coreclr on Windows. Yet, they're all internal and things like CsWin32 still exist. 🤷♂
As for Console, the underlying platform code for parts of it (which is one of many places coreclr has a PAL) of course uses quite different APIs on each platform, particularly around HCI like mouse input, but then the same (or at least similar) APIs for other bits where possible.
Ironically, on Unixy platforms, one of the methods of a class called StdInReader, which is simply an internal sealed class derived from TextReader (which is what Console.In is), has this to say on its implementation of ReadKey:

  /// Unlike Windows, Unix has no concept of virtual key codes.
  /// Hence, in case we do not recognize a key, we can't really
  /// get the ConsoleKey key code associated with it.
  /// As a result, we try to recognize the key, and if that does
  /// not work, we simply return the char associated with that
  /// key with ConsoleKey set to default value.

And here's the code of StdInReader.ReadKey as of the v8.0.8 tag:
        public ConsoleKeyInfo ReadKey(out bool previouslyProcessed)
        {
            if (_availableKeys.Count > 0)
            {
                previouslyProcessed = true;
                return _availableKeys.Pop();
            }

            previouslyProcessed = false;
            return ReadKey();
        }

        private unsafe ConsoleKeyInfo ReadKey()
        {
            Debug.Assert(_availableKeys.Count == 0);

            Interop.Sys.InitializeConsoleBeforeRead();
            try
            {
                if (IsUnprocessedBufferEmpty())
                {
                    // Read in bytes
                    byte* bufPtr = stackalloc byte[BytesToBeRead];
                    int result = ReadStdin(bufPtr, BytesToBeRead);
                    if (result > 0)
                    {
                        // Append them
                        AppendExtraBuffer(new ReadOnlySpan<byte>(bufPtr, result));
                    }
                    else
                    {
                        // Could be empty if EOL entered on its own.  Pick one of the EOL characters we have,
                        // or just use 0 if none are available.
                        return new ConsoleKeyInfo((char)
                            (ConsolePal.s_veolCharacter != ConsolePal.s_posixDisableValue ? ConsolePal.s_veolCharacter :
                             ConsolePal.s_veol2Character != ConsolePal.s_posixDisableValue ? ConsolePal.s_veol2Character :
                             ConsolePal.s_veofCharacter != ConsolePal.s_posixDisableValue ? ConsolePal.s_veofCharacter :
                             0),
                            default(ConsoleKey), false, false, false);
                    }
                }

                return KeyParser.Parse(_unprocessedBufferToBeRead, ConsolePal.TerminalFormatStringsInstance, ConsolePal.s_posixDisableValue, ConsolePal.s_veraseCharacter, ref _startIndex, _endIndex);
            }
            finally
            {
                Interop.Sys.UninitializeConsoleAfterRead();
            }
        }

In the ConsolePal.Windows.cs version, ReadKey is handled at that layer and doesn't wrap the stream in a bespoke class, because it just immediately runs to the Win32 PInvokes, rather than using streams, since Windows doesn't include anything but keys when you read the handle as a normal file/stream, requiring you to use the ReadConsoleInput function to get the other stuff.:
public static ConsoleKeyInfo ReadKey(bool intercept)
        {
            Interop.INPUT_RECORD ir;
            bool r;

            lock (s_readKeySyncObject)
            {
                if (_cachedInputRecord.EventType == Interop.KEY_EVENT)
                {
                    // We had a previous keystroke with repeated characters.
                    ir = _cachedInputRecord;
                    if (_cachedInputRecord.keyEvent.wRepeatCount == 0)
                        _cachedInputRecord.EventType = 0;
                    else
                    {
                        _cachedInputRecord.keyEvent.wRepeatCount--;
                    }
                    // We will return one key from this method, so we decrement the
                    // repeatCount here, leaving the cachedInputRecord in the "queue".

                }
                else
                { // We did NOT have a previous keystroke with repeated characters:

                    while (true)
                    {
                        r = Interop.Kernel32.ReadConsoleInput(InputHandle, out ir, 1, out int numEventsRead);
                        if (!r)
                        {
                            // This will fail when stdin is redirected from a file or pipe.
                            // We could theoretically call Console.Read here, but I
                            // think we might do some things incorrectly then.
                            throw new InvalidOperationException(SR.InvalidOperation_ConsoleReadKeyOnFile);
                        }

                        if (numEventsRead == 0)
                        {
                            // This can happen when there are multiple console-attached
                            // processes waiting for input, and another one is terminated
                            // while we are waiting for input.
                            //
                            // (This is "almost certainly" a bug, but behavior has been
                            // this way for a long time, so we should handle it:
                            // https://github.com/microsoft/terminal/issues/15859)
                            //
                            // (It's a rare case to have multiple console-attached
                            // processes waiting for input, but it can happen sometimes,
                            // such as when ctrl+c'ing a build process that is spawning
                            // tons of child processes--sometimes, due to the order in
                            // which processes exit, a managed shell process (like pwsh)
                            // might get back to the prompt and start trying to read input
                            // while there are still child processes getting cleaned up.)
                            //
                            // In this case, we just need to retry the read.
                            continue;
                        }

                        if (!IsReadKeyEvent(ref ir))
                        {
                            continue;
                        }

                        if (ir.keyEvent.wRepeatCount > 1)
                        {
                            ir.keyEvent.wRepeatCount--;
                            _cachedInputRecord = ir;
                        }
                        break;
                    }
                }  // we did NOT have a previous keystroke with repeated characters.
            }

            ControlKeyState state = (ControlKeyState)ir.keyEvent.dwControlKeyState;
            bool shift = (state & ControlKeyState.ShiftPressed) != 0;
            bool alt = (state & (ControlKeyState.LeftAltPressed | ControlKeyState.RightAltPressed)) != 0;
            bool control = (state & (ControlKeyState.LeftCtrlPressed | ControlKeyState.RightCtrlPressed)) != 0;

            ConsoleKeyInfo info = new ConsoleKeyInfo(ir.keyEvent.uChar, (ConsoleKey)ir.keyEvent.wVirtualKeyCode, shift, alt, control);

            if (!intercept)
                Console.Write(ir.keyEvent.uChar);
            return info;
        }

For the record, one of the comments in that code that says they might be able to use Console.Read but it might break certain things is something I happened to confirm for myself, by chance, when I was trying to do exactly that in a PoC yesterday. You end up having to call additional kernel32 functions first to make it work like one would expect if you do that, and it has high potential to be fragile if a lot of care is not taken around various contingencies. So, for windows, it's best to just KISS and use ReadConsoleInput to drain the input buffer, as that code does, when all HCI input is wanted. And I have a suspicion that this Windows Terminal issue that another comment in the code mentions (microsoft/terminal#15859) may have something to do with the odd behavior around things you raised your issue over in the dotnet/runtime repo for.
At the end of the day, the fundamentally different way that Unix and Windows treat the IO streams for TTYs[^SiouxDough] creates the precondition for the different results, and historical baggage plus trying to help perhaps a bit too much in Windows. kernel32 involves itself in the interpretations of the bytes, rather than just being a dumb pipe,[^TsuDo] making VTS the platform's responsibility, rather than the terminal emulator's responsibility, which makes things more complicated, at the lower level. Or at least that part stands out to me as a kink in the process, anyway. Ironically, unix not special-casing it ends up making life easier since it's your terminal emulator's responsibility to interpret the bytes you give to its stdout stream, and the OS just hands them to it and gets out of the way for the most part.
As I've been deep-diving into it all, I've more than once found myself wondering if allocating in-memory streams/buffers over a screen buffer equivalent[^sudo], allocating our own hosted PTY[^SueDoe], and just proxying the IO to the console the application was handed at launch might be the fix needed to make it all work consistently and more simply. But I have more research and prototyping to do to see if that's viable or even actually solves what I'm hypothesizing it would solve. But it sure would be a nice help in making a unified platform-agnostic abstraction if we could deal with all platforms using a PTY. That also makes network scenarios easier, as well, since a PTY has no requirement to be attached to the application hosting either of its streams. That, incidentally, also creates cool possibilities of things like a network driver that gives you a direct remote console to a running application on another machine, like a text-mode X sort of situation, not needing ConHost.exe or bash or whatever terminal emulator to even be in the picture.[^sudoku]
Another somewhat useful resource, but only for insight (due to incompatible LGPL-2.1 licensing) has been ReactOS, since that attempts to be a clean-room API- and ABI-compatible implementation of the Win32 APIs, from user space down to kernel space, including driver compatibility. Just sucks that LGPL-2.1 is viral and requires the entirety of a combined work using it to then also be under that license.[^boo] 😤 <--(I had a lot of trouble trying to get github to let me use that emoji)
Anyway, back to platform abstractions...
It's awesome that Windows Terminal is what it is, because work on that is forcing some attention to be paid to System.Console and related code/functionality that we're getting direct and indirect benefits from, through the changes/enhancements being made in coreclr to support it, with apparent respect and care being given to cross-platform implications of it all.
I've been watching progress at the WT repo and using it as a reference resource, as well, since obviously there's a teensy bit of relevance, there, for what we're doing.
[^SiouxDough]: Unix being simpler largely thanks to "everything is a file"
[^sudo]: e.g. using an ArrayBufferWriter<byte>
[^SueDoe]: On windows that'd be CreatePseudoConsole and on Unix it'd just be opening file streams over /dev/pty
[^TsuDo]: Well I mean you CAN use the raw file stream exclusively, if you don't care about the mouse for actual input purposes, anyway.
[^sudoku]: Though those of course would still be the majority of use cases anyway
[^boo]: Can I just say that, philosophically, I respect but strongly dislike GPL for strong-arming itself into other people's work, beyond a narrowly-defined scope of JUST the code licensed under it? BSD, MIT, and MPL for the win. That's actual freedom. Live and let live. 🥰

Another thought about something that just kinda amuses me in a way is that the code quoted above does some work that we then undo and then redo in various places. In particular, that's around modifier keys, which you can see the handling of at the bottom of the second code block (the windows version of ReadKey).
Not sure what, if any, relevance that will have as work continues, but it did stand out to me.

Quick update:
Have been continuing to research and prove things out in simple isolated toy apps for various concepts.
When I re-branch for this, I'll have some nice new tools in the toolbelt for simplifying and improving the drivers and abstractions.
But today and probably tomorrow as well, I have some other pressing work that I need to get done not related to TG.

OMG. I can log into github again! I've been back for like a week after the stuff i mentioned was finally over/completed, but was having trouble here...
Sorry. Mostly my fault, as it turns out. But it's fixed in a 3x failsafe way now. 😅
Anyway...
I'm back and will be getting myself back up to speed over the next few days, as far as work that'shaplened in the last few weeks, so I can get back to work on this.
Haven't looked over anything in my gh inbox yet, though. Just had this up toward the top and wanted to make contact so y'all know I'm alive and didn't ditch ya or something. 😅

Missed you!

@dodexahedron I have started simplifying NetDriver as part of my work adding AnsiResponseParser (see #3791 )
Hopefully that won't cause too much conflict with your work here.
I am basically

Change NetEvents to use ConcurrentQueue
Simplify read/input loops and queuing logic
Add in the AnsiResponseParser

The diff (to the main ansi branch) can be seen here:
https://github.com/tznind/gui.cs/pull/172/files

Since I backed it out to do something even cleaner in the first place than what I had previously submitted a PR for, there's no conflict, right at the moment.
But, I would suggest/recommend that you use FileStreams to the pty anyway.

It's kinda interesting.
It's a FileStream, but it feels and behaves almost exactly like a NetworkStream on top of a UDP Socket or other unordered pair of unidirectional channels. It's forward-only/non-seekable, for both input and output, and you'll receive things in the order the OS dispatched them to you, which is what you'll get any other way, but with less junk in between and fewer platform-specific idiosyncrasies to deal with.
It's one place where Windows really shows its original roots and inspiration, because the console is really two character device files that you write to and read from (called $CONIN and $CONOUT), just like Unix, where literally everything is a file. WinNT and VMS share interesting history there. There's a third virtual character device file that is r/w, called just CON, and that was a handy thing to know back in the DOS days if you didn't have a text editor available. You could copy CON somefile.txt and then anything you typed was written to that file (which could even be a printer, which is also a virtual character device file) until you gave it a ctrl-z to signal end of stream.
Fun stuff.


Move core to es2020 as well

The rest of the packages have already switched to ES2020

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/14766/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14766/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14766/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/14766/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/14766/merge
https://gui.babylonjs.com/?snapshot=refs/pull/14766/merge
https://nme.babylonjs.com/?snapshot=refs/pull/14766/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/14766/merge#BCU1XR#0

(Experimental) visualisation test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14766/merge/testResults/webgl2playwright/index.html


Feature request: Command to open coverage report in browser

It'd be handy to be able to open the lcov-report/index.html file from the command palette or via a keypress.

Thanks for submitting an issue Simon, would opening the coverage html file that is currently active be a more optimal approach? ie /vscode-coverage-gutters/example/coverage/lcov-report/example/test-coverage.js.html for this project. Also I am curious what extra information you are looking for in the html that is not provided via IDE? Are you looking for more detailed information provided by the coverage html file?

I use it to see the overall coverage percentages - the per directory coverage graphs/percentages are useful for showing where to focus test effort next.
I've got a custom location defined as "coverage-gutters.lcovname": "coverage/lcov.info" so opening the HTML report at coverage/lcov-report/index.html would do the trick

Makes sense I will take a stab at something other the weekend and get back to you later 😄
I am thinking I can even open the html in the preview inside the ide for keeping the focus in vscode rather then in a browser...
vscode.previewHtml - Render the HTML of the resource in an editor view.

uri Uri of the resource to preview.
column (optional) Column in which to preview.
label (optional) An human readable string that is used as title for the preview.
options (optional) Options for controlling webview environment.

https://code.visualstudio.com/docs/extensionAPI/vscode-api-commands

@SimonCapewell here is a sneak peek of the new preview lcov feature (opened via command, shortcut or menu) that will go out with 1.1.0 sometime early next week. Hopefully this will cover your use case and if not we can always iterate on the idea 😃
https://github.com/ryanluker/vscode-coverage-gutters/pull/80


Compilation error in cowboy_handler.erl:45: illegal pattern

Trying to compile with OTP/19 leads to the following error:
===>      Compiled cowboy_middleware.erl
===> Compiling _build/default/lib/cowboy/src/cowboy_handler.erl failed
_build/default/lib/cowboy/src/cowboy_handler.erl:45: illegal pattern
_build/default/lib/cowboy/src/cowboy_handler.erl:46: variable 'Reason' is unbound
_build/default/lib/cowboy/src/cowboy_handler.erl:47: variable 'Stacktrace' is unbound
===> Compilation failed: {error,
[["_build/default/lib/cowboy/src/cowboy_handler.erl:45: illegal pattern\n",
"_build/default/lib/cowboy/src/cowboy_handler.erl:46: variable 'Reason' is unbound\n",
"_build/default/lib/cowboy/src/cowboy_handler.erl:47: variable 'Stacktrace' is unbound\n"]],
[]}
wappler@uknown:~/development/Projects/Erlang/spawnpool$ vim _build/default/lib/cowboy/src/cowboy_handler.erl
wappler@uknown:~/development/Projects/Erlang/spawnpool$ vim _build/default/lib/cowboy/src/cowboy_handler.erl
wappler@uknown:~/development/Projects/Erlang/spawnpool$ man erl
No manual entry for erl
See 'man 7 undocumented' for help when manual pages are not available.
wappler@uknown:~/development/Projects/Erlang/spawnpool$ erl --help
Erlang/OTP 19 [erts-<IP_ADDRESS>] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [systemtap]
Eshell V<IP_ADDRESS>  (abort with ^G)
What i am doing wrong?
cheers, hristo

Support for OTP-19 was dropped in Cowboy 2.7. Current Cowboy version (future 2.8) requires OTP-22+.


Disable ceph-ansible fsid auto-generation

By default, ceph-ansible also creates a cluster fsid even when fsid is
overridden in user variables.  Commit [1] adds a new variable called
generate_fsid which, when set to false, will disable ceph-ansible's uuid
generation.
Note that leaving generate_fsid set to true does not have any effect on
the fsid we assign to the cluster, however it does create a file called
/etc/openstack_deploy/ceph_fetch/ceph_cluster_uuid.conf which does not
reflect the actual fsid of the cluster.
[1] https://github.com/ceph/ceph-ansible/commit/8e0d53e

:+1:

recheck_upgrade

@mattt416 we need an issue for this to help classify and track the work

Done @git-harry -- actual commit message does not have 'Closes ...' in it, do you want me to update?

@mattt416 yes please.

recheck_ceph

👍


Bind String resourse

Android ActionBarDrawerToggle require 2 parameters in the end which are type int and should be a string resource from R.string resource file as described on the ActionBarDrawerToggle constructor.
public ActionBarDrawerToggle(Activity activity, DrawerLayout drawerLayout,             Toolbar toolbar, @StringRes int openDrawerContentDescRes,             @StringRes int closeDrawerContentDescRes)
However when using butter knife, i used @BindString() annotation but the debugger is rising an issue :

Error:(31, 65) error: @BindString field type must be 'String'. (com.crispbrain.goestream.ui.activities.HomeActivity.navBarOpen)

I also tried with @BindInt() annotation but Butter knife complains that the resource should be of type int.
please advise.
thnx

Just pass the R.string constants directly to that method.

Thanks for the reply. That's what i did actually but it would be great if
butter knife would support this feature in the next releases.
Best luck.
On Dec 29, 2016 15:42, "Jake Wharton"<EMAIL_ADDRESS>wrote:

Just pass the R.string constants directly to that method.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/JakeWharton/butterknife/issues/833#issuecomment-269639514,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASZtpd7yOtkKX2abrqHUnEgm7TQ860X1ks5rM8bigaJpZM4LXfOs
.

Sure. Thanks for the sharp clarification.
All best luck.
On Dec 29, 2016 15:50, "Jake Wharton"<EMAIL_ADDRESS>wrote:

There's nothing to support here. Butter Knife binds resource IDs to their
values and this API wants a resource ID, not a value.
On Thu, Dec 29, 2016, 9:44 AM mohammed aouled issa <
<EMAIL_ADDRESS>wrote:

Thanks for the reply. That's what i did actually but it would be great if
butter knife would support this feature in the next releases.
Best luck.
On Dec 29, 2016 15:42, "Jake Wharton"<EMAIL_ADDRESS>wrote:

Just pass the R.string constants directly to that method.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/JakeWharton/butterknife/issues/833#issuecomment-
269639514
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/
ASZtpd7yOtkKX2abrqHUnEgm7TQ860X1ks5rM8bigaJpZM4LXfOs
.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<https://github.com/JakeWharton/butterknife/issues/833#issuecomment-
269639782>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAEEEfYbQjIn7MuPbJboBVqrjQQEJx5Zks5rM8dXgaJpZM4LXfOs>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/JakeWharton/butterknife/issues/833#issuecomment-269640472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASZtpcSUhPjIKhl0zLAdYa4pK4hUWxCvks5rM8imgaJpZM4LXfOs
.


Cannot fetch userinfo with current token

Could not request userinfo with kct. It seems that scope openid missing when trying to request userinfo.
It will even not sent the request.
tom@neumann ~/bin
$ kct token --context=acme-internal-http-test-client-ropc --decode
{
"exp" :<PHONE_NUMBER>,
"iat" :<PHONE_NUMBER>,
"jti" : "282fe846-6538-4dc7-b531-41e8a850ac18",
"iss" : "http://id.acme.test:8080/auth/realms/acme-internal",
"sub" : "376ecd89-db04-4bcb-9e20-f4e0662d1407",
"typ" : "Bearer",
"azp" : "test-client-ropc",
"sid" : "f2a00842-d786-409e-8c35-e24532faf856",
"scope" : "profile email",
"email_verified" : true,
"name" : "Theo Tester",
"preferred_username" : "tester",
"given_name" : "Theo",
"locale" : "en",
"family_name" : "Tester",
"picture" : "https://en.gravatar.com/userimage/52342809/a957ac868585f91edf7eb9b7463328b9.jpeg?size=64",
"email" : "tester@local"
}

tom@neumann ~/bin
$ kct userinfo --context=acme-internal-http-test-client-ropc --scope="profile email"
Requested scopes must be a subset of configured scopes

It doesn't request oidc scope by default. When creating a context if you want it to be an oidc request, then just add scope=oidc.
Maybe could be better explained in docs, or a better error message.

It needs the openid scope and it adds that if missing. However, the problem is that the scope passed to commands needs to be a subset of the configured scopes for the context. It should just complain instead of trying to add the scope automatically.


Breaks with the release candidate of flutter

Currently I have developed against the Beta release branch as that is the latest "stable". I presume you are referring to the development branch. Since flutter as a whole is not at v1, it is likely there will be API changes that break implementation.  With the level of changes the dev branch undergoes on a daily basis, I would not be able to offer support for that at this point in time.

Very understandable. I added the request because I am using your library as I think it is excellent, and as it is I keep getting warnings from flutter how outdated my flutter install is.
Dev seems much more stable than master though, and the flutter team recommends using it. Master is the one that is constantly updated and breaking.
The only problem when upgrading seems to be that there is a notch property that changed.

I could look at a Dev branch that targets the Dev branch of flutter. Would be a bit more overhead but if it adds value to people I could do it. Would be more prone to breaking as flutters dev branch is in flux. Would you think it be worth it?

Another option would be to Fork and make changes locally at your end. Then you can git reference the project in the pubspec. You could then PR back into my dev branch if others want it.

Ok, let me check if I can fork and fix it on my end then.

I'm having trouble uploading my fix branch for some reason... However the fix is very simple, a property has been removed:
in platform_nav_bar.dart:104, remove this line:
hasNotch: data?.hasNotch ?? true,
And all seems well. I think it is also save to remove from the master, since it seems the property is optional anyway.

This error is happening on my end too, this is on the master branch of flutter. Note that now the beta channel of flutter is now 579 commits behind the master channel of flutter, so updating this seems necessary at this point.

I have Published version 0.3.0 to remove the hasNotch property. Please check if this is a-ok

@aqwert works well! Thank you.


3.12.0 - gpg: Can't check signature: No public key` installing Python feature

When building a dev container using the Python feature using the devcontainer.json below, I get the error gpg: Can't check signature: No public key
{
	"name": "dc-python-tmp",
	"image": "mcr.microsoft.com/vscode/devcontainers/base:0-ubuntu-22.04",
	"remoteUser": "vscode",
	"features": {
		"ghcr.io/devcontainers/features/python:1": {
			"version": "latest"
		}
	}
}

The dev container builds successfully for me if version is omitted or set to 3.11 but fails for latest and 3.12

Thanks for opening the issue, opened https://github.com/devcontainers/features/pull/726 with the fix!

Closing as fixed with https://github.com/devcontainers/features/pull/726 🚀


Increase max_user_watches

this should be set on the host, a note will be added to the documentation.
src: https://stackoverflow.com/a/57221024


Add reusable default authentication failure handler

partially addresses gh-1369

@jgrandja -- addressed the PR review issues. Let me know if there are anymore changes needed.

Thanks for the updates @ddubson. This is now merged.
FYI, I added a polish commit. Let me know if you have any questions.


Does netopeer2 not trigger Sysrepo operational callbacks on get?

Hi, I am having some trouble getting a Sysrepo plugin to work with Netopeer2. I am posting this here because the Sysrepo part seems to work fine, it just doesn't work with Netopeer2.
So, I have a normal operational subscription on a certain subtree of the ietf-ptp model. Using sysrepocfg -X -m ietf-ptp -d operational triggers the callback correctly and everything is fine. Then, I set up the Netopeer2 server, perform  get --filter-xpath "/ietf-ptp:ptp" with netopeer2-cli and the callback doesn't trigger, so no operational data is returned (using a more precise filter doesn't work either). Running an edit-config on the running datastore triggers the callback for my change subscription so I guess the plugin is working OK.

That is definitely strange, what exactly is the subtree you are subscribing for? Do you have any running data for this module?

Hey, thanks for the quick answer.
So, my operational subscription is done like this:
rc = sr_oper_get_items_subscribe(
        session, "ietf-ptp", "/ietf-ptp:ptp/instance-list/current-ds",
        ptp_current_ds_oper_cb, NULL, SR_SUBSCR_CTX_REUSE, &subscription);

And yes, I have this data on the running datastore:
<ptp xmlns="urn:ietf:params:xml:ns:yang:ietf-ptp">
  <instance-list>
    <instance-number>0</instance-number>
  </instance-list>
</ptp>

The operational callback is supposed to provide the data from the current-ds container for the instance 0 shown.

Forgot to ask, what sysrepo/netopeer2 versions are you using?

I am using the latest version available on master on both repos. I have just read in the README of this repo that I should use devel if a bug is found, so I will try this this afternoon if I have time. Should I also try devel version of Sysrepo?

Never use a project from one branch and any of its dependencies from another, so yes, please try it on devel for all libyang, sysrepo, libnetconf2, and netopeer2. If you still have the problem, I will try to reproduce it locally.

Hey, so I just installed devel versions of all components and tried again with no success. Same thing happens. This is the plugin's repo. Let me know if you try to reproduce it and need any help getting it to run.

Before I get to reproducing it, have you tried it when connecting to netopeer2 as root? So that you bypass NACM because that can easily be the problem, if you do not have access to the running data, there is no list instance and so calling this oper data callback would be redundant and is skipped.

Yes, I have connected to the netopeer2 server using netopeer2-cli and connect --login root. It doesn´t trigger the callback either.

Right, I had to try it myself to understand. It all comes to the NMDA spec, second bullet. In short, the data your operational callback is providing are not part of the data returned by <get> because they are config true operational data. If you want to get it, use <get-data> instead.

Huh, you are right. I missed that, my bad. It is working correctly with get-data. Thanks for your help @michalvasko, I am closing the issue now.


test, and document creator feature

the -c/--creator feature is not well documented; we only describe what it is, but there are no runnable examples. also, I quickly look at the code and seems that we don't have any unit tests.
based on this, looks like creator is passed to sqlalchemy to initialize a connection. this feature sounds very similar to the one we added recently for connecting to existing engines. I think we should keep both to remain 100% compatible with ipython-sql  but recommend users switch to the new feature.

for context: https://github.com/ploomber/jupysql/issues/128


AMD Ryzen 5 Pro 4650U with kernel 4.19

Hi,
We are trying to get X working on a Lenovo L15 system which has AMD Ryzen 5 Pro 4650U with Radeon Graphics.
The kernel version is 4.19
Output of lspci is;
VGA Compatible controller. Advanced Micro Devices inc. (AMD/ATI) Renoir (rev d3)
We do not need all the functionality, just basic graphics will be fine.
Xorg log file;
Xorg.0.log
Regards,
Aydin

@paykocaydin This is not related with AMDVLK. You may need to upgrade kernel and ddx driver to newer version

"open /dev/dri/card0: No such file or directory" indicates that the kernel mode driver is not loaded, you can check it with "lsmod | grep amdgpu"? If it's not loaded, you can check what's going on with "dmesg"?

Hi,
lsmod | grep amdgpu produced nothing. So it is not loaded.
dmesg also shows nothing about amdgpu, not even an error message.
As far as i know the kernel that i am working on (4.19) does not support
this GPU.
I have learned that kernels from 5.3 have support.
So does this mean that the driver have to be backported to this kernel in
order to work.
If i am correct i can use framebuffer device to use graphics even my video
card is not supported.
Is that correct? Kernel has framebuffer enabled.
If yes can you please point me to a document on how to do this.
I do not need all the features, just basic X will be enough.
Many thanks for your time.
Aydin
On Mon, 7 Sep 2020 at 10:20, Jacob He<EMAIL_ADDRESS>wrote:

"open /dev/dri/card0: No such file or directory" indicates that the kernel
mode driver is not loaded, you can check it with "lsmod | grep amdgpu"? If
it's not loaded, you can check what's going on with "dmesg"?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GPUOpen-Drivers/AMDVLK/issues/184#issuecomment-688094799,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALDSWIXI2BOD2JEOSWEKC2LSESCSNANCNFSM4Q42SIGA
.


Handle CSP violations in PAL components

Ensure PAL components are CSP complaint.

[ ] Include the respective component name in the forbid configuration inside package.json
[ ] Run yarn lint and fix the errors
[ ] Replace style={{}} usage with classNames where appropriate
[ ] Set dynamic styles using useIsomorphicEffect()

@matthewgallo @amal-k-joy Do we think it make more sense to address CSP issues for individual components or address them in one larger PR for a quicker resolution (but at the risk of more conflicts with other PRs).
It does look like when the System team addressed these, it was mostly within one larger PR. Might still be worth breaking out some of the components if the fixes are more involved, but my feeling is that  most might be able to be addressed in one go.
I think we can also exclude examples, **.stories.js, **.story.js, **.test.js, thumbnails/**.svg and probably mdx/docs-page as well. (Did I miss any?)
SVG might still be better to address a bit separately since it sounded like the fix for it might be more involved.

Seeing ~34 files with the following exclusions:
src/**/**/**.stories.jsx, src/**/**/**.story.jsx, thumbnails/**.svg, examples/**, packages/core/*, **.test.js

I suggest we group the remaining fixes this way —

Carousel.tsx
~Checklist.mdx~
ChecklistChart.js
Coachmark.tsx
CoachmarkOverlay.tsx

--

~Datagrid.mdx~
DatagridExpandedRow.tsx
DatagridRow
DatagridVirtualBody.tsx
DraggableElement.tsx
~Datagrid/Datagrid.stories/common.js~
~Filtering.docs-page.js~
DatagridActions.js
~utils/Wrapper.js~

--

DataSpreadsheetBody.tsx
DataSpreadsheetHeader.tsx
NotificationPanel.tsx
PageHeader.tsx
TearsheetShell.tsx

--

ScrollGradient.js
StringFormatter.js
TruncatedList.tsx
WebTerminal.tsx

--

~DragAndDrop/preview-components/GridContainer.js~
~DragAndDrop/preview-components/Item.js~
~DragAndDrop/preview-components/Sortable.js~
~DragAndDrop/preview-components/SortableItem.js~
~DragAndDrop/preview-components/Underlay.js~
~ExampleComponent.js~
~FullPageError/preview-components/UiShell.js~
~StoryDocsPage.js~

Please can NoDataEmptyState be added to the list please?
I've noticed this component has inline style blocks

@tom-youd I believe this was covered in our SVG updates. Based on when the PR was merged, it should be included in our next release candidate (Monday, Oct 28^1).


adding 'f' and 't' key codes to keydown trigger

Hoping to add f and t key codes to keydown. trigger method. These two keys are used in media player apps, like YouTube, to trigger full screen and theater mode features. Also updated the docs with the key codes.

Thankyou for the PR, but I think it would be strange to just add f and t keys, and I don't think we should add modifiers for all keys


Bug: deleting a block decorator node (divider) causes loss of selection

Lexical version: 0.7.6
Steps To Reproduce

Replicate the steps in the video below.

https://user-images.githubusercontent.com/8862967/211872809-710dac40-28d9-4b64-8204-fba40ae97078.mp4
The current behavior
After deleting, the selection is lost.
The expected behavior
After deleting, there is still a selection where it makes sense.

@DaniGuardiola A lil off topic, but could you tell me the screen shot app you used to generate the keystrokes? I have a reproducible bug for Lexical which I couldn't explain but I think this tool will make this clear in the issues!

@gaurav21r it's screenkey: https://www.thregr.org/~wavexx/software/screenkey/

@DaniGuardiola Thank you so much ❤ I think it is Linux only?

Can't reproduce with current lexical


Multicursor bug in html files

Issue Type: Bug
Open any html file. Put cursor on a tag. Observe multicusror becomes active. From now on you cant do any selection.
Now move the cursor to the end of the tag. Observe cursor starts blinking, Ln X, Col Y in right bottom corner goes crazy cause cursor position gets changed all the time as far as I understand. Also 2 of the renderer processes start consuming 100% of the CPU.
This is reproducible with all extensions disabled and does not happen in stable version.
https://youtu.be/Piat_U2iOZs
VS Code version: Code - Insiders 1.41.0-insider (7cf4cca47aa025a590fc939af54932042302be63, 2019-12-02T05:26:29.458Z)
OS version: Darwin x64 19.0.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz (8 x 2300)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 3

Memory (System)
16.00GB (0.13GB free)

Process Argv
-psn_0_10521096

Screen Reader
no

VM
0%

Extensions (19)

Extension
Author (truncated)
Version

Bookmarks
ale
10.6.0

project-manager
ale
10.9.1

vscode-eslint
dba
1.9.1

gitlens
eam
10.2.0

EditorConfig
Edi
0.14.2

vscode-todo-plus
fab
4.14.1

vscode-pull-request-github
Git
0.13.0

rainbow-csv
mec
1.3.1

dotenv
mik
1.0.1

debugger-for-chrome
msj
4.12.2

vscode-sort-json
ric
1.18.0

code-settings-sync
Sha
3.4.3

code-spell-checker
str
1.7.20

sort-lines
Tyr
1.9.0

vscodeintellicode
Vis
1.2.0

vscode-icons
vsc
9.6.0

vim
vsc
1.11.3

local-history
xyz
1.7.0

markdown-all-in-one
yzh
2.5.1

(1 theme extensions excluded)

@ivanvoznyakovsky video is private, so can't see behavior (probably should be changed to owners of direct link).
From description it looks related to #47069 tagging @octref

Duplicate of #85715.

@IllusionMH made the video public. old habit 😄 and yes, #85715 looks like the same bug.


sound bug

Does the issue occur with only Immersive Portals mod and Farbic API? (Backup the world before testing this.)
No
What happened?
after creating a portal, entering, then leaving and walking away, i can hear these invisible pigmen near me. it also happens with other nether npcs and entities.
Post the log here
No response

You said that this issue does not occur with only immptl, so it's a compatibility issue, please find which exact mod it's incompatible with.

Updated the issue template to make it clear. It does not ask whether you are using other mods. I need you to test whether this issue occur without other mods.

Are you using dimension stack?


text/plain support

The emails alert manager generate seem to be Content-Type: text/html; charset=UTF-8 only.
A plain text counterpart would be handy on less capable MUAs.
https://s.natalian.org/2016-12-09/1481247762_1534x1404.png

Yes, that would definitely be valuable. Actually we have a tracking issue for multipart emails in #290. So I'll close here as it's a duplicate.


Gh-2201: Add support for Accumulo 2 while retaining Accumulo 1

This make Gaffer compatible with Accumulo 2 and retains support for Accumulo 1.
Uses a utility class to dynamically import Accumulo classes which are incompatible between versions 1 & 2, plus handles creation of certain objects associated with these classes. Gaffer can be built for Accumulo 1 and Hadoop 2 using a 'classic' profile which swaps dependency versions. Other minor POM changes were required to ensure compatibility for existing libraries.
Related Issue

Resolve #2201

Codecov Report

:exclamation: No coverage uploaded for pull request base (v2-alpha@e8cbead). Click here to learn what that means.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             v2-alpha    #2679   +/-   ##
===========================================
  Coverage            ?   73.62%
  Complexity          ?      228
===========================================
  Files               ?       19
  Lines               ?      728
  Branches            ?       57
===========================================
  Hits                ?      536
  Misses              ?      143
  Partials            ?       49

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e8cbead...0a87df4. Read the comment docs.


⚠ Bofrost.lu has degraded performance

In 64b8b21, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2320 ms

Resolved: Bofrost.lu performance has improved in e25957d after 20 minutes.


Is it possible for only some of the commands in a batch to execute?

If I am doing a batch with Execution Mode : REDIS_WRITE_ATOMIC,
Is it possible for my batch to fail halfway, and have only made half the changes for example? Or if it fails in the middle will all of the changes be undone?

Is it possible for my batch to fail halfway, and have only made half the changes for example? Or if it fails in the middle will all of the changes be undone?

No, it's not supported by Redis batch.


Add unit testing for session commands

Commands have been added for unit testing global commands. Add tests for unit-testing session commands.

Issue is invalid because of rewrite. Closed.


Crash on startup when USB keyboard is connected

Hyprland Version
Hyprland, built from branch  at commit v0.30.0  ().
Bug or Regression?
Bug
Description
When logging in when I have USB keyboard connected without fail hyprland instantly crashes.
When I first login and then reconnect my keyboard it works.
I'm running hyprland on apply silicon with nixos
How to reproduce
Have USB keyboard connected
Crash reports, logs, images, videos
hyprlandCrashReport1474.txt

doesn't look like related to your keyboard. wlroots can't find a GPU. Issue on your side.

Any idea how I can debug this further?
If I manually start Hyprland from a terminal entered with ctrl+alt+f3 it works fine.

then it's your login manager's fault most likely. Ask those people


Clean up/delete feature branches

Delete the feature branches that were merged into the code or are no longer relevant. If the branch is still active, please update the name of the branch using the feature branch naming convention,  <initials>/<issue#>-<short description> .

[ ] ArcGIS_Pro_1.2
[x] csm/dark-icons
[x] csm/favorite-to-feature-template2.0
[x] csm/favorite-to-template
[x] csm/update-to-prosdk2.0
[x] csm/#168-flipped-export-image
[x] lw-jenkinsPro2.0-test
[x] pro-sdk-2.0
[ ] v2.0
[ ] v2.1

Deleted the ones I could - this branch is locked so requires repo Admin rights to delete:
ArcGIS_Pro_1.2
These are the version/release maintenance branches created as part of the release process so should remain:
v2.0
v2.1

Verified. Closing.