unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>, <5971@debbugs.gnu.org>
Cc: tracker@debbugs.gnu.org,
	'GNU bug Tracking System' <help-debbugs@gnu.org>
Subject: bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value
Date: Mon, 19 Apr 2010 08:09:38 -0700	[thread overview]
Message-ID: <1ED47ADCD80A4C019EF77D4CB7C5D863@us.oracle.com> (raw)
In-Reply-To: <jwvbpdgufit.fsf-monnier+emacs@gnu.org>

 

> -----Original Message-----
> From: Stefan Monnier [mailto:monnier@iro.umontreal.ca] 
> Sent: Sunday, April 18, 2010 11:25 PM
> To: Drew Adams
> Subject: Re: bug#5971: 23.1.95; `delete' modifies default 
> value instead of buffer-local value
> 
> >> > This doesn't seem right to me.
> >>
> >> Why not?  That's the whole reason for the existence of two 
> >> functions: `delete' and `remove'.
> >
> > I'm aware that `delete' modifies the list structure and 
> > `remove' uses a copy.  What I don't understand is the
> > interaction with a default value instead of a buffer-local
> > value.  Why would `delete' cause the behavior described?
> 
> Why not?

Why? (You're not helping, just being evasive.) Why should modification of a
buffer-local value also modify the default value?

If this is not a product bug, it is at least a doc bug.

I can find nothing in the doc that mentions such behavior or would help one to
expect it or understand it. There is no explanation of any dependency between a
default value and buffer-local values, in the sense manifested. The only
explanation about buffer-local vars states that if a buffer-local value is not
yet set then the default value is used instead.

That does not explain why modification of a buffer-local value would affect also
the default value. The way the doc presents it, the two are conceptually
separate, including in terms of modification. There is nothing that I can see
that would lead one to expect that modification of a particular buffer-local
value would affect also the default value. This needs to be documented. It is
apparently an important way in which a buffer-local value is, well, not
buffer-local.

In the doc there are caveats about things like `let'-binding, but nothing is
said about this (arguably more serious or at least just as surprising)
bizarreness (er, design property).

Buffer-local variables are specific to Emacs Lisp (and other Lisps that have a
notion of editor buffers). Other, general Lisps do not have any notion of
buffer-local variables, so users of such Lisps who come to Emacs Lisp will not
have an understanding of this either. The Emacs Lisp doc needs to cover this
specific difference completely.

> PS: Closing this.  

Please reopen it - at least as a doc bug.

> You can continue the discussion on gnu.emacs.help
> (or even comp.lang.lisp, tho I never read that one and 
> they're probably not that familiar with buffer-local variables).

Precisely. Which is why this particular knot about buffer-local variables needs
to be documented in the Elisp manual. It is not, AFAICT.








  reply	other threads:[~2010-04-19 15:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19  2:41 bug#5971: 23.1.95; `delete' modifies default value instead of buffer-local value Drew Adams
2010-04-19  4:23 ` Stefan Monnier
2010-04-19  5:24   ` Drew Adams
2010-04-19  6:25     ` Stefan Monnier
2010-04-19 15:09       ` Drew Adams [this message]
2010-04-19 15:56         ` Glenn Morris
2010-04-19 16:05         ` Andreas Schwab
2010-04-19 16:15           ` Drew Adams
2010-04-19 16:31             ` Andreas Schwab
2010-04-19 17:03               ` Drew Adams
2010-04-19 18:42                 ` Andreas Schwab
2010-04-19 18:58                   ` Drew Adams
2010-04-19 20:18                     ` Andreas Schwab
2010-04-19 20:31                       ` Drew Adams
2010-04-19 20:38                         ` Andreas Schwab
2010-04-19 22:06                           ` Drew Adams
2010-04-21  7:29                             ` Kevin Rodgers
2010-04-21 11:58                               ` Drew Adams
2011-07-09  5:47                               ` Glenn Morris
2010-04-19 15:09     ` bug#5971: - reopen 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=1ED47ADCD80A4C019EF77D4CB7C5D863@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=5971@debbugs.gnu.org \
    --cc=help-debbugs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=tracker@debbugs.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).