For custom pretty-printers, the long-term plan is to make the watch expression language rich enough that you can just write one-liners in the watches window to pretty-print your struct. E.g. `for entry in my_hashmap.entries_ptr.[my_hashmap.num_entries] { if entry.has_value { yield struct {key: &entry.key, value: &entry.value}; } }`. Then allow loading a collection of such printers from a file; I guess each pretty-printer would have a regex of type names for which to use it (e.g. `std:.*:unordered_(multi)?(set|map)`). There are not very many containers in standard libraries (like, 10-20?), and hopefully most of their pretty-printers can be trivial one-liners, so they would be easy enough to add and maintain that incompatibility with other debuggers wouldn't be a big concern. Currently nnd doesn't have anything like that (e.g. there are no loops in the watch expression language), I don't have a good design for the language yet, not sure if I'll ever get around to it.

(Btw, "pretty-printers" is not a good name for what I'm talking about; rather, it transforms a value into another value, e.g. an std::vector into a slice, or an unordered_map into an array of pairs, which is then printed using a normal non-customizable printer. The transformed value ~fully replaces the original value, so you can e.g. do array indexing on std::vector as if it was a slice: `v[42]`. This seems like a better way to do it than a literal pretty-printer that outputs a string.)

What kind of cooperation from library authors would help with container recognition... The current recognizers are just looking for fields begin/end (pointers) or data/len (pointer and number), etc (see src/pretty.rs, though it's not very good code). So just use those names for fields and it should work :) . I'm not sure any more formal/bureaucratic contract is needed. But it would be easy for the recognizer to also check e.g. typedefs inside the struct (I guess most languages have something that translates to typedefs in debug info? at least C++ and Rust do). E.g. maybe a convention would say that if `typedef int THIS_IS_A_VECTOR` is present inside the struct then the struct should be shown as a vector even if it has additional unrecognized fields apart from begin/end/[capacity]; or `typedef int THIS_IS_NOT_A_CONTAINER` would make the debugger show the struct plainly even if has begin+end and nothing else. That's just off the top of my head, I haven't thought in the direction of adding markup to the code.

A maintained collection of recognizers (in some new declarative language?) for containers in various versions of various libraries sure sounds nice at least in theory (then maybe I wouldn't've needed to do all the terrible things that I did in `src/pretty.rs`). But I don't want to maintain such a thing myself, and don't have useful thoughts on how to go about doing it. Except maybe this: nnd got a lot of mileage from very loose duck-typed matching; it doesn't just look for fields "begin" and "end", it also (1) strips field names to remove common suffixes and prefixes: "_M_begin_", "__begin_", "c_begin" are all matched as "begin", (2) unwraps struct if it has just one field: `foo._M_t._M_head_impl._M_whatever_other_nonsense._M_actual_data` becomes just `foo._M_actual_data`; this transformation alone is enough to remove the need for any custom pretty-printer for std::unique_ptr - it just unwraps into a plain pointer automatically. Tricks like this cut down the number of different recognizers required by a large factor, but maybe would occasionally produce false positives ("pretty-print" something that's not a container).

(Dump of thoughts about the expression language, probably not very readable: The maximally ambitious version of the language would have something like: (1) compile to bytecode or machine code for fast conditional breakpoints, (2) be able to inject the expression bytecode+interpreter (or machine code) into the debuggee for super fast conditional breakpoints, and maybe for debuggee function calls along the way, (3) have two address spaces: debuggee memory and script memory, with pointers tagged with address space id either at runtime or at compile time, ideally both (at compile time for good typechecking and error messages, at runtime for being able to do something like `let elem = if container.empty {&dummy_element} else {container.start}`; or maybe the latter is not important in practice, and the address space id should just be part of the pointer type? idk; I guess the correct way to do it is to write lots of pretty-printers for real containers in an imaginary language and see what comes up), (4) some kind of template functions for pretty-printing, (5) templates not only by type, but also maybe by address space, by whether the value's address is known (e.g. a debuggee variable may live on the stack at one point in the program and in register in another part), by variable locations if they're compiled into the bytecode (e.g. same as in the previous pair of parentheses), (6) use the same type system for the scripting language and the debugged program's types, but without RAII etc (e.g. the script would be able to create an std::vector and assign its fields, but it would be a "dead" version of the struct, with no constructor and destructor), (7) but there's at least one simplification: the script is always short-lived, so script memory allocations can just use an arena and never deallocate, so the language doesn't need RAII, GC, or even defer, just malloc. The design space of languages with multiple address spaces and tagged pointers doesn't seem very explored, at least by me (should look for prior art), so it'll take a bunch of thinking and rewriting. Probably the maximally ambitious version is too complex, and it's better to choose some simpler set of requirements, but it's not clear which one. If you somehow understood any of that and have thoughts, lmk :) )

* Mach APIs instead of ptrace (probably a lot of changes).

* Mach-O instead of ELF.

* Some other APIs instead of /proc/<pid>/{maps,stat,...}

* Probably arm in addition to x86?

* Dealing with security stuff.

* Probably lots of other small differences everywhere.

Limiting the scope to one OS and CPU arhitecture was a big part of how I was able to make a usable debugger in a reasonable time.

You don't have to make a GUI with any of those.

Linux may not be so pretty, but it's far more comfortable.