Jorengarenar

Yeah, we didn't copy that one over precisely because it was kind of a blocker to introducing replacements for outdated design.

But I think it can be weaseled into that principle. Thanks!

I mean...

> Six years after the start of the Second Generation, a new generation of consoles appeared (...) For reasons that are not entirely clear, they are considered part of the Second Generation.

As well as in last paragraph:

> (...) ‘What to call this so-called “Lost Generation?’” Should it be renamed to the Third Generation, and the Third to the Fourth and so forth? That would be confusing. While I like the term “Lost Generation,” and it lends well to how these machines were (...) doomed by the console market crash, (...) I suggest calling it the 2.5 Generation; this avoids any renaming and places it in the correct chronological order.

>the premise is sort of flawed.

>The author says that the 3rd gen of consoles really begins with the NES, and so these early 1980s consoles can't belong to the 3rd generation.

Rather than the author, I would say that it's everybody else - a general consensus - making that claim.

>So I think it makes more sense to say that the 3rd generation begins in 1982/1983 with the Colecovision and Atari 5200.

I think is precisely the premise of this article - to show that those systems, had it not been for a crash of 1983, would have been categorized as early 3rd gens instead of late 2nd gens and to give a way to somewhat correct the mistake by calling them "generation 2.5"

> vim predates the fashion for dark backgrounds,

If anything, the correct version of this statement would be "Vim was created when light backgrounds were a fad".

The "natural" background of the terminal is dark, including ADM-3A (terminal "responsible" of vi's HJKL).

> This is still the case in C11, Section 5.2.4.1. Did this change in the most recent standard?

Well, no, it's still marked "just" obsolete. For it to be deprecated or removed there would need to be anybody caring about it enough to put some work. But since it doesn't affect vendors at all (they can just ignore) and users don't complain, it's just a forgotten "law" - still law, but a dead one.

> I was thinking more like the file-local namespace clobbering offered by Python e.g., from LIBNAME import actual_function_name.

Oh, that's... way more than just namespaces. Way more. That would require more fundamental changes and additions. C++ just added modules in C++20 (not sure how well those will catch on), but I don't think something like that is to be expected in C for feasible future.

@1: The limits are considered obsolete since C89 and implementations are encouraged to avoid them whenever possible. I think the same way we disregard non ASCII character sets, non two's complement encodings and similar, we are safe in assuming sane implementation being able to handle longer names. And being honest, if given implementation isn't capable of more than 31 significant characters, then it would have problems with namespaces too.

@2: Agree, although I don't recall this ever happening to me.

@3: Is it? How is libname::actual_function_name() much better?

I actually like to use libname__actual_function_name(), as it further separates "namespace" from function name (unless we need compatibility with C++, as IIRC it reserves all double underscores, not only at the beginning).

Only handful of Vim plugins have dependencies and even then you need to install them explicitly

Liking to have clean and empty inbox isn't related to limited memory

LIBNAME_actual_function_name()