From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: merging etc Date: Thu, 30 Aug 2007 14:57:07 +0200 Message-ID: <86ejhli3j0.fsf@lola.quinscape.zz> References: <200708211523.l7LFNnVl000876@oogie-boogie.ics.uci.edu> <200708220820.l7M8KbIt026014@oogie-boogie.ics.uci.edu> <200708290403.l7T43TS6023420@oogie-boogie.ics.uci.edu> <200708290425.l7T4P4TC023875@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188478647 20242 80.91.229.12 (30 Aug 2007 12:57:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Aug 2007 12:57:27 +0000 (UTC) Cc: joakim@verona.se, emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 30 14:57:26 2007 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 1IQjaH-0000Eg-Tn for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2007 14:57:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQjaH-00065j-E3 for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2007 08:57:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IQjaE-00065e-0P for emacs-devel@gnu.org; Thu, 30 Aug 2007 08:57:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IQjaB-00062R-CM for emacs-devel@gnu.org; Thu, 30 Aug 2007 08:57:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQjaB-00062N-A8 for emacs-devel@gnu.org; Thu, 30 Aug 2007 08:57:11 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IQjaA-0003bm-Lz for emacs-devel@gnu.org; Thu, 30 Aug 2007 08:57:10 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id OAA21895 for ; Thu, 30 Aug 2007 14:57:02 +0200 X-Delivered-To: Original-Received: (qmail 28890 invoked from network); 30 Aug 2007 12:57:07 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 30 Aug 2007 12:57:07 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 5CD20E9B24; Thu, 30 Aug 2007 14:57:07 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Thu\, 30 Aug 2007 08\:37\:33 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Detected-Kernel: Linux 2.4-2.6 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:77415 Archived-At: Stefan Monnier writes: >> Just to get things started, here is a tentative NEWS entry: > >> ** Emacs now supports several simultaneous display devices. >> Emacs can now handle frames on several different X displays and >> terminals simultaneously. Emacsclient has also been extendend to allow >> specification on which display to use. > > That's the Emacs-level documentation. It is? We don't need to document that environment variables suddenly are session-specific, we don't need to document the relation of sessions to frames to terminals and so on? That some stuff has become frame-local, too? I think that some of those details would better be solved in a different way, but it is not easy to do or judge that if the current choices are not really documented with their user-relevant consequences. > We need the Lisp-level doc as well. That too. But for discussing and/or cleaning the implications of the design, the consequences for the user are of foremost interest, I think. If we can't explain the consequences for the user concisely and understandably, there is a problem with the design. So that is the kind of documentation I would want to see first. If the user-visible consequences are easy to understand and consistent, the documentation for _that_ can stay, and the Lisp level can then try to follow. -- David Kastrup