unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 30241@debbugs.gnu.org
Subject: bug#30241: Emacs 26.0.91: "Generalized variables" are not defined.
Date: Sat, 10 Feb 2018 21:58:41 +0000	[thread overview]
Message-ID: <20180210215841.GB4537@ACM> (raw)
In-Reply-To: <83o9lfk2sy.fsf@gnu.org>

Hello, Eli.

Sorry about the long delay.

On Sat, Jan 27, 2018 at 12:34:53 +0200, Eli Zaretskii wrote:
> > Date: Fri, 26 Jan 2018 08:15:32 -0800 (PST)
> > From: Drew Adams <drew.adams@oracle.com>
> > Cc: acm@muc.de, 30241@debbugs.gnu.org

[ .... ]

> > I think you'll see a difference - it is, IMO, "significantly
> > different".

> Actually, no, I didn't.  I do see some additional explanations that
> might have helped Alan understand the issue, but nothing
> "significant".  So much so that I doubt Alan will find the CL docs
> helpful after disliking our docs of the same subject, as he did, based
> on his original bug report.  Of course, it's possible that I'm missing
> something here.

> Therefore, I invite Alan (and anyone else who'd like to chime in) to
> please compare the CL docs on this matter with ours, and tell what
> parts of the former made the issue "fall into place" (pun intended)
> wrt this topic, where our docs don't.  Bonus points for proposing
> patches for the relevant parts of the ELisp manual, to make this
> subject's documentation "significantly" better.

I've read https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node80.html,
and found it clear indeed.  However it was also long.  After reading it,
the Elisp sections on generalised variables make much more sense.

This suggests that these Elisp sections contain the material, but are
not suitable for readers who don't already understand generalised
variables.

In that CL page, a generalised variable is effectively defined as
something you can use `setf' on within the first three paragraphs.  In
the elisp sections, that identification is not present in the opening
paragraphs - there is no definition on that opening page.  The first
sub-page does not define a generalised variable as something you can use
setf on - it merely says setf is a way to access one.  But that
definition needs to be in the top level page, and it needs to be clear
that it _is_ a definition.

The CL page gives a complete list of forms setf will work with.  The
elisp page merely gives a list, without it being clear whether that list
is complete or not.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).





  parent reply	other threads:[~2018-02-10 21:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-24 20:06 bug#30241: Emacs 26.0.91: "Generalized variables" are not defined Alan Mackenzie
2018-01-24 20:49 ` Noam Postavsky
2018-01-24 21:25 ` Drew Adams
2018-01-24 21:38   ` Noam Postavsky
2018-01-24 21:43     ` Drew Adams
2018-01-26 14:16   ` Eli Zaretskii
2018-01-26 16:15     ` Drew Adams
2018-01-27 10:34       ` Eli Zaretskii
2018-02-02 10:33         ` Eli Zaretskii
2018-02-10 11:24           ` Eli Zaretskii
2018-02-10 21:58         ` Alan Mackenzie [this message]
2018-02-10 22:54           ` Drew Adams
2018-02-11 20:43             ` Richard Stallman
2018-02-11 16:00           ` Eli Zaretskii
2018-03-20 20:51             ` Alan Mackenzie
2018-03-21  6:17               ` Eli Zaretskii
     [not found] ` <handler.30241.B.15168248834946.ack@debbugs.gnu.org>
2018-03-21 17:46   ` bug#30241: (Emacs 26.0.91: "Generalized variables" are not defined.) Alan Mackenzie
     [not found] <<20180124200652.GA4493@ACM>
     [not found] ` <<e3468d0d-4ee5-4173-9a0d-051803a8cf08@default>
     [not found]   ` <<83h8r8ln7u.fsf@gnu.org>
     [not found]     ` <<41654c7c-2d8d-44ec-a5c4-dd12014b7a9e@default>
     [not found]       ` <<83o9lfk2sy.fsf@gnu.org>
2018-01-27 15:31         ` bug#30241: Emacs 26.0.91: "Generalized variables" are not defined Drew Adams

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/emacs/

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

  git send-email \
    --in-reply-to=20180210215841.GB4537@ACM \
    --to=acm@muc.de \
    --cc=30241@debbugs.gnu.org \
    --cc=eliz@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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).