From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Turn on more documentation Date: Mon, 14 May 2012 11:14:23 -0400 Message-ID: References: <87ehqxzke9.fsf@gnu.org> <87lil4vz9g.fsf@gnu.org> <87k40fszd5.fsf@gnu.org> <87likureni.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1337008485 30461 80.91.229.3 (14 May 2012 15:14:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 May 2012 15:14:45 +0000 (UTC) Cc: guile-devel@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 14 17:14:42 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1STwyv-0001ou-KU for guile-devel@m.gmane.org; Mon, 14 May 2012 17:14:41 +0200 Original-Received: from localhost ([::1]:59629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STwyu-000503-RQ for guile-devel@m.gmane.org; Mon, 14 May 2012 11:14:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STwyl-0004ze-IP for guile-devel@gnu.org; Mon, 14 May 2012 11:14:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1STwyg-0002N9-RA for guile-devel@gnu.org; Mon, 14 May 2012 11:14:31 -0400 Original-Received: from mail-we0-f169.google.com ([74.125.82.169]:60982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1STwyg-0002Jv-Hz; Mon, 14 May 2012 11:14:26 -0400 Original-Received: by wefh52 with SMTP id h52so2463693wef.0 for ; Mon, 14 May 2012 08:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vpc0LzyNh0zQX0xWIGwQf629dLMUfyY60Skr6yw5cFI=; b=VNAAAnv1PP5A+Ju9QmIxwBS7K2A5PHtit7pv6zqp6ok7qZ+qGEVqHNBJbbVeI06etG VV0TlKH9gfrxKzH+2KpPaRwSRzAfhsRXN/X6JDlNf7lfnU69ebom8KmCVQnZe35B4yc/ 9hk7OQeHUKDt2Iy6cmfsQZJS36Ffkw2DY+s6u82sjZss/2A7y7wAr1jKM0fgEKz2E8ur VGumnX7uFfHjArfjQRUOwGD/IAHXOTfU9KugPV5xP0kUHQ2f2rUP5qnCL2GnJeqGHG9G T982JSkWcZpomMcfFmEHlgmZBLCumy68BQ4ZcXL+LjeFjDTZQTejXCrzcn0b/CQ/6uA2 vIRA== Original-Received: by 10.50.47.132 with SMTP id d4mr4521101ign.7.1337008463495; Mon, 14 May 2012 08:14:23 -0700 (PDT) Original-Received: by 10.42.29.200 with HTTP; Mon, 14 May 2012 08:14:23 -0700 (PDT) In-Reply-To: <87likureni.fsf@gnu.org> X-Google-Sender-Auth: rGrZf2gNZEJatblU8bX4JdMJGug X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14419 Archived-At: Hello, >> Unless there is going to be some other distinction between core and >> extensions, it would seem more natural to me to document everything by >> functionality, in the same part of the manual. Some sections would >> correspond to modules, because modules are also supposed to group >> things by functionality, but that would not be the rule for how the >> manual worked. What do you think? > > I tend to agree, but then I=92m not sure what a better sectioning would b= e > in practice. =A0Any ideas? I think of our current situation as having three top-level lists of functionality, in API Reference, Guile Modules, and Standard Library. How about just merging them into one list? > Perhaps this could be worked out in =91master=92, so that node names don= =92t > change for 2.0.x. Yes, I certainly agree that we shouldn't change this for 2.0. Thanks, Noah