Seems fine. ACTIVATE_SH is still in there on the version I have on my Debian Testing machine (15.1.0+ds-3 according to the dpkg system, 15.1.0 according to virtualenv.version). Not sure when it was removed, but it's not really relevant. :)

In D9023#135215, @marmoute wrote:

Did you measure the performance impact on other operation than your target operation ? I am curious about the impact of the @property here.

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.)