unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@gnu.org>
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: "guile-user@gnu.org" <guile-user@gnu.org>
Subject: Re: SLAYER announcement and help request for preparing a GNU package
Date: Wed, 08 May 2013 11:34:12 +0200	[thread overview]
Message-ID: <87wqr9n7cb.fsf@zigzag.favinet> (raw)
In-Reply-To: <CAMFYt2bgUncJEO=zbH5PUO6V5+3b=rB0+BtEDe_2Vd5=EkyoQg@mail.gmail.com> (Panicz Maciej Godek's message of "Wed, 8 May 2013 00:50:32 +0200")

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

() Panicz Maciej Godek <godek.maciek@gmail.com>
() Wed, 8 May 2013 00:50:32 +0200

   both guile-sdl and guile-figl copy the scm modules to
   $(prefix)/share/guile/site..., but apparently they both do that in a
   different way (which means there's no standard way), and none of them
   allows to 'fine tune' that directory with an optarg to ./configure

I like how guile-ncurses does it.  Maybe Guile-BAUX (and SNUGGLE[0],
which i forgot to mention previously) will follow its lead.

   And the whole thing makes me wonder about the status of guile
   documentation.

Back in time, Guile inherited the documentation maintenance mindset of
Emacs, i.e., "docstrings are for interactive (repl) consumption, full
descriptions belong in the manual".  This makes for a lot of work, which
Emacs can easily demand of its large hacker population, but Guile cannot
(its hackers being relatively few and somewhat prone to solipsism).  So
naturally, as w/ any situation where todo exceeds doers, some stuff does
not get done or gets done w/ less attention than deserved.

At present, there is a protocol between the repl and the database of
docstrings (guile-procedures.txt) only, and only for libguile(?).  And
those laboriously maintained docstrings do not make it into the manual,
either, by dint of the mindset.  If that were to change, i think it
would be a SMOP to arrange to significantly improve the status of Guile
documentation.  (Maybe that has already happened, but i missed it?)

Personally, i think the ideal model is to define a protocol between the
repl and the manual-viewing program, such that full documentation is the
only thing that needs to be maintained.  IMHO, the best layout for that
is intro, concept and expository text in .texi, and proc/var/etc details
in .h/.c/.scm comments.  That's what Guile-BAUX supports, no surpise.

   The guide is really great (although sometimes it remains silent about
   certain features that can be found in header files), but I've
   observed that doc-strings for built-in functions are no longer
   available, even though they are specified.

Could you give some examples?

   And besides, how do the aforementioned modules (those are, as I
   reckon, tsar and c-tsar) refer to guile-snarf-docs that is shipped
   with guile source?

They don't.  The script guile-snarf-docs is not installed, and thus not
available to third parties (like SLAYER or Guile-SDL).  But even if it
were, its method has changed over the years; it might give bad results
if used w/ a different Guile version than its original distribution.
Believe me, i [pw]ondered the same thing.  That's what led to Guile
1.4.x hacking and doc fu[1], and eventually, Guile-BAUX (and SNUGGLE).

___________________________________________________
[0] http://www.gnuvola.org/software/snuggle/

[1] http://www.gnuvola.org/software/guile/
    http://www.gnuvola.org/software/guile/doc/Doc-Maintenance.html

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2013-05-08  9:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-04 21:54 SLAYER announcement and help request for preparing a GNU package Panicz Maciej Godek
2013-05-05  5:15 ` John Darrington
2013-05-05  6:55   ` Stjepan Horvat
2013-05-05  6:59   ` Panicz Maciej Godek
2013-05-05 18:48     ` Thien-Thi Nguyen
2013-05-05 19:42       ` Popularity (was Re: SLAYER announcement ...) Mike Gran
2013-05-05 20:04         ` Popularity Frank Terbeck
2013-05-05 22:12         ` Popularity (was Re: SLAYER announcement ...) Chris Vine
2013-05-06  3:25         ` Nala Ginrut
2013-05-07 12:20         ` Ludovic Courtès
2013-05-05 21:37       ` SLAYER announcement and help request for preparing a GNU package Panicz Maciej Godek
2013-05-06  8:06 ` Javier Sancho
2013-05-06 19:36   ` Panicz Maciej Godek
2013-05-06 21:25     ` Thien-Thi Nguyen
2013-05-07 22:50       ` Panicz Maciej Godek
2013-05-08  9:34         ` Thien-Thi Nguyen [this message]
2013-05-08 12:51           ` Panicz Maciej Godek
2013-05-08 13:37             ` Mark H Weaver
2013-05-08 15:15               ` Mike Gran
2013-05-08 21:44                 ` Panicz Maciej Godek
2013-05-09  6:50             ` Thien-Thi Nguyen
2013-05-08 21:56           ` Ludovic Courtès
2013-05-07  7:23     ` Javier Sancho
2013-05-07 22:00       ` Panicz Maciej Godek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqr9n7cb.fsf@zigzag.favinet \
    --to=ttn@gnu.org \
    --cc=godek.maciek@gmail.com \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).