One other thing: you will need to squash your commits and retitle them per the contribution guidelines, as we use conventional commits. This would be something like docs: Update troubleshooting guide for editors without wait modes (that’s probably longer than 50 characters, which is the typical max length for the message).

This is a valuable addition, but I personally have a few issues with it at the moment.

1. You're intermingling the concept (using an intermediate script which invokes an $EDITOR in a manner that provides wait functionality) with the example. I think it would be better to explain the concept first, as generally as possible, and then provide an example.
2. The section title is "Any editor", but the solution contained within uses a Bash-specific built-in. Obviously, this requires Bash, so it excludes all (non-WSL + Bash) Windows users at a minimum. Perhaps something like "Background-only editors" would be better? Note that I am terrible at naming things.
3. The example mentions editing chezmoi.toml. I understand why this was done, but I feel it is unnecessarily specific, and could potentially leave a user with the impression that the solution would only work if their config file is in the TOML format, or lead them to create a chezmoi.toml file even if they already have an existing config in a different format. I would instead simply replace this with something like "Set the edit.command configuration variable to the new shell script", and then provide the example in TOML if needed.

Explaining the concept separately from the example would also allow us to add examples in the future (using different commands, using different shells/platforms etc.) if needed. I wouldn't be surprised if there was an equivalent cross-platform Go/Rust tool for this somewhere.

+1 to @halostatue's points regarding commits/message. We use the conventional commit categories to exclude all of the non-user-facing/miscellaneous changes from the changelog when a new release is cut.

This is a valuable addition, but I personally have a few issues with it at the moment.

1. You're intermingling the concept (using an intermediate script which invokes an `$EDITOR` in a manner that provides wait functionality) with the example. I think it would be better to explain the concept first, as generally as possible, and then provide an example.

2. The section title is "Any editor", but the solution contained within uses a Bash-specific built-in. Obviously, this requires Bash, so it excludes all (non-WSL + Bash) Windows users at a minimum. Perhaps something like "Background-only editors" would be better? Note that I am terrible at naming things.

3. The example mentions editing `chezmoi.toml`. I understand why this was done, but I feel it is unnecessarily specific, and _could potentially_ leave a user with the impression that the solution would only work if their config file is in the TOML format, or lead them to create a `chezmoi.toml` file even if they already have an existing config in a different format. I would instead simply replace this with something like "Set the `edit.command` configuration variable to the new shell script", and then provide the example in TOML if needed.

Explaining the concept separately from the example would also allow us to add examples in the future (using different commands, using different shells/platforms etc.) if needed. I wouldn't be surprised if there was an equivalent cross-platform Go/Rust tool for this somewhere.

+1 to @halostatue's points regarding commits/message. We use the conventional commit categories to exclude all of the non-user-facing/miscellaneous changes from the changelog when a new release is cut.

@bradenhilton All valid points, but... I only saw your update after it was already approved and I made the squash and stuff... So maybe a follow-up docu update (through separate PR) would be more convenient at the moment? So perhaps the addition currently has a grade of 7 out of 10 and everyone is, of course, free to make it a 9 out of 10.

Anyway, my main objective with this PR was to get an 'I build my own workflow'-vibe going with the intended reader, so to never limit oneself to a single tool but combine software and make it work for you. I also always prefer actual working examples to an abstraction any time of the week, so I think the aim for at least this piece of documentation should be to help people along and not try to please everyone (it is behind a 'tab', right 😅).