From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: merging etc Date: Thu, 30 Aug 2007 15:02:35 +0200 Message-ID: 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> <86ejhli3j0.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188478994 21674 80.91.229.12 (30 Aug 2007 13:03:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Aug 2007 13:03:14 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 30 15:03:12 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 1IQjfn-0001nN-As for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2007 15:02:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQjfm-0003N5-TV for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2007 09:02:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IQjfT-000328-PV for emacs-devel@gnu.org; Thu, 30 Aug 2007 09:02:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IQjfS-00030w-D3 for emacs-devel@gnu.org; Thu, 30 Aug 2007 09:02:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQjfS-00030d-8u for emacs-devel@gnu.org; Thu, 30 Aug 2007 09:02:38 -0400 Original-Received: from proxy1.bredband.net ([195.54.101.71]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IQjfR-0004lG-JP for emacs-devel@gnu.org; Thu, 30 Aug 2007 09:02:37 -0400 Original-Received: from kurono.home (83.227.131.3) by proxy1.bredband.net (7.3.127) id 46D6A7B100008FDF for emacs-devel@gnu.org; Thu, 30 Aug 2007 15:02:36 +0200 In-Reply-To: <86ejhli3j0.fsf@lola.quinscape.zz> (David Kastrup's message of "Thu\, 30 Aug 2007 14\:57\:07 +0200") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1.50 (gnu/linux) X-Detected-Kernel: Genre and OS details not recognized. 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:77417 Archived-At: David Kastrup writes: > 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? Is that sort of thing normaly documented in NEWS? I thought the purpose of NEWS was to be a somewhat terse overview? > 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 -- Joakim Verona