From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: standard output/error/input streams Date: Sat, 14 Jan 2017 16:31:54 +0200 Message-ID: <838tqdbtlx.fsf@gnu.org> References: <87wpdxu8yt.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1484404356 10300 195.159.176.226 (14 Jan 2017 14:32:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2017 14:32:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 14 15:32:31 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cSPNa-0001U8-DB for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2017 15:32:26 +0100 Original-Received: from localhost ([::1]:48171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSPNd-0004en-6t for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2017 09:32:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSPMy-0004Y8-FF for emacs-devel@gnu.org; Sat, 14 Jan 2017 09:31:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cSPMv-00019E-3f for emacs-devel@gnu.org; Sat, 14 Jan 2017 09:31:48 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSPMu-00019A-WA; Sat, 14 Jan 2017 09:31:45 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1092 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cSPMt-0004Pd-Vz; Sat, 14 Jan 2017 09:31:44 -0500 In-reply-to: <87wpdxu8yt.fsf@russet.org.uk> (phillip.lord@russet.org.uk) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211281 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Date: Sat, 14 Jan 2017 12:22:50 +0000 > > I've worked up the patch that I made to add input streams for writing to > the system standard out. There was some discussion about this in Jul. > > https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00910.html > > The new version is on feature/stdout-stderr-stream. Thanks. Some of the concerns I expressed here: https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00938.html are still relevant, and at the very least should be reflected in the docs. > Can I add this to master? I think this still "needs work", see my comments below: +@cindex @code{external-standard-input} +@defun external-standard-input &optional char No need to explicitly index a function that is introduced in a @defun: the latter automatically adds an index entry. +This function reads a single character from the system standard input +(as opposed to @var{standard-input}) and functions as a stream. Note, Two spaces between sentences, please (here and elsewhere). +however, that if Emacs is running in a terminal its use can be +unpredictable. I think we should explain more about the issue here, so that the reader understands what she is up against. (I think this function will simply not work on a TTY frame.) +These functions are predominately useful for debugging, as they are a +mechanism for producing output that does not change any buffer. Note, +however, that if Emacs is running in a terminal their use can affect +the display unpredictably. Likewise here. This should also mention the problems with stdout/stderr disposition in GUI sessions. +(defvar external-standard-input-pushback nil + "Pushback character for `external-standard-input'.") Isn't this an internal variable? If so, it should use double hyphen in its name. And what is the purpose of this pushback? I didn't see any code that sets it in patch. +DEFUN ("external-standard-input-read-char",Fexternal_standard_input_read_char, Sexternal_standard_input_read_char, 0, 0, 0, + doc: /* Read a single character from the system standard input. + +Returns -1 if standard input is at the end.*/) + (void) +{ + int c; + Lisp_Object val; + + c = getchar(); + XSETINT(val,c); + + return val; +} This implementation has a number of issues: . getchar reads a _byte_, not a character, so unless input is plain-ASCII, what you return here is a raw byte, not a character in the Emacs sense of that word. That is inconsistent with every other input facility we have, and could very well get the user in trouble. . getchar doesn't return until you type RET, at least on my system, which might come as a surprise to users. . (nitpicking) our coding style keeps one space between the function/macro name and the opening parenthesis. (Same issue exists elsewhere in the patch.) +DEFUN ("external-standard-input-read-line", Fexternal_standard_input_read_line, Sexternal_standard_input_read_line, 0, 0, 0, + doc: /* Read a line from the system standard input.*/) This function doesn't seem to be documented in the ELisp manual. + if (len || c == '\n' || c == '\r') + { + val = make_string (line, len); + xfree (line); What about EOL decoding, as in all the other Emacs input functions? Also, make_string has its own ideas about when to produce unibyte strings and when multibyte strings. You should instead decode the input text using coding-system-for-read (if non-nil) or locale-coding-system (or maybe what terminal-coding-system returns). +DEFUN ("external-standard-output", Fexternal_standard_output, Sexternal_standard_output, 1, 1, 0, + doc: /* Output character CHARACTER to system standard output. */) + (Lisp_Object character) +{ + CHECK_NUMBER (character); + printchar_to_stream (XINT(character), stdout); printchar_to_stream converts the output text via standard-display-table, if that is non-nil; do we really want that for functionality that is supposed to be a debugging aid? It also sends its argument to the debugger on MS-Windows -- is that desirable?