On 7/24/2022 2:47 AM, Eli Zaretskii wrote: >> From: Jim Porter >> Cc: larsi@gnus.org, 56025@debbugs.gnu.org >> Date: Sat, 23 Jul 2022 22:29:28 -0700 >> >> -@defun process-tty-name process >> +@defun process-tty-name process &optional stream >> This function returns the terminal name that @var{process} is using for >> its communication with Emacs---or @code{nil} if it is using pipes >> instead of a pty (see @code{process-connection-type} in >> -@ref{Asynchronous Processes}). If @var{process} represents a program >> -running on a remote host, the terminal name used by that program on >> -the remote host is provided as process property @code{remote-tty}. If >> -@var{process} represents a network, serial, or pipe connection, the >> -value is @code{nil}. >> +@ref{Asynchronous Processes}). If @var{stream} is one of @code{stdin}, >> +@code{stdout}, or @code{stderr}, this function returns the terminal >> +name (or @code{nil}, as above) that @var{process} uses for that stream >> +specifically. You can use this to determine whether a particular >> +stream uses a pipe or a pty. > > This text doesn't tell what happens if STREAM is nil or omitted. Ok, I expanded this to clarify things. (Same for the docstring.) Hopefully that provides enough detail. I tried to explain the behavior without going overly in-depth and explaining all the implementation details of how PTYs get set up. Let me know if it needs any further tweaks. >> +If @var{process} represents a program running on a remote host, the >> +terminal name used by that program on the remote host is provided as >> +process property @code{remote-tty}. If @var{process} represents a >> +network, serial, or pipe connection, the value is @code{nil}. > > If the previous paragraph is only for local subprocesses, the text > there should say so. I've added an explanation of what (I think) this means for remote processes: `process-tty-name' returns the name of the local TTY (so, the TTY used by ssh, for example), whereas the `remote-tty' property returns the name of, well... the remote TTY. I'm pretty sure that's what the behavior is at least, based on my reading of the code. On 7/24/2022 2:48 AM, Eli Zaretskii wrote: >> From: Lars Ingebrigtsen >> >> Since this (mainly) affects Cygwin builds, could someone who uses >> Windows give the patch a look-over and apply it? > > I did the review and tested on native MS-Windows, but I think we > should wait for Ken to try this on Cygwin. I tested the v4 patch on Cygwin (and GNU/Linux) and all the new tests I added passed. Ken also tested patch v2 and things worked.