In D8281#124247, @martinvonz wrote:

In D8281#124246, @spectral wrote:

• Server emits a new capability narrow-exp-1-escaped (in addition to the current narrow-exp-1, this is not replacing the existing capability)

nit: I *think* the "1" in the name was supposed to be a version number, so the new capability's name would be narrow-exp-2.

In D8281#124129, @durin42 wrote:

In D8281#124058, @marmoute wrote:

Since narrow is still experimental, I don't think we should try too hard for backward compatibility. We could introduce a new end-point for a new encoding and drop the old one in a couple of version.

+0, honestly. I won't require it, but I'd really rather we shaved this yak _now_ rather than when narrow has even more users.

In D8280#123642, @marmoute wrote:

Should we try to move to some automatic detection of file with doctest? That would be more reliable.

In D8281#123621, @mharbison72 wrote:

The Windows path changes seem like a good idea.
Would quoting paths with commas eliminate the need for custom escaping? I don't feel strongly about it, but custom escaping always feels weird to me. (I fact, a coworker did some homebrew escaping for CSV files a few days ago, but I forget how it ultimately ended up.)

We decided to use a different method to resolve this issue.

In D8039#118719, @yuja wrote:

What do you think about this approach:
1. The server detects that LC_TYPE is coerced.
2. When handling the "validate" command, the server sends back "invalidate this server, and fallback to original hg" response.
This makes chg/non-chg behave consistently with some startup overhead in mis-configured environment. The chg client can potentially print a warning to remind the user to fix their environment.

That could be, but if we do want to make chg/hg behavior consistent, maybe we
can adjust the hash computation logic?

1. client sends CHG_ORIG_LC_CTYPE or CHG_UNSET_LC_CTYPE when spawning server
2. they're kept in environ dict, but override LC_CTYPE while computing hash, and excluded from the hash
3. client does not send these variables over setenv command, but passes the validation because {CHG_ORIG_LC_CTYPE: x, LC_CTYPE: y} == {LC_CTYPE: x}.

I'll see how easy that is to implement and send a separate review request once I have it working.

In D8022#118428, @yuja wrote:

This would cause a difference in behavior between hg and chg. I don't know how big of an issue that would be.
hg: starts up, python coerces LC_CTYPE, hg spawns a non-python subprocess, LC_CTYPE is set to the coerced value
chg: starts up, python coerces LC_CTYPE, chg fixes it, hg spawns a non-python subprocess, LC_CTYPE is set to the original value (or unset).

I think a minor behavior difference is acceptable. I see this is the problem
of Python 3 design "the world is unicode", and IMHO we want to work around
the problem with minimal changes.

I prefer passing in (const char**)environ to hgc_setenv().

In D8022#118325, @yuja wrote:

Another idea. How about sending the true LC_CTYPE value as a command
argument so the env mangling can be reverted?

1. spawn hg serve --cmdserver chgunix ... with --daemon-postexec setenv:LC_CTYPE=$LC_CTYPE
2. runservice() overwrites LC_CTYPE to the specified value (undo coercing)
3. chgserver hashes the restored environ

Since the "coercing" is 100% useless for Mercurial, restoring LC_CTYPE
should be perfectly fine. And unlike setting PYTHONCOERCECLOCALE=0,
Python subprocesses can still see its own "coercing" results for better
or worse.