From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Terminology in multi-tty primitives Date: Tue, 30 Dec 2008 11:18:15 +0900 Message-ID: <87zlies8wo.fsf@xemacs.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1230603340 5801 80.91.229.12 (30 Dec 2008 02:15:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2008 02:15:40 +0000 (UTC) Cc: Eli Zaretskii , cyd@stupidchicken.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 30 03:16:47 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LHUA2-0006xQ-7v for ged-emacs-devel@m.gmane.org; Tue, 30 Dec 2008 03:16:46 +0100 Original-Received: from localhost ([127.0.0.1]:57239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LHU8o-0002ds-Ai for ged-emacs-devel@m.gmane.org; Mon, 29 Dec 2008 21:15:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LHU8j-0002dd-S7 for emacs-devel@gnu.org; Mon, 29 Dec 2008 21:15:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LHU8j-0002dQ-Eu for emacs-devel@gnu.org; Mon, 29 Dec 2008 21:15:25 -0500 Original-Received: from [199.232.76.173] (port=39263 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LHU8j-0002dN-92 for emacs-devel@gnu.org; Mon, 29 Dec 2008 21:15:25 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:43128) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LHU8e-00083l-PI; Mon, 29 Dec 2008 21:15:21 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 12EFD1535B3; Tue, 30 Dec 2008 11:15:13 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B410511F559; Tue, 30 Dec 2008 11:18:15 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:107406 Archived-At: Richard M Stallman writes: > I think you are wrong about suspend making no sense on GUI terminals: > we have (in Emacs 23) suspend-frame that does work on GUI. > > It does this by lumping together various different operations. > Really it is just a way of trying to make C-z do something meaningful > on window systems where suspending Emacs is not useful. > It is a useful command, but sheds no light on how to conceptualize the > interfaces at the Lisp level. I used to agree with you, but The Kids These Days (ie, those who have grown up with WIMPy interfaces) think of a window as a (foreground) process. If the window goes away, the process stops. I think that is well-based in psychology. If Eli (the MS-DOS Ambassador to Emacs!) finds commonality there, there's *something* in common there. In particular, on a GUI the difference between a kill -STOP'ed emacs and one with no visible windows is hardly important to the user, who must do something unusual to resurrect it. So the "withdraw frame" function (which happens to be called `suspend-frame') just keeps withdrawing frames, and when the last one is withdrawn, emacs goes to sleep. On a X11-style GUI, this requires no additional work: no window, no events, no Maya == Nirvana. On a TTY, you need to suspend Emacs to achieve enlightenment. No big difference from the user's POV. > Anyway, the examples I gave were just that: examples. Here's another > example: we have make-frame-on-display, make-frame-on-tty, and > make-terminal-frame; and then we have make-frame that can do all of > the above. IMO, it's terribly confusing. > > Would you like to propose a change for these, which people could consider? The semantics are a bit delicate, but if you have/create a notion of "current-terminal", which is the terminal from which input was last received, then in practice most frames are created on that terminal, and most of the rest have an implicit notion of "my terminal" (eg, an emacsclient -nw process will use its controlling tty). So give make-frame a terminal parameter, and (make-frame) will use the current terminal as default. The general form will be (make-frame '((terminal DESCRIPTOR) (terminal-type TYPE))) where if 'terminal-type is absent, `make-frame' uses an heuristic to guess it. In particular, there should be a way to discriminate between a human-oriented descriptor and an unambiguous internal one. It seems to me that humans who know what they want will invariably use a string descriptor, such as ":0" or "CON:" or "/dev/tty3". So make the internal type of terminals something else (the small integer indexing a table of connections would do fine). This internal type is what `frame-terminal' (takes a frame argument), `get-terminal' (takes a string and optional type argument, implements the guessing algorithm used above, and calls `make-terminal' if an appropriate terminal connection doesn't exist yet), and `make-terminal' (the more-or-less internal function that does the heavy lifting) return. Then the general `make-frame' call above would be precisely equivalent to (make-frame '((terminal (get-terminal DESCRIPTOR TYPE)))) when DESCRIPTOR is a string. Use of the internal type for DESCRIPTOR in `get-terminal' should be an error. Personally, I see no need whatsoever for `make-frame-on-...' variants. If they can't be removed for hysterical raisins, then at least they can be deprecated in the documentation.