> I've gone so far as to keep my config directory visible -- ~/.config is a symlink to ~/config, which actually holds all my config, conveniently a git repository in itself for easy portability and tracking.

Sometimes I wonder how much defaulting to a directory with a leading dot hurt adoption. It gave me the impression that it was designed for or by people who don't manually edit their config files.

It's not defaulting to a directory, but to a variable: "$XDG_CONFIG_HOME".

Also, if you know how to change config of an application for the last 15-16 years, you also know that you're going to edit a "dot file".

KDE stored everything under ".kde" for a long long time, and stored a great tree under it too. rc files as config files and other KDE related files as app specific files.

In fact, the ".config" folder is just an evolution of ".kde" folder. Spec is written by KDE guys.

> It's not defaulting to a directory, but to a variable: "$XDG_CONFIG_HOME".

By default I'm referring to the following part of the spec and the fact that systems I've used start in this state:

> If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

I did not understand the banner until I read your comment.

I read the banner and thought "of course this is user created content; that's typical of a wiki. I wonder what separates their 'official' wiki pages."

> emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands

I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess.

VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it.

From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit.

It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.

If I understand correctly, each `authzPB` collected in the iteration stores references to fields of an `authzModel`. Before the patch, these were identical, referring to the fields of the loop variable v. Each iteration of the loop, v is set, and all those stored references pointed to the new value.

Rust does give a compilation error for that.

That makes sense.