unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gerd.moellmann@gmail.com, 65209@debbugs.gnu.org,
	monnier@iro.umontreal.ca
Subject: bug#65209: 30.0.50; Unexpected behaviour of setq-local
Date: Tue, 22 Aug 2023 05:09:44 +0200	[thread overview]
Message-ID: <87wmxnojrb.fsf@web.de> (raw)
In-Reply-To: <83350exl6h.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Aug 2023 09:49:42 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

> > Ehm - does somebody care about the manual?
>
> What do you mean?

My wish would be that the manual says a bit more about how let-binding
and buffer-local play together.  We have this

|    *Warning:* When a variable has buffer-local bindings in one or more
| buffers, ‘let’ rebinds the binding that’s currently in effect.  For
| instance, if the current buffer has a buffer-local value, ‘let’
| temporarily rebinds that.  If no buffer-local bindings are in effect,
| ‘let’ rebinds the default value.  If inside the ‘let’ you then change to
| a different current buffer in which a different binding is in effect,
| you won’t see the ‘let’ binding any more.  And if you exit the ‘let’
| while still in the other buffer, you won’t see the unbinding occur
| (though it will occur properly).

in (info "(elisp) Intro to Buffer-Local") [good] and also some words
about `set-default' being prevented from setting the default value
inside `let' in (info "(elisp) Default Value").

But the manual leaves open some questions (after reading the manual I
was not able to tell that the bug in this report was a bug):

How are bindings working when not changing the current buffer inside the
let?  If I create a buffer-local binding and the `let' is left, what
binding is left in the buffer - is the variable in that buffer still
buffer local, or does leaving the let maybe also remove the local
variable?

This example derived from Stefan's test clarifies most questions:

#+begin_src emacs-lisp
;; -*- lexical-binding: t -*-

(defvar-local my-var :default)

(let (inside-let local-inside-let inside-let-other-buffer local-outer outer)
  (with-temp-buffer
    (let ((my-var :let-bound))
      (setq inside-let my-var)
      (setq-local my-var :buffer-local)
      (setq local-inside-let my-var)
      (setq inside-let-other-buffer (with-temp-buffer my-var)))
    (setq local-outer my-var)
    (setq outer (with-temp-buffer my-var)))
  (list inside-let local-inside-let inside-let-other-buffer
        local-outer outer))

;; --> (:let-bound :buffer-local :let-bound
;;      :buffer-local :default)
#+end_src


Then, sometimes one sees this warning (e.g. when evaluating the above
example):

| Making my-var buffer-local while locally let-bound!

People will want to know what it means and whether (or when) they need
to care about it or can ignore it.


Finally, should we also talk about lexical variables vs. buffer-local?
They are different again:

#+begin_src emacs-lisp
(with-temp-buffer
  (let ((var :let-bound))
    (set (make-local-variable 'var) :buffer-local)
    var)) ;;    --> :let-bound, not :buffer-local!
#+end_src


Michael.





  reply	other threads:[~2023-08-22  3:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 13:50 bug#65209: 30.0.50; Unexpected behaviour of setq-local Gerd Möllmann
2023-08-10 14:00 ` Eli Zaretskii
2023-08-11  0:17 ` Michael Heerdegen
2023-08-11  4:56   ` Gerd Möllmann
2023-08-11  5:53     ` Michael Heerdegen
2023-08-11  8:17       ` Gerd Möllmann
2023-08-11 11:09         ` Eli Zaretskii
2023-08-11 11:34           ` Gerd Möllmann
2023-08-11 11:36             ` Eli Zaretskii
2023-08-13  4:16           ` Michael Heerdegen
2023-08-13  5:53             ` Eli Zaretskii
2023-08-11 14:58         ` Drew Adams
2023-08-13 16:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-13 19:51   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-14  3:24     ` Michael Heerdegen
2023-08-14  4:05       ` Gerd Möllmann
2023-08-18 23:24         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20  4:43           ` Michael Heerdegen
2023-08-20  6:49             ` Eli Zaretskii
2023-08-22  3:09               ` Michael Heerdegen [this message]
2023-08-22 10:56                 ` Eli Zaretskii
2023-08-23  3:47                   ` Michael Heerdegen
2023-08-23 11:39                     ` Eli Zaretskii
2023-08-23 12:51                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-24  1:06                         ` Michael Heerdegen
2023-08-24  5:22                           ` Eli Zaretskii
2023-08-26  2:09                             ` Michael Heerdegen
2023-08-26  6:02                               ` Eli Zaretskii
2023-08-26 14:25                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-27  4:19                                 ` Michael Heerdegen
2023-08-24  3:31                       ` Michael Heerdegen
2023-08-24  5:35                         ` Eli Zaretskii

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=87wmxnojrb.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=65209@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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).