From unknown Mon Jun 23 04:10:42 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#26624 <26624@debbugs.gnu.org> To: bug#26624 <26624@debbugs.gnu.org> Subject: Status: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag Reply-To: bug#26624 <26624@debbugs.gnu.org> Date: Mon, 23 Jun 2025 11:10:42 +0000 retitle 26624 26.0.50; Generalized variable `buffer-local-value' does't res= tore local flag reassign 26624 emacs submitter 26624 Philipp Stephani severity 26624 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 23 13:13:57 2017 Received: (at submit) by debbugs.gnu.org; 23 Apr 2017 17:13:57 +0000 Received: from localhost ([127.0.0.1]:36676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d2L5B-0006ob-BV for submit@debbugs.gnu.org; Sun, 23 Apr 2017 13:13:57 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d2L5A-0006oP-Jq for submit@debbugs.gnu.org; Sun, 23 Apr 2017 13:13:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2L54-0002au-AO for submit@debbugs.gnu.org; Sun, 23 Apr 2017 13:13:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35398) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d2L54-0002an-6T for submit@debbugs.gnu.org; Sun, 23 Apr 2017 13:13:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2L52-0008Ao-UN for bug-gnu-emacs@gnu.org; Sun, 23 Apr 2017 13:13:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2L51-0002aL-OW for bug-gnu-emacs@gnu.org; Sun, 23 Apr 2017 13:13:48 -0400 Received: from mail-wr0-x22e.google.com ([2a00:1450:400c:c0c::22e]:34508) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d2L51-0002aB-HA for bug-gnu-emacs@gnu.org; Sun, 23 Apr 2017 13:13:47 -0400 Received: by mail-wr0-x22e.google.com with SMTP id z109so79272177wrb.1 for ; Sun, 23 Apr 2017 10:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=StsOyRXo8alpcn9y5SrRCYm89uJ3bbGvV3N6+zMB/yI=; b=UQBzRB0lGMxyR3qjpHJ3SU0zw78RwRRPEUcdyD+A0SYasXn8wZNKGDUuYSXz4ErQvy AT9STDNQn5ryRvPyYHgCk2+2sffOZBcYB6/U4dULUPQdzlWCxGxyyPTp44EO+uh6gf7w G/JCkq1e60aMmdeoFI7ldaq/RAaUZTFqLjfq5mOMzBnsc/1vyhqpqlOn5aD368e/8iFB jitv/B/UeQOWxqX2sJHifeDXGc/ZukJh2TANKKDNDnpCHK5GICs7tNvNAhpi5jMNDF8E So3oX11j3sMzypksw6LVGZUWNFa5OKI2hWk+0Wztsy1lNgJgMHFeP9/bX6hR+ShvFHmw xfAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=StsOyRXo8alpcn9y5SrRCYm89uJ3bbGvV3N6+zMB/yI=; b=GqdmY7k1jnIdJL5oWsoPMz94L2AkPn/jhh4QCIjqXoUOOA2zgsF8BPfUQLIR7CKO1o ze22F9gYimaXPtffhrVePKsncCO+00RosZMf22BeHE4kjb7QtNG5rLq2qdQndGX2BTZY 9Ds2RlfgbD9JzoJRyisg+7Joz/5nk0GAqz7V5D2EnTyO+1Z4+uXgAN6xlg+fqtIed5OT bJNdvI2V6EAp/i7xUTWk4jVf6yfnokysKaDKdBTZAXlXTnSaJcgCvsPR2C+rALweUzXq 3PaHZQ4/OzwL8Op8tOWbajP/tiICVkHK0NowwRqFnGUk8bpqX4T2X9MXqGiqBeqajC63 II+A== X-Gm-Message-State: AN3rC/7JeaJOkMOKn/bymFEl9Y37XA7WoGq2wZ/KQ2Ndz2gBpWWNt3n/ NAa7BuNxGEbs6fGkwv+oSQ== X-Received: by 10.223.148.97 with SMTP id 88mr2766428wrq.174.1492967626152; Sun, 23 Apr 2017 10:13:46 -0700 (PDT) Received: from p ([2001:4c50:25f:c000:48e6:d722:5002:bf77]) by smtp.gmail.com with ESMTPSA id k90sm9996382wmi.26.2017.04.23.10.13.44 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 23 Apr 2017 10:13:45 -0700 (PDT) From: Philipp Stephani To: bug-gnu-emacs@gnu.org Subject: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag Date: Sun, 23 Apr 2017 19:13:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) In *scratch*, evaluate: (defvar foo-test-var nil) (with-temp-buffer (list (list (buffer-local-value 'foo-test-var (current-buffer)) (local-variable-p 'foo-test-var) (local-variable-if-set-p 'foo-test-var)) (cl-letf (((buffer-local-value 'foo-test-var (current-buffer)) 123)) (list (buffer-local-value 'foo-test-var (current-buffer)) (local-variable-p 'foo-test-var) (local-variable-if-set-p 'foo-test-var))) (list (buffer-local-value 'foo-test-var (current-buffer)) (local-variable-p 'foo-test-var) (local-variable-if-set-p 'foo-test-var)))) The result is: ((nil nil nil) (123 t t) (nil t t)) But expected is: ((nil nil nil) (123 t t) (nil nil nil)) i.e. the local flag of the variable should be reset. In GNU Emacs 26.0.50 (build 19, x86_64-apple-darwin16.5.0, NS appkit-1504.82 Version 10.12.4 (Build 16E195)) of 2017-04-23 built on p Repository revision: a1f93c1dfa53dbe007faa09ab0c6e913e86e3ffe Windowing system distributor 'Apple', version 10.3.1504 Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --without-xml2 --with-modules --without-pop --with-mailutils --enable-checking --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0' MAKEINFO=/usr/local/opt/texinfo/bin/makeinfo' Configured features: RSVG DBUS NOTIFY ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS MODULES Important settings: value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind kqueue cocoa ns multi-tty make-network-process emacs) Memory information: ((conses 16 203864 9733) (symbols 48 19974 1) (miscs 40 57 190) (strings 32 18048 4861) (string-bytes 1 589547) (vectors 16 34976) (vector-slots 8 701022 3277) (floats 8 52 66) (intervals 56 199 0) (buffers 976 11)) From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 09:10:39 2017 Received: (at 26624) by debbugs.gnu.org; 17 Jun 2017 13:10:39 +0000 Received: from localhost ([127.0.0.1]:52231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMDUt-000294-EV for submit@debbugs.gnu.org; Sat, 17 Jun 2017 09:10:39 -0400 Received: from mail-ot0-f173.google.com ([74.125.82.173]:34941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMDUr-00028r-TL for 26624@debbugs.gnu.org; Sat, 17 Jun 2017 09:10:38 -0400 Received: by mail-ot0-f173.google.com with SMTP id u13so31022295otd.2 for <26624@debbugs.gnu.org>; Sat, 17 Jun 2017 06:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZDBfxDEQHDiYrdyaKXlX+ZDoWn+VwRRxBCv2nC7edCQ=; b=PB1ENeZbEXcjZ1fWvmgPx1wWdESeKfPoXn/pFGurtR93SbtztsPbyYy2j1ARNLhr// ND1v7RLVLKJmBZC6pBff2wym0Hmn/ki/KKCmtNMkIV9XxymwbF1Xpf8sV6j0KRK0LCu+ 0rI+y1vp0dSKiv/0d9kjUQOr7/Ur4jIAWbnp7mD8h6cQCob9Z49Pi+Jaxs2HCY90Iq6P fgpMvhL4etBZ5MzXKxfGSBELlBqW4oZ55H7BQU9qSRMKTsxN3t0PSgBnb8dX4CZyJZFq DFb+ZTukLLau9hwF92JMW0g9o3sj54ULF+rqknK7WRo2y6+9RwD7vPphCc+TiyBCKZal Ot9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZDBfxDEQHDiYrdyaKXlX+ZDoWn+VwRRxBCv2nC7edCQ=; b=sR8+d6YbcJbdOztCKlEtVA1Xg1C1h0cmEqvc/ebhkQGvodq50vvEhb8LqAk8cp52Ez zXjtlanRdZ0KsPD52pNLDAsk7xUpBPwIyOQpEkn2q4MOnkFCkJhjMlaLtSTVMQSILb04 24JvMr1laU6VgyblQOS45VAgqqA3ozd0e1NQJKX3TFXeHn59z6JvPPuOpt7nM8T+XDxe ywzXeHBbV4oTovGf9hugo7TsZDRmolH8ikUhlYuhCXbOXcyvrT2tgVGz/Kn8IRhHwB7p N4rd6sJBVUurY1WjLnhx+V0XQZNLni4yzI/XCR32kCYStVH7ZN9Fekw7jKzg2sTkt0G8 5eRw== X-Gm-Message-State: AKS2vOwrHg4ABjlU7vRB7vs+RajcgOXTTZOnLpzMQ8MuLNnTXSCcXg1D Sp1s8g8I2FvDBsVlk2jDYsIaRL2fusVk X-Received: by 10.157.24.51 with SMTP id b48mr7969239ote.143.1497705030840; Sat, 17 Jun 2017 06:10:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Stephani Date: Sat, 17 Jun 2017 13:10:20 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: 26624@debbugs.gnu.org Content-Type: multipart/mixed; boundary="001a113e1e7e5799bb055227a00f" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26624 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a113e1e7e5799bb055227a00f Content-Type: multipart/alternative; boundary="001a113e1e7e5799b6055227a00d" --001a113e1e7e5799b6055227a00d Content-Type: text/plain; charset="UTF-8" Philipp Stephani schrieb am So., 23. Apr. 2017 um 19:14 Uhr: > > In *scratch*, evaluate: > > (defvar foo-test-var nil) > (with-temp-buffer > (list (list (buffer-local-value 'foo-test-var (current-buffer)) > (local-variable-p 'foo-test-var) > (local-variable-if-set-p 'foo-test-var)) > (cl-letf (((buffer-local-value 'foo-test-var (current-buffer)) > 123)) > (list (buffer-local-value 'foo-test-var (current-buffer)) > (local-variable-p 'foo-test-var) > (local-variable-if-set-p 'foo-test-var))) > (list (buffer-local-value 'foo-test-var (current-buffer)) > (local-variable-p 'foo-test-var) > (local-variable-if-set-p 'foo-test-var)))) > > The result is: > > ((nil nil nil) (123 t t) (nil t t)) > > But expected is: > > ((nil nil nil) (123 t t) (nil nil nil)) > > i.e. the local flag of the variable should be reset. > > It's possible to fix this (see attached patch), but at the expense of breaking other valid use cases such as (cl-incf (buffer-local-value ...)). Not sure whether the bug can be fixed at all without breaking other stuff. --001a113e1e7e5799b6055227a00d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am So., 23. Apr. 2017 um 19:14=C2=A0Uhr:

In *scratch*, evaluate:

(defvar foo-test-var nil)
(with-temp-buffer
=C2=A0 (list (list (buffer-local-value 'foo-test-var (current-buffer))<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (local-variable-p 'foo= -test-var)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (local-variable-if-set-p &= #39;foo-test-var))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (cl-letf (((buffer-local-value 'foo-test-va= r (current-buffer)) 123))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (list (buffer-local-value 'foo-test-= var (current-buffer))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (local-variable-p &= #39;foo-test-var)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (local-variable-if-= set-p 'foo-test-var)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (list (buffer-local-value 'foo-test-var (cu= rrent-buffer))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (local-variable-p 'foo= -test-var)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (local-variable-if-set-p &= #39;foo-test-var))))

The result is:

((nil nil nil) (123 t t) (nil t t))

But expected is:

((nil nil nil) (123 t t) (nil nil nil))

i.e. the local flag of the variable should be reset.


It's possible to fix this (see attache= d patch), but at the expense of breaking other valid use cases such as (cl-= incf (buffer-local-value ...)). Not sure whether the bug can be fixed at al= l without breaking other stuff.=C2=A0
--001a113e1e7e5799b6055227a00d-- --001a113e1e7e5799bb055227a00f Content-Type: text/plain; charset="US-ASCII"; name="0001-Have-cl-letf-restore-buffer-local-status-Bug-26624.txt" Content-Disposition: attachment; filename="0001-Have-cl-letf-restore-buffer-local-status-Bug-26624.txt" Content-Transfer-Encoding: base64 Content-ID: <15cb62bd81f3568ecbb1> X-Attachment-Id: 15cb62bd81f3568ecbb1 RnJvbSAzNzg5YjdiODQzZWM0MTdhZTNiZTVkMGYyNDQwOTU1OWE0NmJjYzkzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IEZyaSwgMTYgSnVuIDIwMTcgMjI6NTU6NTIgKzAyMDAKU3ViamVjdDogW1BBVENIIDEvMl0g SGF2ZSBgY2wtbGV0ZicgcmVzdG9yZSBidWZmZXItbG9jYWwgc3RhdHVzIChCdWcjMjY2MjQpCgoq IGxpc3AvZW1hY3MtbGlzcC9ndi5lbCAoYnVmZmVyLWxvY2FsLXZhbHVlKTogUmVjb3JkIGFuZCBy ZXN0b3JlCndoZXRoZXIgdGhlIHZhcmlhYmxlIHdhcyBidWZmZXItbG9jYWw7IHVzZWQgZm9yIGBj bC1sZXRmJy4KKiB0ZXN0L2xpc3AvZW1hY3MtbGlzcC9ndi10ZXN0cy5lbCAoZ3YtdGVzdHMtLWJ1 ZzI2NjI0KTogQWRkIHVuaXQKdGVzdC4KLS0tCiBsaXNwL2VtYWNzLWxpc3AvZ3YuZWwgICAgICAg ICAgICB8IDE1ICsrKysrKysrKy0tLQogdGVzdC9saXNwL2VtYWNzLWxpc3AvZ3YtdGVzdHMuZWwg fCA1MSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiAyIGZpbGVzIGNo YW5nZWQsIDYzIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2 NDQgdGVzdC9saXNwL2VtYWNzLWxpc3AvZ3YtdGVzdHMuZWwKCmRpZmYgLS1naXQgYS9saXNwL2Vt YWNzLWxpc3AvZ3YuZWwgYi9saXNwL2VtYWNzLWxpc3AvZ3YuZWwKaW5kZXggYzVjMTJhNjQxNC4u YTYxNGQ2NzVhZiAxMDA2NDQKLS0tIGEvbGlzcC9lbWFjcy1saXNwL2d2LmVsCisrKyBiL2xpc3Av ZW1hY3MtbGlzcC9ndi5lbApAQCAtMzcyLDkgKzM3MiwxOCBAQCBzZXRmCiAoZ3YtZGVmaW5lLXNl dHRlciB3aW5kb3ctcG9pbnQgKHYgJm9wdGlvbmFsIHcpIGAoc2V0LXdpbmRvdy1wb2ludCAsdyAs dikpCiAoZ3YtZGVmaW5lLXNldHRlciB3aW5kb3ctc3RhcnQgKHYgJm9wdGlvbmFsIHcpIGAoc2V0 LXdpbmRvdy1zdGFydCAsdyAsdikpCiAKLShndi1kZWZpbmUtc2V0dGVyIGJ1ZmZlci1sb2NhbC12 YWx1ZSAodmFsIHZhciBidWYpCi0gIChtYWNyb2V4cC1sZXQyIG5pbCB2IHZhbAotICAgIGAod2l0 aC1jdXJyZW50LWJ1ZmZlciAsYnVmIChzZXQgKG1ha2UtbG9jYWwtdmFyaWFibGUgLHZhcikgLHYp KSkpCisoZ3YtZGVmaW5lLWV4cGFuZGVyIGJ1ZmZlci1sb2NhbC12YWx1ZQorICAobGFtYmRhIChk byB2YXIgYnVmKQorICAgIChtYWNyb2V4cC1sZXQyKiBuaWwgKCh2YXIgdmFyKSAoYnVmIGJ1Zikp CisgICAgICAoZnVuY2FsbCBkbworICAgICAgICAgICAgICAgYChpZiAobG9jYWwtdmFyaWFibGUt cCAsdmFyICxidWYpCisgICAgICAgICAgICAgICAgICAgIChidWZmZXItbG9jYWwtdmFsdWUgLHZh ciAsYnVmKQorICAgICAgICAgICAgICAgICAgIzE9JyM6dW5ib3VuZCkKKyAgICAgICAgICAgICAg IChsYW1iZGEgKHZhbCkKKyAgICAgICAgICAgICAgICAgYCh3aXRoLWN1cnJlbnQtYnVmZmVyICxi dWYKKyAgICAgICAgICAgICAgICAgICAgKGlmIChlcSAsdmFsICMxIykKKyAgICAgICAgICAgICAg ICAgICAgICAgIChraWxsLWxvY2FsLXZhcmlhYmxlICx2YXIpCisgICAgICAgICAgICAgICAgICAg ICAgKHNldCAobWFrZS1sb2NhbC12YXJpYWJsZSAsdmFyKSAsdmFsKSkpKSkpKSkKIAogKGd2LWRl ZmluZS1leHBhbmRlciBhbGlzdC1nZXQKICAgKGxhbWJkYSAoZG8ga2V5IGFsaXN0ICZvcHRpb25h bCBkZWZhdWx0IHJlbW92ZSkKZGlmZiAtLWdpdCBhL3Rlc3QvbGlzcC9lbWFjcy1saXNwL2d2LXRl c3RzLmVsIGIvdGVzdC9saXNwL2VtYWNzLWxpc3AvZ3YtdGVzdHMuZWwKbmV3IGZpbGUgbW9kZSAx MDA2NDQKaW5kZXggMDAwMDAwMDAwMC4uYjQ5YzEyZGRmMgotLS0gL2Rldi9udWxsCisrKyBiL3Rl c3QvbGlzcC9lbWFjcy1saXNwL2d2LXRlc3RzLmVsCkBAIC0wLDAgKzEsNTEgQEAKKzs7OyBndi10 ZXN0cy5lbCAtLS0gdW5pdCB0ZXN0cyBmb3IgZ3YuZWwgICAgICAgICAgICAgLSotIGxleGljYWwt YmluZGluZzogdDsgLSotCisKKzs7IENvcHlyaWdodCAoQykgMjAxNyBGcmVlIFNvZnR3YXJlIEZv dW5kYXRpb24sIEluYy4KKworOzsgVGhpcyBmaWxlIGlzIHBhcnQgb2YgR05VIEVtYWNzLgorCis7 OyBHTlUgRW1hY3MgaXMgZnJlZSBzb2Z0d2FyZTogeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5k L29yIG1vZGlmeQorOzsgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKzs7IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRp b24sIGVpdGhlciB2ZXJzaW9uIDMgb2YgdGhlIExpY2Vuc2UsIG9yCis7OyAoYXQgeW91ciBvcHRp b24pIGFueSBsYXRlciB2ZXJzaW9uLgorCis7OyBHTlUgRW1hY3MgaXMgZGlzdHJpYnV0ZWQgaW4g dGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKzs7IGJ1dCBXSVRIT1VUIEFOWSBXQVJS QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCis7OyBNRVJDSEFOVEFC SUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCis7OyBH TlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorCis7OyBZb3Ugc2hv dWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z ZQorOzsgYWxvbmcgd2l0aCBHTlUgRW1hY3MuICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5nbnUu b3JnL2xpY2Vuc2VzLz4uCisKKzs7OyBDb21tZW50YXJ5OgorCis7OyBVbml0IHRlc3RzIGZvciBs aXNwL2VtYWNzLWxpc3AvZ3YuZWwuCisKKzs7OyBDb2RlOgorCisoZGVmdmFyIGd2LXRlc3RzLS12 YXIgJ2RlZmF1bHQgIlRlc3QgdmFyaWFibGUuIikKKworKGVydC1kZWZ0ZXN0IGd2LXRlc3RzLS1i dWcyNjYyNCAoKQorICAiQ2hlY2tzIHRoYXQgQnVnIzI2NjI0IGlzIGZpeGVkLiIKKyAgKHdpdGgt dGVtcC1idWZmZXIKKyAgICAobGV0ICgodmFyLWNhbGxzIDApIChidWYtY2FsbHMgMCkpCisgICAg ICAoc2hvdWxkIChlcXVhbCAoYnVmZmVyLWxvY2FsLXZhbHVlICdndi10ZXN0cy0tdmFyIChjdXJy ZW50LWJ1ZmZlcikpCisgICAgICAgICAgICAgICAgICAgICAnZGVmYXVsdCkpCisgICAgICAoc2hv dWxkLW5vdCAobG9jYWwtdmFyaWFibGUtcCAnZ3YtdGVzdHMtLXZhcikpCisgICAgICAoc2hvdWxk LW5vdCAobG9jYWwtdmFyaWFibGUtaWYtc2V0LXAgJ2d2LXRlc3RzLS12YXIpKQorICAgICAgKGNs LWxldGYgKCgoYnVmZmVyLWxvY2FsLXZhbHVlCisgICAgICAgICAgICAgICAgICAocHJvZ24gKGNs LWluY2YgdmFyLWNhbGxzKSAnZ3YtdGVzdHMtLXZhcikKKyAgICAgICAgICAgICAgICAgIChwcm9n biAoY2wtaW5jZiBidWYtY2FsbHMpIChjdXJyZW50LWJ1ZmZlcikpKQorICAgICAgICAgICAgICAg ICAndW5ib3VuZCkpCisgICAgICAgIChzaG91bGQgKGVxdWFsIChidWZmZXItbG9jYWwtdmFsdWUg J2d2LXRlc3RzLS12YXIgKGN1cnJlbnQtYnVmZmVyKSkKKyAgICAgICAgICAgICAgICAgICAgICAg J3VuYm91bmQpKQorICAgICAgICAoc2hvdWxkIChsb2NhbC12YXJpYWJsZS1wICdndi10ZXN0cy0t dmFyKSkKKyAgICAgICAgKHNob3VsZCAobG9jYWwtdmFyaWFibGUtaWYtc2V0LXAgJ2d2LXRlc3Rz LS12YXIpKSkKKyAgICAgIChzaG91bGQgKGVxdWFsIChidWZmZXItbG9jYWwtdmFsdWUgJ2d2LXRl c3RzLS12YXIgKGN1cnJlbnQtYnVmZmVyKSkKKyAgICAgICAgICAgICAgICAgICAgICdkZWZhdWx0 KSkKKyAgICAgIChzaG91bGQtbm90IChsb2NhbC12YXJpYWJsZS1wICdndi10ZXN0cy0tdmFyKSkK KyAgICAgIChzaG91bGQtbm90IChsb2NhbC12YXJpYWJsZS1pZi1zZXQtcCAnZ3YtdGVzdHMtLXZh cikpCisgICAgICAoc2hvdWxkIChlcXVhbCB2YXItY2FsbHMgMSkpCisgICAgICAoc2hvdWxkIChl cXVhbCBidWYtY2FsbHMgMSkpKSkpCisKKzs7OyBndi10ZXN0cy5lbCBlbmRzIGhlcmUKLS0gCjIu MTMuMQoK --001a113e1e7e5799bb055227a00f-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 17 14:46:32 2017 Received: (at 26624) by debbugs.gnu.org; 17 Jun 2017 18:46:32 +0000 Received: from localhost ([127.0.0.1]:53672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMIjw-0005OJ-CO for submit@debbugs.gnu.org; Sat, 17 Jun 2017 14:46:32 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:37571) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMIjv-0005O6-6m for 26624@debbugs.gnu.org; Sat, 17 Jun 2017 14:46:31 -0400 Received: by mail-it0-f43.google.com with SMTP id m47so41246266iti.0 for <26624@debbugs.gnu.org>; Sat, 17 Jun 2017 11:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=X92R3+uztBvAqLGJqosSpYh8ISGoy9rYjUIgIj8CaH0=; b=Mqr4/YkPFiZLXoD5g8mBErDESSZAn0jqRHCGi7Nk84veo7T9+NmLUxsQah0gGgMkqS zKjotrOe1ssy4r5IGdJBP7jSJFe/brnvi81kq1hbPN2e5UNP2KwGEIhL9RnqG2l7gjj9 Jj1DwaCPxb+ntv8O/z+MebiLfYAuZZQSJb7LbrvCZl/I51RNttZlocveRMBI7rBOe2DD MxOwXRYrY0eHfTrvPWRPuVyqNHugfKheWs7XfOKxFsD8J084K6Mgruwc5MTtE4dmYKN0 ljiiyLNt7peEfFrNKkPHcX+oiU7RxNPgdMJMgC04kj4Z2zi5fYFy+AQ4YLDn72d4sB/L oWWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=X92R3+uztBvAqLGJqosSpYh8ISGoy9rYjUIgIj8CaH0=; b=Gs6RtLTOFUwL3Q8g3XAlaEbik7TTZcUbIVNRYjwJlmsHLSl7/iSsxa6/2ZEcRXu9vG gyCiVCV+Uyx7jhq5B6jEQLozMTYD8h7kAlvyc+en1L4008VSkS12mony5+gJ7Icb3l8K Y75o8EJPH4yaxZPQEtmiqrD/GQlRq1TjRaVTKvXB1tmBpwzUOU5Q6DJL6ySjJjzsKtyE A7PjlYfkR859j0CkD6IdwljKh9lzWogYzwRfvh2seBPG8sLVcdRZKhBVqoUfNiJ+GRV+ /GGzMRiSDOSF9SZkQ2FkmQvogMMKYmEVap8LQXrpc2SQyeM+ISKGLCEmjXqyvvArN1Gm lG1Q== X-Gm-Message-State: AKS2vOyV63g6onsT+N80fecit1ujne0zmZdZi4H636VL18oZ++7gxt4Z zOXSty11QqV6SVL6 X-Received: by 10.36.211.69 with SMTP id n66mr15606295itg.36.1497725185363; Sat, 17 Jun 2017 11:46:25 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id c31sm3219550ioj.53.2017.06.17.11.46.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 17 Jun 2017 11:46:24 -0700 (PDT) From: npostavs@users.sourceforge.net To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: Date: Sat, 17 Jun 2017 14:48:02 -0400 In-Reply-To: (Philipp Stephani's message of "Sat, 17 Jun 2017 13:10:20 +0000") Message-ID: <8760fusb6l.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Philipp Stephani writes: > It's possible to fix this (see attached patch), but at the expense of > breaking other valid use cases such as (cl-incf (buffer-local-value ...)). > Not sure whether the bug can be fixed at all without breaking other > stuff. I don't really understand the internals of the gv expander stuff, but maybe we could special case the fix to cl-letf? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 18 00:17:25 2017 Received: (at 26624) by debbugs.gnu.org; 18 Jun 2017 04:17:25 +0000 Received: from localhost ([127.0.0.1]:53890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMReP-00017h-Jq for submit@debbugs.gnu.org; Sun, 18 Jun 2017 00:17:25 -0400 Received: from mout.web.de ([212.227.15.14]:65283) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMReO-00017R-3N for 26624@debbugs.gnu.org; Sun, 18 Jun 2017 00:17:24 -0400 Received: from drachen.dragon ([94.217.115.1]) by smtp.web.de (mrweb001 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LjrYH-1dxQE137Mn-00boID; Sun, 18 Jun 2017 06:17:16 +0200 From: Michael Heerdegen To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: Date: Sun, 18 Jun 2017 06:17:15 +0200 In-Reply-To: (Philipp Stephani's message of "Sat, 17 Jun 2017 13:10:20 +0000") Message-ID: <87zid6udys.fsf@drachen> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:aF+2szGBEimTzgeYChOaEfxW3/gZkZZbgcuLk8fBYC6p8YRtAO9 XTuWv9k6Ebvyj8l7ItiGUbAL4ncKwr9QHe5AlX+2XAVPKK8591eGpvFDx4O2rhlRje6hpbb JraUn4BBArQ6hG21EO9tjUdqKBbIwiNx4uB8uoXDJV4Jy0bdn69/SAaYXPOoxa2M7x9F8DY z4XQbjqu8FV5b8Up2ZaaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:lD1PgugGPlY=:tkUmIuUZx2aZxYDb5RbBe8 HgjLRmGnxWz2WSqK5qypzc7nZl/Z/7rOgB/VZxfmwvd8MSEd+ppl49oXHRjYO0JeKlu7X6heJ wKiGkshme1VVnYm2Z5I+ylis7FYlJ7ffuNY1i6BpAIIz5i7C5tyL4VLr+mBT1YU/h5HFZQc3K ihYDEf+mxbNGY/2q8NGnZAyHNr686ZrnvcbLXvNIP4H3Jt1BrBsS/wI/tCPxmMWhKObO074mn vBuJtn0nPhFvE6ojtusYw19KSBxI9aAVG6/3PSLl4oGvN+a5xn7g9x6oogC2XPNRl0rJ50clb y9YzS1a+LcZWMUYh3rTcJlc9BroN7EslHliNbPFCIEmOdfEohrGTdRoie+iyBnoHJypgqd2wl KJCPbIYUQVoY1KAJQClSR6Arb1go52GTpMufDkp7zTwmwkHU7dIA+OM+2ZTnlHrmTcpxK6o7S fkyEzxoxHI8et98wYykCZBvP52L/INP8Mmo9s6SF674jJphRi7zAGc0ux4TKM8N6yMtEWN/fa ptxy3O1DvVYifKI/6n8p7SkGS923Di8ZJ5YmB041wa//t1VVC4ta/pFMKhfwVmuNYJHY9Utws PjWrO0LmU+2TdaLOv0776yP5qql9EYCKZ9pAZVLpGwS9BCtIKexf/FTt2i310Z5bHxpdlGISH Dh/Qvfybj8Y1DHkqj071oGs+iHt1uusb2/5ncZHeTbcu4PUtJ2RnFQR0MKxnshtt7xIgUBjgJ 0OEPbBKd0pwX7XKD3S3OM9eQC36PmUbB84jT41Bbjt8WodVTWu46ELrwDCSKC4lJEp5wU2qq6 FB29NqY X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) Philipp Stephani writes: > It's possible to fix this (see attached patch), but at the expense of > breaking other valid use cases such as (cl-incf (buffer-local-value > ...)). Not sure whether the bug can be fixed at all without breaking > other stuff. I have no solution, but some thoughts. The more I think about it, the more I come to the conclusion that `buffer-local-value' does not have a well defined according place. The function `buffer-local-value' is not injective: it maps different states to the same value because it can't express whether the VARIABLE's binding is buffer-local or not. But we need this information because we need to undo creating a buffer local binding in the setter when closing the `letf'. And the setter, accepting only a value for the binding, isn't surjective, because the argument doesn't hold any information of buffer-localness. Moreover, we want the setter to always create a buffer-local binding in one situation (setf), but this isn't true for the setter we need to use for `cl-letf'. We could widen the semantics of `cl-letf' to do what we want in this case, but I'm not sure if it's worth the trouble. Not if there are more cases like this. BTW, a completely different point of view would be to argument like this: the manual describes generalized variables as "one of the many places in Lisp memory where values can be stored". If variable X has no buffer local binding in some buffer B, that place in Lisp memory is the one that holds the global binding of X. That means that the place expression (buffer-local-binding X B) is equivalent to the place expression X. OTOH, If X has a buffer local binding in B, we can use X as getter expression and `setq' as setter, so the place expression (buffer-local-binding X B) is also equivalent to X. So it is always equivalent to just X and of no use. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 12:53:51 2017 Received: (at 26624) by debbugs.gnu.org; 2 Jul 2017 16:53:51 +0000 Received: from localhost ([127.0.0.1]:48957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRi87-0007dD-HZ for submit@debbugs.gnu.org; Sun, 02 Jul 2017 12:53:51 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:36748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRi86-0007cy-3F for 26624@debbugs.gnu.org; Sun, 02 Jul 2017 12:53:50 -0400 Received: by mail-oi0-f47.google.com with SMTP id x187so10236105oig.3 for <26624@debbugs.gnu.org>; Sun, 02 Jul 2017 09:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FjlZdnO1Jn5HbS6Y8ot5ANMkbLGaDNbC3TUZUkP+jZA=; b=qUbdwQ5VqJJksbVQuHFE6vOs8IueXlqu2lvo2STR/0uEWNzuQEksTBPVSpjkuzFfy9 pciZBRoUYPYmuoSMfC/F46idUe5my3tEHZXu9VLfulwdRZLFAcnm8JG/qjyrslGuNJYM v+VefXTg332IvvdHLnDdtYOex67+ISH2KeTIQcEXQimRmkupXGfOsbpimEFWJ3+tAE5W iMntdUch5X3oQsultPk9RCpyJbSam7M2iOOxm0lEJe1YAeG2cXnLrIN3oWYGxWbw0fHp jJyDVtikSBH59RScgi9AnrfuTeKXQr7HfTxGTzueIi3HEC0mZtnYAOQOhD3tHi6B4FaT ODsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FjlZdnO1Jn5HbS6Y8ot5ANMkbLGaDNbC3TUZUkP+jZA=; b=oJZZ1Akv0+ylB14tkzu9tVRI9N2wWHaQg7rADdUS+l/icWOSHq2j3Isgidd3S2hglO 4viyIaRl1oF3/Ewmdj50BVPmGlB5SfG82mLavRTgufOPzqow9K+oCGhK4tp/+K6LNu+H xGATlojvplRScgrpP7Te0X3560TkV835/RT5GGVvBPBF1vXsdJ1HH7xRGH7QS4BXuELR B2UhHHaOlZeIcD9ob/V2ezC6CxnC7ReoqfbfraTMda9KW/34218RQ+hQbOxNghrK38A3 z6aCqt3ep5oViEbDv1KePm83PrTZ3n8T748MXZB9M5SQCyTCcM42NK0C81UEX/B4dolN wsmQ== X-Gm-Message-State: AKS2vOxjAuHyEIbafgI3qwmcJ6kSlauDCe850/XocTC93EdLUqHaP3VL TIVIRADBCppjovSWrCaiB5S8O6eYSw== X-Received: by 10.202.244.215 with SMTP id s206mr15714689oih.25.1499014424281; Sun, 02 Jul 2017 09:53:44 -0700 (PDT) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> In-Reply-To: <87zid6udys.fsf@drachen> From: Philipp Stephani Date: Sun, 02 Jul 2017 16:53:33 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Michael Heerdegen Content-Type: multipart/alternative; boundary="001a1137da0645c6110553587e7d" X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) --001a1137da0645c6110553587e7d Content-Type: text/plain; charset="UTF-8" Michael Heerdegen schrieb am So., 18. Juni 2017 um 06:17 Uhr: > Philipp Stephani writes: > > > It's possible to fix this (see attached patch), but at the expense of > > breaking other valid use cases such as (cl-incf (buffer-local-value > > ...)). Not sure whether the bug can be fixed at all without breaking > > other stuff. > > I have no solution, but some thoughts. > > The more I think about it, the more I come to the conclusion that > `buffer-local-value' does not have a well defined according place. > > The function `buffer-local-value' is not injective: it maps different > states to the same value because it can't express whether the VARIABLE's > binding is buffer-local or not. But we need this information because we > need to undo creating a buffer local binding in the setter when closing > the `letf'. > > And the setter, accepting only a value for the binding, isn't > surjective, because the argument doesn't hold any information of > buffer-localness. Moreover, we want the setter to always create a > buffer-local binding in one situation (setf), but this isn't true for > the setter we need to use for `cl-letf'. > > We could widen the semantics of `cl-letf' to do what we want in this > case, but I'm not sure if it's worth the trouble. Not if there are more > cases like this. > > Thanks for this great analysis. Given this, it seems that the place definition for `buffer-local-value' should be removed from gv.el. --001a1137da0645c6110553587e7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am So., 18. Juni 2017 um 06:17=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> writes:<= br>
> It's possible to fix this (see attached patch), but at the expense= of
> breaking other valid use cases such as (cl-incf (buffer-local-value > ...)). Not sure whether the bug can be fixed at all without breaking > other stuff.

I have no solution, but some thoughts.

The more I think about it, the more I come to the conclusion that
`buffer-local-value' does not have a well defined according place.

The function `buffer-local-value' is not injective: it maps different states to the same value because it can't express whether the VARIABLE&= #39;s
binding is buffer-local or not.=C2=A0 But we need this information because = we
need to undo creating a buffer local binding in the setter when closing
the `letf'.

And the setter, accepting only a value for the binding, isn't
surjective, because the argument doesn't hold any information of
buffer-localness.=C2=A0 Moreover, we want the setter to always create a
buffer-local binding in one situation (setf), but this isn't true for the setter we need to use for `cl-letf'.

We could widen the semantics of `cl-letf' to do what we want in this case, but I'm not sure if it's worth the trouble.=C2=A0 Not if ther= e are more
cases like this.


Thanks for this great analysis. Given = this, it seems that the place definition for `buffer-local-value' shoul= d be removed from gv.el.
--001a1137da0645c6110553587e7d-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 24 11:20:07 2017 Received: (at 26624) by debbugs.gnu.org; 24 Sep 2017 15:20:07 +0000 Received: from localhost ([127.0.0.1]:56190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw8hS-0003qv-Ty for submit@debbugs.gnu.org; Sun, 24 Sep 2017 11:20:07 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:43163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw8hR-0003qN-CV for 26624@debbugs.gnu.org; Sun, 24 Sep 2017 11:20:05 -0400 Received: by mail-oi0-f47.google.com with SMTP id r20so3968923oie.0 for <26624@debbugs.gnu.org>; Sun, 24 Sep 2017 08:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ji/VPHfdq55Tb01Vq5gLI1VO3Ktml5S6YMwlgJqaSs=; b=c9Hd6fGvgc5tA9DkgANwt/e7qbsTbkaTZf+iV9Bli0ESK9QpB0uOCIEnk0khYrGzH3 3qRlhlxJy3OTkpu8cZxYvSFVQVy93J09FixslLp2pr3+nhjAXRIGnFWMyPTF3CDShfnE 8WidLZKPjrPz7Qv1FFIdSS/6FZ+ctwKSR4rPp4sxOMft6HPvsBeZN6PgnaW9qPZCver5 iN1KTvj9bAYsTzMZ93mF/B3/7cozz+LdsuSWH4WxfmkOoVVupuAtM3yg9t2ARQuyH5jS 3YmWjatycXT9y8dybntPGOFxORQ7OWKT/LjBHp+4jpjrNIbMkn2bBrv7C6A45+KzuU7r OzXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/ji/VPHfdq55Tb01Vq5gLI1VO3Ktml5S6YMwlgJqaSs=; b=poGAnewRZ61xInZ6U5sPC2cCHgNXEVHi6XnDq+X5EeRxTQvq+RpVQZf6lM6wJJspXR UAYQzY/VC1RzEOM3ayaIdsxywAS6uKIvxDPUxw4qrLmckdzKJvmWvn/rnq0Lp1vILXFf H3ZSz4rUCbdz1vV/d7LztzINIQRU4TfScO4+JYdEepquTP4T1TemhARtZtZl8v1uNufV ODjBPB/rM0d54MmliFdnCcT4A8BUaOpS7GR1SIIPI1h7pfL+ZgyV3JqO8TpvGz3d37sJ rZ/6Tcnrbww2mF1GCrApmQh+5dXz6E1uGdUket2SGJbpNskTveJLpz0pRA08CrqjOAgy AmFw== X-Gm-Message-State: AHPjjUhDnL+JGdVlo/EUoivxjf4W7i+kqBtwtJSjVr5hVnnqfN0BTic0 bFq9ZxH1MaFFlTqrurIy92gQ2vviTcUD9vCJ1P0= X-Google-Smtp-Source: AOwi7QDlEY5Qb2bsbFPddrEqZ/OI1goMv73dy/DKHQXxgfPEIX+jEaACDg2HQIfTDDbRzEVUYfSV0yzjUFESvCfgMI4= X-Received: by 10.202.57.130 with SMTP id g124mr5429301oia.296.1506266399466; Sun, 24 Sep 2017 08:19:59 -0700 (PDT) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> In-Reply-To: From: Philipp Stephani Date: Sun, 24 Sep 2017 15:19:48 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Michael Heerdegen Content-Type: multipart/mixed; boundary="001a113cde84ade0fb0559f0f93d" X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.0 (--) --001a113cde84ade0fb0559f0f93d Content-Type: multipart/alternative; boundary="001a113cde84ade0f70559f0f93b" --001a113cde84ade0f70559f0f93b Content-Type: text/plain; charset="UTF-8" Philipp Stephani schrieb am So., 2. Juli 2017 um 18:53 Uhr: > Michael Heerdegen schrieb am So., 18. Juni > 2017 um 06:17 Uhr: > >> Philipp Stephani writes: >> >> > It's possible to fix this (see attached patch), but at the expense of >> > breaking other valid use cases such as (cl-incf (buffer-local-value >> > ...)). Not sure whether the bug can be fixed at all without breaking >> > other stuff. >> >> I have no solution, but some thoughts. >> >> The more I think about it, the more I come to the conclusion that >> `buffer-local-value' does not have a well defined according place. >> >> The function `buffer-local-value' is not injective: it maps different >> states to the same value because it can't express whether the VARIABLE's >> binding is buffer-local or not. But we need this information because we >> need to undo creating a buffer local binding in the setter when closing >> the `letf'. >> >> And the setter, accepting only a value for the binding, isn't >> surjective, because the argument doesn't hold any information of >> buffer-localness. Moreover, we want the setter to always create a >> buffer-local binding in one situation (setf), but this isn't true for >> the setter we need to use for `cl-letf'. >> >> We could widen the semantics of `cl-letf' to do what we want in this >> case, but I'm not sure if it's worth the trouble. Not if there are more >> cases like this. >> >> > Thanks for this great analysis. Given this, it seems that the place > definition for `buffer-local-value' should be removed from gv.el. > Here's a patch that does just that. --001a113cde84ade0f70559f0f93b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am So., 2. Juli 2017 um 18:53=C2=A0Uhr:
Michael Heerdegen <michael_heerdegen@web.de> schrieb am So., 18. Jun= i 2017 um 06:17=C2=A0Uhr:
Philipp = Stephani <p.s= tephani2@gmail.com> writes:

> It's possible to fix this (see attached patch), but at the expense= of
> breaking other valid use cases such as (cl-incf (buffer-local-value > ...)). Not sure whether the bug can be fixed at all without breaking > other stuff.

I have no solution, but some thoughts.

The more I think about it, the more I come to the conclusion that
`buffer-local-value' does not have a well defined according place.

The function `buffer-local-value' is not injective: it maps different states to the same value because it can't express whether the VARIABLE&= #39;s
binding is buffer-local or not.=C2=A0 But we need this information because = we
need to undo creating a buffer local binding in the setter when closing
the `letf'.

And the setter, accepting only a value for the binding, isn't
surjective, because the argument doesn't hold any information of
buffer-localness.=C2=A0 Moreover, we want the setter to always create a
buffer-local binding in one situation (setf), but this isn't true for the setter we need to use for `cl-letf'.

We could widen the semantics of `cl-letf' to do what we want in this case, but I'm not sure if it's worth the trouble.=C2=A0 Not if ther= e are more
cases like this.


Thanks for this great analysis. Given this, it seems that= the place definition for `buffer-local-value' should be removed from g= v.el.

Here's a patch = that does just that.=C2=A0
--001a113cde84ade0f70559f0f93b-- --001a113cde84ade0fb0559f0f93d Content-Type: text/plain; charset="US-ASCII"; name="0001-Remove-buffer-local-value-as-generalized-variable-Bug-.txt" Content-Disposition: attachment; filename="0001-Remove-buffer-local-value-as-generalized-variable-Bug-.txt" Content-Transfer-Encoding: base64 Content-ID: <15eb47905e1322133aa1> X-Attachment-Id: 15eb47905e1322133aa1 RnJvbSA0YWQzMDU4NDc2YmRjN2Y1ZmE3ZTYwZDkxYzI0MGE2M2UxZjVmNzNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IEZyaSwgMTYgSnVuIDIwMTcgMjI6NTU6NTIgKzAyMDAKU3ViamVjdDogW1BBVENIXSBSZW1v dmUgYGJ1ZmZlci1sb2NhbC12YWx1ZScgYXMgZ2VuZXJhbGl6ZWQgdmFyaWFibGUKIChCdWcjMjY2 MjQpCgoqIGxpc3AvZW1hY3MtbGlzcC9ndi5lbCAoYnVmZmVyLWxvY2FsLXZhbHVlKTogUmVtb3Zl LgoqIGxpc3AvZmlsZXMuZWwgKGZpbGUtbmFtZS1ub24tc3BlY2lhbCk6IFJlbW92ZSBhIHN0YWxl IGNvbW1lbnQuCi0tLQogZXRjL05FV1MgICAgICAgICAgICAgIHwgNyArKysrKysrCiBsaXNwL2Vt YWNzLWxpc3AvZ3YuZWwgfCA0IC0tLS0KIGxpc3AvZmlsZXMuZWwgICAgICAgICB8IDIgLS0KIDMg ZmlsZXMgY2hhbmdlZCwgNyBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp dCBhL2V0Yy9ORVdTIGIvZXRjL05FV1MKaW5kZXggYWFjZGY3OWI1Ny4uNWI4NzkzOWNmNyAxMDA2 NDQKLS0tIGEvZXRjL05FV1MKKysrIGIvZXRjL05FV1MKQEAgLTUxLDYgKzUxLDEzIEBAIHNldHMg dGhlIFhUZXJtIHdpbmRvdyB0aXRsZS4gIFRoZSBkZWZhdWx0IGlzIHRvIHNldCB0aGUgd2luZG93 IHRpdGxlLgogKiogVGhlIEZJTEVOQU1FIGFyZ3VtZW50IHRvICdmaWxlLW5hbWUtYmFzZScgaXMg bm93IG1hbmRhdG9yeSBhbmQgbm8KIGxvbmdlciBkZWZhdWx0cyB0byAnYnVmZmVyLWZpbGUtbmFt ZScuCiAKKyoqICdidWZmZXItbG9jYWwtdmFsdWUnIGlzIG5vIGxvbmdlciBhIGdlbmVyYWxpemVk IHZhcmlhYmxlLiAgVGhpcyBpcworYmVjYXVzZSB0aGUgYnVmZmVyLWxvY2FsIHZhbHVlIG9mIGEg dmFyaWFibGUgYWx3YXlzIGNvbnNpc3RzIG9mIHR3bworcGllY2VzOiB0aGUgYWN0dWFsIHZhbHVl IG9mIHRoZSB2YXJpYWJsZSwgYW5kIHdoZXRoZXIgaXQgaXMKK2J1ZmZlci1sb2NhbC4gIEJ1dCAn YnVmZmVyLWxvY2FsLXZhbHVlJyByZXR1cm5zIG9ubHkgb25lIHBpZWNlIG9mCitpbmZvcm1hdGlv biwgd2hpY2ggaXMgbm90IGVub3VnaCBmb3IgYSBnZW5lcmFsaXplZCB2YXJpYWJsZS4gIEluCitw YXJ0aWN1bGFyLCAnY2wtbGV0ZicgY2FuJ3QgYmUgbWFkZSB0byB3b3JrIHdpdGggJ2J1ZmZlci1s b2NhbC12YWx1ZScuCisKIAwKICogTGlzcCBDaGFuZ2VzIGluIEVtYWNzIDI3LjEKIApkaWZmIC0t Z2l0IGEvbGlzcC9lbWFjcy1saXNwL2d2LmVsIGIvbGlzcC9lbWFjcy1saXNwL2d2LmVsCmluZGV4 IDg5MmQ2ZTk3MTYuLmY1MDRjYTQzYjAgMTAwNjQ0Ci0tLSBhL2xpc3AvZW1hY3MtbGlzcC9ndi5l bAorKysgYi9saXNwL2VtYWNzLWxpc3AvZ3YuZWwKQEAgLTM2NywxMCArMzY3LDYgQEAgc2V0Zgog KGd2LWRlZmluZS1zZXR0ZXIgd2luZG93LXBvaW50ICh2ICZvcHRpb25hbCB3KSBgKHNldC13aW5k b3ctcG9pbnQgLHcgLHYpKQogKGd2LWRlZmluZS1zZXR0ZXIgd2luZG93LXN0YXJ0ICh2ICZvcHRp b25hbCB3KSBgKHNldC13aW5kb3ctc3RhcnQgLHcgLHYpKQogCi0oZ3YtZGVmaW5lLXNldHRlciBi dWZmZXItbG9jYWwtdmFsdWUgKHZhbCB2YXIgYnVmKQotICAobWFjcm9leHAtbGV0MiBuaWwgdiB2 YWwKLSAgICBgKHdpdGgtY3VycmVudC1idWZmZXIgLGJ1ZiAoc2V0IChtYWtlLWxvY2FsLXZhcmlh YmxlICx2YXIpICx2KSkpKQotCiAoZ3YtZGVmaW5lLWV4cGFuZGVyIGFsaXN0LWdldAogICAobGFt YmRhIChkbyBrZXkgYWxpc3QgJm9wdGlvbmFsIGRlZmF1bHQgcmVtb3ZlIHRlc3RmbikKICAgICAo bWFjcm9leHAtbGV0MiBtYWNyb2V4cC1jb3B5YWJsZS1wIGsga2V5CmRpZmYgLS1naXQgYS9saXNw L2ZpbGVzLmVsIGIvbGlzcC9maWxlcy5lbAppbmRleCBmZTdjYjFhOGE5Li40YmI2MTFhM2JhIDEw MDY0NAotLS0gYS9saXNwL2ZpbGVzLmVsCisrKyBiL2xpc3AvZmlsZXMuZWwKQEAgLTcwMDUsOCAr NzAwNSw2IEBAIGZpbGUtbmFtZS1ub24tc3BlY2lhbAogICAgICAgICAgICAod2hlbiAoYW5kIHZp c2l0IGJ1ZmZlci1maWxlLW5hbWUpCiAgICAgICAgICAgICAgKHNldHEgYnVmZmVyLWZpbGUtbmFt ZSAoY29uY2F0ICIvOiIgYnVmZmVyLWZpbGUtbmFtZSkpKSkpKQogICAgICAgKGB1bnF1b3RlLXRo ZW4tcXVvdGUKLSAgICAgICA7OyBXZSBjYW4ndCB1c2UgYGNsLWxldGYnIHdpdGggYChidWZmZXIt bG9jYWwtdmFsdWUpJyBoZXJlCi0gICAgICAgOzsgYmVjYXVzZSBpdCB3b3VsZG4ndCB3b3JrIGR1 cmluZyBib290c3RyYXBwaW5nLgogICAgICAgIChsZXQgKChidWZmZXIgKGN1cnJlbnQtYnVmZmVy KSkpCiAgICAgICAgICA7OyBgdW5xdW90ZS10aGVuLXF1b3RlJyBpcyBvbmx5IHVzZWQgZm9yIHRo ZQogICAgICAgICAgOzsgYHZlcmlmeS12aXNpdGVkLWZpbGUtbW9kdGltZScgYWN0aW9uLCB3aGlj aCB0YWtlcyBhIGJ1ZmZlcgotLSAKMi4xNC4xCgo= --001a113cde84ade0fb0559f0f93d-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 24 11:36:21 2017 Received: (at 26624) by debbugs.gnu.org; 24 Sep 2017 15:36:21 +0000 Received: from localhost ([127.0.0.1]:56212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw8xA-0004FH-Sm for submit@debbugs.gnu.org; Sun, 24 Sep 2017 11:36:21 -0400 Received: from mout.web.de ([217.72.192.78]:61143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw8x8-0004F2-QN for 26624@debbugs.gnu.org; Sun, 24 Sep 2017 11:36:19 -0400 Received: from drachen.dragon ([92.74.174.244]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MbQOe-1ddNc70ttM-00IjuC; Sun, 24 Sep 2017 17:36:11 +0200 From: Michael Heerdegen To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> Date: Sun, 24 Sep 2017 17:36:10 +0200 In-Reply-To: (Philipp Stephani's message of "Sun, 24 Sep 2017 15:19:48 +0000") Message-ID: <87shfc6rdh.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:IznenLns+5iDNWjC46P5uqUwfI+M+rqMrLHyIyN3sdSt9SRIHVI J58soc6riZb6jxwPOiAbemATYxvioOWwslYRf7RVCF6ZYVGFyrbQhGDCS/nI+rPVBuyMTxG zQYzp6y6m0u+hj+SoCINqx1rReYovIBuxj9F8z5ezNvdtdenHuz16YUupz1ri3Nj0M5M+qT zxkoDlkkcUDP48CoXlGzQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:sntjL0OxaXU=:ZeHw88gOgRVyidv9J2TtLe 2uMIxFBtGDVdAqsHhxzq2t98m0escCEX+hNnmEZ//wCZKA4fUlA2QsTldQ1iZ2Ze5vDuftH26 ti22Y+MZtPZ6WWDHDwCQf78XNT2DJua7cTN7sXbQxZpxceVrTWAuH41Mp7gl9qxe59dV1gtTv gArxnGoyal/CNvWlgcYYYOjQV6dJcxyYY/Z3Km7rsrPYjjUEY0PPTLQ+o3IuXWtDW9ACcImbO BZJHuVLWt5vkY4nMclw5DpaNpHE2wu955vt3jgGjkUqxEzSmH/2kOsOl92RclSi47CuGeO9mX BMuIwBP768w7ylYno1pVzYR/SOTmvtaG5U0mnTmnanDIFwnrPtiQukPeH2PG30i7Cu+8pgLHG WNI51ECLUajSqTEAbsDusG/jpkw9/ro3XPLnkITb22eZKgqnJ+0MwKgWZFNIFLVFTTGV2n9/R Xl2zeVd4j9pHcIjrYfNLyJ6/6is6yNWs3vro7RUUWn9SVzpQZtw9Ye1cXA4Wc3MWxdUONJ3WK GXzGcG8skCj/BhmuMuuldgZdo//5sP6KtBz8Xv1BmhklkT49ioXBRZzY7IQ98xlMFzFqxa/9v kkWNjETU88vjVJ9+E3hxrfgccVjQgQYKwb+p04aWDePVAORwM96s0E9O91+hE+t+gq0aRmzwi CdlEBlnwsmK8qQBfySzaXsEUk073YBza72CyXf4297qQFATkcfxWI5cFCGgO0OLZ9n9Wq4ke2 wnu6lXA6NFx3uwjl8iBiJVF8anjgavL+VuuwmZi+ZJuj0YLCf/jSNgEBw3ki2LlLBBOxt2rfx WQnk9fGmm5qrC1MXQ1/57szE4WwVxDk+p8E1FlVgo6guXmDuTY= X-Spam-Score: -3.5 (---) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) Philipp Stephani writes: > Here's a patch that does just that. Thanks. Looks good to me. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 24 11:45:02 2017 Received: (at 26624) by debbugs.gnu.org; 24 Sep 2017 15:45:02 +0000 Received: from localhost ([127.0.0.1]:56222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw95a-0004RW-0J for submit@debbugs.gnu.org; Sun, 24 Sep 2017 11:45:02 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:52534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw95Y-0004Qo-83 for 26624@debbugs.gnu.org; Sun, 24 Sep 2017 11:45:00 -0400 Received: by mail-io0-f169.google.com with SMTP id i197so7864000ioe.9 for <26624@debbugs.gnu.org>; Sun, 24 Sep 2017 08:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=L+StrcEixdbUAynsHi23cDuxqjk3/sJKIRpmhgbE8JY=; b=aeiPFCDEPxG1+gxAX2I5r6pZZ1wI8ysf0KPUL5bVzyBVP7iMcqynshMQBupy6dLjTs LoVkX1TvK5WJn+2sV+XL9+t0Q48Mgk3QjGArxiQYPCM3HeTvPwBch2+xl+JJVXHdmzNx 8szBrOQWJrqbFbv69U3rZIyogG8TTnqppNt69ouoehN/Lg/ZfGFz0u+6mrgo5fdnalh2 pXXFqhZl8O4e7FaXPLTWGubGzrDfBwxeoRXKpC67Egn6ME3F5HXpTajqKDkpUPLcOfFK Ve0fK/5AhNNcYgdK4Wc4fkfH0PNvQs8GNDmSAIXMFbulpb3nb/9163lR3gytlnF6X+0w 2JOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=L+StrcEixdbUAynsHi23cDuxqjk3/sJKIRpmhgbE8JY=; b=FIuKFgQ3MW//N3mFp3tIo4560/JODugYzrQm/aDL523G7YZipNHkTUen2jNfXTCSdf 2YyOislZuuxFK06N4s23D2OiJtd6FghwUPVyZl685u82BC9KkdT+SXvHUnr0AWV5hNdH IOIi1MhQwVpU5H5BY8uEqSYGKFNjIiiCc6+U9wUKmiyHafoNtOaE08+j71EcC5b5ojyp u4EsqDRcUFGOL77U7qP3XjGoBsDdRfHRoV9R7zrQZ4+F5P3tjWhCoDPu0U2qN7WR9XAQ 8rGo9ktU5651CAy3ck0k0vCQVfNA5yBKTej/0wl2KQvVSdneTI/Y2dma5/4xBQV1ostl CRSw== X-Gm-Message-State: AHPjjUgNoTS0pnAcZqVkr0M94ESsBzm4GeuAon4qEtKwk2YutrwCgS4u bcNZnZZNfElVfR359a1Iez/OPw== X-Google-Smtp-Source: AOwi7QBUIcflOe9YP96j7JG2DwH2ku3YJB1rQ+zsmqMNGj8RAReS3nQTDZQE6B5KVzWD54gOyO2rkw== X-Received: by 10.107.1.16 with SMTP id 16mr2938326iob.211.1506267894507; Sun, 24 Sep 2017 08:44:54 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id e68sm2009198itc.21.2017.09.24.08.44.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Sep 2017 08:44:53 -0700 (PDT) From: Noam Postavsky To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> Date: Sun, 24 Sep 2017 11:44:53 -0400 In-Reply-To: (Philipp Stephani's message of "Sun, 24 Sep 2017 15:19:48 +0000") Message-ID: <87o9q0m77u.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 26624 Cc: Michael Heerdegen , 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Philipp Stephani writes: > * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. Is it possible to just give an obsolete warning first? From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 24 12:42:35 2017 Received: (at 26624) by debbugs.gnu.org; 24 Sep 2017 16:42:35 +0000 Received: from localhost ([127.0.0.1]:56288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw9zH-0005nu-Cp for submit@debbugs.gnu.org; Sun, 24 Sep 2017 12:42:35 -0400 Received: from mail-oi0-f52.google.com ([209.85.218.52]:50333) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw9zF-0005nf-I1 for 26624@debbugs.gnu.org; Sun, 24 Sep 2017 12:42:33 -0400 Received: by mail-oi0-f52.google.com with SMTP id w65so4088092oia.7 for <26624@debbugs.gnu.org>; Sun, 24 Sep 2017 09:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hm0KUgi+nPcyPY1jbtBoirB6/SzMTsPvz7dP7C5OGv8=; b=iUr257ODYN2hXLfB79Wzskz28h9DqLZos5DyTtAZ7dcQWBZgdOFNChUGqZgTvjY/0T 1wdEM6L1Et8FjVOEast8cgWulKMqMZ3ebKjwSH812xB+U+612XTo/n2geDo7GMWhgPtO DQDV7wj+fpPzR6wQRvXfP9PtS2kNPGTnyW8HTMZ48FW3Ubob/pg5SjkqMUyu+kUKRzog 3lo5JuL03jb3eHRejwdMFVBWmfG3caj3gM8AS08id5gPLurq0jUDvT4KGC4feEKZRZhC bPG9wYQlhmyQlj6WhPRhGzh91qMTFkwCfvMBh15g8NjvvahBBKNJcX0Mpu0ECmTdcNf8 r9jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hm0KUgi+nPcyPY1jbtBoirB6/SzMTsPvz7dP7C5OGv8=; b=FYnnLv+sJooxjcnm1NEsi4B5YvH/zJdJOvNBTI2ufMbsR8C/Pi9sIMLrPakPm2AIbU AjUj5SC/0xDl47FWTnZYkc7gub8CQqvZ3uwueaFoB51Vd6NSlpnMnpYQs+RZxvhsGgWB g9otHR/F2co3g6K1AhspkkkQNuNjbD+3e2ii1WoRLZIuLk/IeLrko5fOvDCXJhy8YnZB QCxahQcvXgS1mcqNHmx9r6pAJPqbfrrcUroCf6JJTgVKI7rkcJCi2htuD9J1pIYXKd/W ees8nRWzOULa/Bpsy6aT9anukPgkzXcx637sY6xnmo2dIU8qJ89tWAWj/bgG/yPvNooy anzw== X-Gm-Message-State: AHPjjUifd7tcU4qNXspkNAlJOfR418Js6KPlI/PdhJoZDpHnRRttVMjM tIKhXEC8zSxB49qMszvQqmiC17PcCt/jq3Q//+w= X-Google-Smtp-Source: AOwi7QChUNAXakxXwEADNkfWYJXFoNPwmN80GiIOaAtGyisVMZdh4aMVMX1R0BuJl+DDEQmtwETHp+50/2T5Q4Qu/4g= X-Received: by 10.202.57.130 with SMTP id g124mr5629895oia.296.1506271343331; Sun, 24 Sep 2017 09:42:23 -0700 (PDT) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> In-Reply-To: <87o9q0m77u.fsf@users.sourceforge.net> From: Philipp Stephani Date: Sun, 24 Sep 2017 16:42:12 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Noam Postavsky Content-Type: multipart/alternative; boundary="001a113cde845acfb10559f22020" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: Michael Heerdegen , 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --001a113cde845acfb10559f22020 Content-Type: text/plain; charset="UTF-8" Noam Postavsky schrieb am So., 24. Sep. 2017 um 17:44 Uhr: > Philipp Stephani writes: > > > * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. > > Is it possible to just give an obsolete warning first? > I don't think it's possible in the sense of `make-obsolete' because the expander is not a named function. It would be possible to use `display-warning' within the body of the setter, but that would only annoy users. If necessary, we might add additional code to the `setf' macro to warn about this form in particular during byte compilation. --001a113cde845acfb10559f22020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Noam P= ostavsky <npostavs@use= rs.sourceforge.net> schrieb am So., 24. Sep. 2017 um 17:44=C2=A0Uhr:=
Philipp Stephani <p.stephani2@gmail.com>= writes:

> * lisp/emacs-lisp/gv.el (buffer-local-value): Remove.

Is it possible to just give an obsolete warning first?

I don't think it's possible in the sense of `make-o= bsolete' because the expander is not a named function.
It wou= ld be possible to use `display-warning' within the body of the setter, = but that would only annoy users.
If necessary, we might add addit= ional code to the `setf' macro to warn about this form in particular du= ring byte compilation.
--001a113cde845acfb10559f22020-- From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 24 13:43:29 2017 Received: (at 26624) by debbugs.gnu.org; 24 Sep 2017 17:43:29 +0000 Received: from localhost ([127.0.0.1]:56396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dwAwD-0007Lx-Kt for submit@debbugs.gnu.org; Sun, 24 Sep 2017 13:43:29 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:44741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dwAwB-0007Li-QU for 26624@debbugs.gnu.org; Sun, 24 Sep 2017 13:43:28 -0400 Received: by mail-it0-f48.google.com with SMTP id d192so4362514itd.1 for <26624@debbugs.gnu.org>; Sun, 24 Sep 2017 10:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=yVrpAdVIeL6ngohBrElec7Kq6qgHLV7xvIpJf7CNxjM=; b=gk3ZPY0qd9ZSu23a7Er0KpKk46vl8Fv6gQU2vFeJ7IDTVNIJ4Wowui8erNVFbw9/0a Oe4LZMj2rJUx5QyJ/vl+35juUwB3/zf0bP2vfhCQrWNB64USr1+zq7t1MnGbcaZjK8Gc Q2MGV8oHA3MknsGJg60WZO8Ad0jdCfw8sxgCk411kahH5tXXqB4HMwpxD9jBQnnx4RsP vcLJ/ukRJwfQ+RkEuaZp+Gi1/nThNMtsMA0rju53W4Qpahcv2WEepuJlgI6CGAxOz8SV AtBjdGlN8K3mOvsU0iR+sB5vJyZKlbdpZqUkcUNEYVmbJHk0pGBlk9WNUTf2z8UZSh7/ HPbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=yVrpAdVIeL6ngohBrElec7Kq6qgHLV7xvIpJf7CNxjM=; b=OMok9lrcOSHbQ2zf+HySbspbjjfMkHgt2Y/LseQuCHmHBCafmWQ78Ca+BNUF9bGYKu BcmTcjEZA5VSlfn89IkW7Fen1xp8dYjRBiWz55/xtxbkJFWw0NcA5SSoEFrVbtozBh25 bf6OAo+hOBrdD+fKmzfGytCrPcKchwNRGW4sa8QewKe6y97K8JVNhgQnt57cK38VMdFG RnobrNU5YLz4/Pp7Fdj7UQbPrdleDy7s1ZsFo+HQOk/aWbhxr19LiZv5cbzyCZWEWzy0 enEfGPH58u/ZwQ631q/fZJuv1VxAnCTN22KY77jvj+TTaAxr7ztHryegYMZ7tEvJm454 ZBnQ== X-Gm-Message-State: AHPjjUjrcx9qCkYBqtFHqXWwdtcwJ/oZmaOsK8nqv2d8lTxDx9XSkY9h Gnwpd2OUFF05qjGSqfd6NVCjww== X-Google-Smtp-Source: AOwi7QDFNL6diuGtvvhWTfmoOEHdHF5TjAbjPlweYVEam8QrynTJgToEfLo0XE3vZDGsPChp8mZavA== X-Received: by 10.36.6.18 with SMTP id 18mr16342860itv.15.1506275002178; Sun, 24 Sep 2017 10:43:22 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id k133sm2508750itd.0.2017.09.24.10.43.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Sep 2017 10:43:21 -0700 (PDT) From: Noam Postavsky To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> Date: Sun, 24 Sep 2017 13:43:20 -0400 In-Reply-To: (Philipp Stephani's message of "Sun, 24 Sep 2017 16:42:12 +0000") Message-ID: <87d16gm1qf.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: Michael Heerdegen , 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Philipp Stephani writes: > Noam Postavsky schrieb am So., 24. > Sep. 2017 um 17:44=C2=A0Uhr: > > Philipp Stephani writes: >=20=20=20=20 > > * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. >=20=20=20=20 > Is it possible to just give an obsolete warning first? > > > I don't think it's possible in the sense of `make-obsolete' because > the expander is not a named function. > It would be possible to use `display-warning' within the body of the > setter, but that would only annoy users. > If necessary, we might add additional code to the `setf' macro to > warn about this form in particular during byte compilation. IMO, a compilation warning would be appropriate. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 29 03:50:56 2017 Received: (at 26624) by debbugs.gnu.org; 29 Sep 2017 07:50:56 +0000 Received: from localhost ([127.0.0.1]:37515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxq4V-0005s2-VE for submit@debbugs.gnu.org; Fri, 29 Sep 2017 03:50:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxq4U-0005rp-7C for 26624@debbugs.gnu.org; Fri, 29 Sep 2017 03:50:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxq4M-0007wl-2M for 26624@debbugs.gnu.org; Fri, 29 Sep 2017 03:50:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxq4L-0007wh-V2; Fri, 29 Sep 2017 03:50:45 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4964 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dxq4L-0000x5-D5; Fri, 29 Sep 2017 03:50:45 -0400 Date: Fri, 29 Sep 2017 10:50:36 +0300 Message-Id: <837ewi9c4z.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: <87d16gm1qf.fsf@users.sourceforge.net> (message from Noam Postavsky on Sun, 24 Sep 2017 13:43:20 -0400) Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 26624 Cc: michael_heerdegen@web.de, p.stephani2@gmail.com, 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Noam Postavsky > Date: Sun, 24 Sep 2017 13:43:20 -0400 > Cc: Michael Heerdegen , 26624@debbugs.gnu.org > > Philipp Stephani writes: > > > Noam Postavsky schrieb am So., 24. > > Sep. 2017 um 17:44 Uhr: > > > > Philipp Stephani writes: > > > > > * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. > > > > Is it possible to just give an obsolete warning first? > > > > > > I don't think it's possible in the sense of `make-obsolete' because > > the expander is not a named function. > > It would be possible to use `display-warning' within the body of the > > setter, but that would only annoy users. > > If necessary, we might add additional code to the `setf' macro to > > warn about this form in particular during byte compilation. > > IMO, a compilation warning would be appropriate. I agree. Removing some feature without due warning is not something we should do, except in very rare cases (which this one isn't). From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 29 16:55:58 2017 Received: (at 26624) by debbugs.gnu.org; 29 Sep 2017 20:55:58 +0000 Received: from localhost ([127.0.0.1]:39711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dy2KE-0002eh-BS for submit@debbugs.gnu.org; Fri, 29 Sep 2017 16:55:58 -0400 Received: from mail-oi0-f52.google.com ([209.85.218.52]:54169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dy2KD-0002eT-AH for 26624@debbugs.gnu.org; Fri, 29 Sep 2017 16:55:57 -0400 Received: by mail-oi0-f52.google.com with SMTP id j126so1322277oia.10 for <26624@debbugs.gnu.org>; Fri, 29 Sep 2017 13:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eM5PM27nc1SO9mYySDTHF8tPaHDDqnTMS377nmO/YGY=; b=FASaE2IhK8RZoXUxR+76g/HavEb7AXi/BVloax0F24mnwVvxLEP4oCPVXLER8aL/QX 77Es0DQaVUWAWIYxAbSrN7FMKIZTUcwI494tIAbP9eOGdl25DUSE+hFZ5nfz70CkBiM9 uu1twO2Yhn9v5nqh3ZOXDuFYvsioDRQfIVDlYZxEdpYFKRVTViDoeg7fcJLBw8aRoiNZ mKDueaa3WVAWp/p+0BmIgnxexA8aWm/Q92qFaKhDr4QvjVUhUTnwj0RX6BOKM+6DYlYR wJ9MZuldjUwiSGJThdDbUT6myC7rJ5TD8gaQRq3rAdwLllKbbECLc/J6DL6u//ZWOWno /D+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eM5PM27nc1SO9mYySDTHF8tPaHDDqnTMS377nmO/YGY=; b=VDBjmn7DYkNtRlolgLuCJjxgGdVokbUIRz6bjvwAR1O+3G4Q2X0VNTeqO8rFvb+6Av HXQRlSAvqVXPlRWEYpjf7I6UdSUqis9e+xm5hBXJIqdLUgHnlF3ShzICyCj6jsEiSaKD 6B5hrjPGJJ++0b3uRFt+P9hA3SwsDdUGY50Bn1SJ9nRnjLQAKbw0zOlS2O2JXOoVP4I0 O3DqDncijc1VWwNXgKWLWu0jI4wb4MAqA644s+cr5krA69NayNl7VFCAThCHNBUjdnkA 7FxAkcyTgDEMfoNYCVVa6sdHZSAvDcBps1gCUAVXsOcNIeADtjeLb46hHgXgZmvJUqop I9Lw== X-Gm-Message-State: AMCzsaXp+L3DnXEb/7fcyNZ8dV1C2jXaFd18FfpWSuMbvRun7T23YEHz g2ma9zIfrqpZpIN7H2FSGdrHEB9cwSHhO/y9x00= X-Google-Smtp-Source: AOwi7QBSGccUvFr1BpDWBZa7+mXLVgGJMgYRFGEKXEiKI9DYcopFcpJ+wxTLdWMkSSYv2ZkCMjDnBLpt5u3Zb1vuZiM= X-Received: by 10.157.66.142 with SMTP id r14mr3231710ote.335.1506718551558; Fri, 29 Sep 2017 13:55:51 -0700 (PDT) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> In-Reply-To: <837ewi9c4z.fsf@gnu.org> From: Philipp Stephani Date: Fri, 29 Sep 2017 20:55:41 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Eli Zaretskii , Noam Postavsky Content-Type: multipart/alternative; boundary="94eb2c1c10020acfba055a5a408c" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: michael_heerdegen@web.de, 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --94eb2c1c10020acfba055a5a408c Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am Fr., 29. Sep. 2017 um 09:51 Uhr: > > From: Noam Postavsky > > Date: Sun, 24 Sep 2017 13:43:20 -0400 > > Cc: Michael Heerdegen , 26624@debbugs.gnu.org > > > > Philipp Stephani writes: > > > > > Noam Postavsky schrieb am So., 24. > > > Sep. 2017 um 17:44 Uhr: > > > > > > Philipp Stephani writes: > > > > > > > * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. > > > > > > Is it possible to just give an obsolete warning first? > > > > > > > > > I don't think it's possible in the sense of `make-obsolete' because > > > the expander is not a named function. > > > It would be possible to use `display-warning' within the body of the > > > setter, but that would only annoy users. > > > If necessary, we might add additional code to the `setf' macro to > > > warn about this form in particular during byte compilation. > > > > IMO, a compilation warning would be appropriate. > > I agree. Removing some feature without due warning is not something > we should do, except in very rare cases (which this one isn't). > I fully agree, but I don't know how to correctly deprecate a generalized variable. Should I add code to the byte compiler to deal with this case explicitly? --94eb2c1c10020acfba055a5a408c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Fr., 29. Sep. 2017 um 09:51=C2=A0Uhr:
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 24 Sep 2017 13:43:20 -0400
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 26624@debbugs.gnu.org
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > Noam Postavsky <npostavs@users.sourceforge.net> schrieb am So.= , 24.
> > Sep. 2017 um 17:44=C2=A0Uhr:
> >
> >=C2=A0 =C2=A0 =C2=A0Philipp Stephani <p.stephani2@gmail.com> writes:
> >
> >=C2=A0 =C2=A0 =C2=A0> * lisp/emacs-lisp/gv.el (buffer-local-val= ue): Remove.
> >
> >=C2=A0 =C2=A0 =C2=A0Is it possible to just give an obsolete warnin= g first?
> >
> >
> > I don't think it's possible in the sense of `make-obsolet= e' because
> > the expander is not a named function.
> > It would be possible to use `display-warning' within the body= of the
> > setter, but that would only annoy users.
> > If necessary, we might add additional code to the `setf' macr= o to
> > warn about this form in particular during byte compilation.
>
> IMO, a compilation warning would be appropriate.

I agree.=C2=A0 Removing some feature without due warning is not something we should do, except in very rare cases (which this one isn't).

I fully agree, but I don't know how to cor= rectly deprecate a generalized variable. Should I add code to the byte comp= iler to deal with this case explicitly?=C2=A0=C2=A0
--94eb2c1c10020acfba055a5a408c-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 30 02:46:40 2017 Received: (at 26624) by debbugs.gnu.org; 30 Sep 2017 06:46:40 +0000 Received: from localhost ([127.0.0.1]:39885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyBXs-0006jp-Kw for submit@debbugs.gnu.org; Sat, 30 Sep 2017 02:46:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34141) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyBXq-0006jc-QB for 26624@debbugs.gnu.org; Sat, 30 Sep 2017 02:46:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyBXi-0005CB-98 for 26624@debbugs.gnu.org; Sat, 30 Sep 2017 02:46:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyBXi-0005Bo-5W; Sat, 30 Sep 2017 02:46:30 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1745 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dyBXh-0003TU-El; Sat, 30 Sep 2017 02:46:29 -0400 Date: Sat, 30 Sep 2017 09:46:22 +0300 Message-Id: <837ewg65vl.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Fri, 29 Sep 2017 20:55:41 +0000) Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 26624 Cc: michael_heerdegen@web.de, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Philipp Stephani > Date: Fri, 29 Sep 2017 20:55:41 +0000 > Cc: michael_heerdegen@web.de, 26624@debbugs.gnu.org > > I agree. Removing some feature without due warning is not something > we should do, except in very rare cases (which this one isn't). > > I fully agree, but I don't know how to correctly deprecate a generalized variable. Should I add code to the byte > compiler to deal with this case explicitly? If no other idea comes up, yes, I think so. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 26 17:19:53 2017 Received: (at 26624) by debbugs.gnu.org; 26 Dec 2017 22:19:53 +0000 Received: from localhost ([127.0.0.1]:52951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTxZg-0000sJ-Pp for submit@debbugs.gnu.org; Tue, 26 Dec 2017 17:19:52 -0500 Received: from mout.web.de ([212.227.17.12]:51207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTxZf-0000s4-AO for 26624@debbugs.gnu.org; Tue, 26 Dec 2017 17:19:51 -0500 Received: from drachen.dragon ([88.74.120.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0M7bQ3-1eqb3J38qt-00xMgK; Tue, 26 Dec 2017 23:19:34 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> Date: Tue, 26 Dec 2017 23:19:33 +0100 In-Reply-To: <837ewg65vl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Sep 2017 09:46:22 +0300") Message-ID: <871sjhcetm.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:KJYBLe0nQy/Gqy4nUWE4ylJNQk5Iyzdt7exXxNTA16amukQuXBR jBrX2JzUIW20A4T+qygIJJLpYGWWAM8oCYOYp0tyAXdgKFJg4oNmTyeTXfrpgd40v1Xy6dZ Wm1AOUaVcCS1kzew7xjXs7YMCuKAk/f42xgKhj39ucbmWTlHRefep/PJGnvrmMPazkLWlgc Yx5EX5UCCqqvVoBKXJFSA== X-UI-Out-Filterresults: notjunk:1;V01:K0:W45jcZP9hfg=:H+RPOeEU4zAgCECrypVtPC xZ/CXUExt8JLk3V3z+B/y7CAUEH1VVNbBwQ/X9mDhBvD79t3QN8om2tdTBor+ZQF6zC5PReDN dPm18sYccvqjyZYtC3Fr6BmgqtlMRO4BDTRYnAruK780qVu67uEvLTGPWDENEAH88ImsBeYby 1Np+ZSUSaU9lfa5dKs75uRUqdhQJmNwJQnV40n9TvLul2vbvMwjYAm30TPnJce6h5LyEnS6zf hv3TQJ6MbG/voWNru34UOfxxvqFfu6OciDv2x9TP+LzkV8RuXNlmfLZ+qScr9brBjCFNAbrC0 EI9wH0D7WciDwHOKT3HcF1X2VDZMxtme4vRm0bAVae7ru6A0A13leYpFAWgpu4s3xSexvijTC ldsqTBl4o6foeVZKO7c8uiKa5uajIskjivJVWcepNVIDUc+8cxTYVvG8YvlFm4sXGEgni5D5d S6QBooN3DaW4hddqsaeTvQz3K99qwbCweUai0UP+zqE+clsDS+mzMZaho71/pr8+yHRaEBZbZ +ZLtpaNzoTiPO6sIKbAUjkqbP/OiPFYWW70hEcMUATxqmOxTmrrWo59gMAH5bL++KqmyGNFDz 2ccpLAx0QM5b3FopBY83kh2DqDoUQ4tnWCrL0iqtU5vagexnC0O8+K1d8gRu42LSlpo0pw8Tw kqM9roBim5cugk3M3SSS0pVz9DBiZnW23LRBsOGZpFzSCwCxnD3pIv7RIxoJ+PhUIRYGGehOe fD+ox/UnYc0pxbTwuiyUu16gmaS6GkGzPWJWaUnEw9s3ybwUgEHGMy8sh+sZYlmYs8t5a7oyt lyg545lKPI6FX5LkmSVB4ZpSa4tAd0HderT7AecugYbmY4A+nc= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: Philipp Stephani , 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > > I agree. Removing some feature without due warning is not something > > we should do, except in very rare cases (which this one isn't). > > > > I fully agree, but I don't know how to correctly deprecate a > > generalized variable. Should I add code to the byte > > compiler to deal with this case explicitly? > > If no other idea comes up, yes, I think so. I guess it's not really worth the time to implement an infrastructure for gv-expander obsoletion, because we will probably make use of it only every 150 years (estimation). So it could be that nobody wants to do this for quite a while. Would it be acceptable if the gv setter of `buffer-local-value' would just print a warning (i.e., solve it "by hand")? Not perfect, admitted, but still much better than leaving this unfixed. Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 27 11:11:02 2017 Received: (at 26624) by debbugs.gnu.org; 27 Dec 2017 16:11:02 +0000 Received: from localhost ([127.0.0.1]:54041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUEII-0007ko-7u for submit@debbugs.gnu.org; Wed, 27 Dec 2017 11:11:02 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUEIH-0007kW-6a for 26624@debbugs.gnu.org; Wed, 27 Dec 2017 11:11:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eUEI9-0005ib-1s for 26624@debbugs.gnu.org; Wed, 27 Dec 2017 11:10:56 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eUEHt-0005LL-Cb; Wed, 27 Dec 2017 11:10:37 -0500 Received: from [176.228.60.248] (port=4638 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eUEHs-0004Fj-LH; Wed, 27 Dec 2017 11:10:37 -0500 Date: Wed, 27 Dec 2017 18:10:49 +0200 Message-Id: <83po70gnhy.fsf@gnu.org> From: Eli Zaretskii To: Michael Heerdegen In-reply-to: <871sjhcetm.fsf@web.de> (message from Michael Heerdegen on Tue, 26 Dec 2017 23:19:33 +0100) Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> <871sjhcetm.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 26624 Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Michael Heerdegen > Cc: Philipp Stephani , 26624@debbugs.gnu.org, npostavs@users.sourceforge.net > Date: Tue, 26 Dec 2017 23:19:33 +0100 > > I guess it's not really worth the time to implement an infrastructure > for gv-expander obsoletion, because we will probably make use of it only > every 150 years (estimation). So it could be that nobody wants to do > this for quite a while. > > Would it be acceptable if the gv setter of `buffer-local-value' would > just print a warning (i.e., solve it "by hand")? Not perfect, admitted, > but still much better than leaving this unfixed. Is it (better than leaving this unfixed)? In any case, I don't think I understand the suggestion in detail. Can you show a patch or an idea of a patch? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 27 14:54:50 2017 Received: (at 26624) by debbugs.gnu.org; 27 Dec 2017 19:54:50 +0000 Received: from localhost ([127.0.0.1]:54181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUHmr-0000Bn-Q4 for submit@debbugs.gnu.org; Wed, 27 Dec 2017 14:54:49 -0500 Received: from mout.web.de ([212.227.17.11]:55089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUHmq-0000Bb-18 for 26624@debbugs.gnu.org; Wed, 27 Dec 2017 14:54:48 -0500 Received: from drachen.dragon ([88.74.120.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LaTaN-1fEa5K38JD-00mHrg; Wed, 27 Dec 2017 20:54:29 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> <871sjhcetm.fsf@web.de> <83po70gnhy.fsf@gnu.org> Date: Wed, 27 Dec 2017 20:54:28 +0100 In-Reply-To: <83po70gnhy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 27 Dec 2017 18:10:49 +0200") Message-ID: <877et8ymiz.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K0:RTrwNNJjng26sXixncYHjiOl+iQ6AqlO8pi83PLLAVlvaBo34W+ UAk2yKL7qpQtHgs5iz8ukcIUjl6Alogf5i+NlD9Yb/7c6lzJTADqzU2y9OC533orQr6vF8W PhYGd7a6ouy3ANTnm+O7Q1aIuXOK8tbpiimr4DfBFTPnQYfvmI9AcbR85MIQZ23h/AmZdBQ KFWQPwhtogEwg3U43ZhLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:oLv0f94He9I=:bnbiwL7NDvyn4CEDTqLD2o z22Ka/Two+71R1cf8s+yCvyIa4+vvr0N/5a4gNXWWH3ynN1fPlRyCiadt00YXO9fkjtRyVANW oe4cy/8ja+1eRyibAQak7NZVn3mUC5a6B0PG4mCrxe7KwXXuavXIETWKsA/zmFdtG/axIRNpL QeFxvUUk2QyTOxnXCzgD6+4CKHtdq+Z9H7AKmO980jF4X8NZJsDyfAR1bu/WzrmTOkxPE8q9G F6Lpz0a69Irmd8WzFVjk4hghm+sWG3qdXyQC9Eb7BEoCQsUnrsSeJSmWO4PSSJfy9Qiu9kzqL tjxvvI48oq2Pb0pPYrkqk3rlXNbZJQF2LgBAXCKng/rExBvCFqea+Ti3pZPmpCLXoYrQpZZ5J bSuKJI9hGUkAVGhco8R8CJ/rnMf1uGPNv0LSfHg7tnlGq+5k+1lH3BgdQ2Qf4eA6MFTfmdure 90OWsMFXRpq0E5X7PBPlmLUojWQ0Y1jvrKGgLR7S8smrrSfwHaVO1gen2qjAK9RRE4anAc/ps zGnwacYX1tHXxfRJGCtWxpGTsk7V2vnYzY/Olj692XF6l5rWD2kOd8EL3Uya2OmogtBqZsOHH 0s9D66Yzf89A9tjeGxxuNwZSftJwzmOIBjegkzo3+nha19B9q7eFYhRoEe3G58I9qWdJ7AtVA H//A8bQscHFOmdM/fey3u694KPca6HjGGim4V+QSGZYtayimLXvtZNH6bNQZBd9epq8kf8dYE w0QHtdhzHVofdlLOBsqbKbTViP92+UnDMr0V4D+CCxxjG0e1IZtUSSzsQoHfRG5cUrzAuRSIk 2vzXsCdi6zynd5G44ud+e+j4BXG6N9rFluuYkzxZdIhCho3jPg= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > In any case, I don't think I understand the suggestion in detail. Can > you show a patch or an idea of a patch? Maybe simply something like this? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Obsolete-gv-setter-of-buffer-local-value.patch >From 5bc85fadc201eb7d061fe585283f0f4e44f0d910 Mon Sep 17 00:00:00 2001 From: Michael Heerdegen Date: Wed, 27 Dec 2017 20:46:20 +0100 Subject: [PATCH] Obsolete gv-setter of `buffer-local-value' This solves Bug#26624. --- lisp/emacs-lisp/gv.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/emacs-lisp/gv.el b/lisp/emacs-lisp/gv.el index 777b955d90..f0aad6689d 100644 --- a/lisp/emacs-lisp/gv.el +++ b/lisp/emacs-lisp/gv.el @@ -370,6 +370,7 @@ setf (gv-define-setter window-start (v &optional w) `(set-window-start ,w ,v)) (gv-define-setter buffer-local-value (val var buf) + (byte-compile-warn "Warning: obsolete gv-setter: `buffer-local-value'") (macroexp-let2 nil v val `(with-current-buffer ,buf (set (make-local-variable ,var) ,v)))) -- 2.15.1 --=-=-= Content-Type: text/plain Michael. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 27 15:27:30 2017 Received: (at 26624) by debbugs.gnu.org; 27 Dec 2017 20:27:30 +0000 Received: from localhost ([127.0.0.1]:54202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUIIT-0000yD-Q9 for submit@debbugs.gnu.org; Wed, 27 Dec 2017 15:27:29 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUIIR-0000xz-Lr for 26624@debbugs.gnu.org; Wed, 27 Dec 2017 15:27:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eUIII-0005iJ-T4 for 26624@debbugs.gnu.org; Wed, 27 Dec 2017 15:27:22 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eUII1-0005Ns-U0; Wed, 27 Dec 2017 15:27:02 -0500 Received: from [176.228.60.248] (port=1031 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eUII1-00052l-9J; Wed, 27 Dec 2017 15:27:01 -0500 Date: Wed, 27 Dec 2017 22:27:14 +0200 Message-Id: <83d12zhq71.fsf@gnu.org> From: Eli Zaretskii To: Michael Heerdegen In-reply-to: <877et8ymiz.fsf@web.de> (message from Michael Heerdegen on Wed, 27 Dec 2017 20:54:28 +0100) Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> <871sjhcetm.fsf@web.de> <83po70gnhy.fsf@gnu.org> <877et8ymiz.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 26624 Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Michael Heerdegen > Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net > Date: Wed, 27 Dec 2017 20:54:28 +0100 > > diff --git a/lisp/emacs-lisp/gv.el b/lisp/emacs-lisp/gv.el > index 777b955d90..f0aad6689d 100644 > --- a/lisp/emacs-lisp/gv.el > +++ b/lisp/emacs-lisp/gv.el > @@ -370,6 +370,7 @@ setf > (gv-define-setter window-start (v &optional w) `(set-window-start ,w ,v)) > > (gv-define-setter buffer-local-value (val var buf) > + (byte-compile-warn "Warning: obsolete gv-setter: `buffer-local-value'") > (macroexp-let2 nil v val > `(with-current-buffer ,buf (set (make-local-variable ,var) ,v)))) Does this warning pop up during bootstrap, and if so, how many times? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 29 09:09:00 2017 Received: (at 26624) by debbugs.gnu.org; 29 Dec 2017 14:09:00 +0000 Received: from localhost ([127.0.0.1]:55953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUvLI-0004RD-M2 for submit@debbugs.gnu.org; Fri, 29 Dec 2017 09:09:00 -0500 Received: from mout.web.de ([212.227.17.11]:55971) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUvLG-0004Qz-Vw for 26624@debbugs.gnu.org; Fri, 29 Dec 2017 09:08:59 -0500 Received: from drachen.dragon ([88.74.120.211]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0Lk8ko-1f5u2z35pq-00c9US; Fri, 29 Dec 2017 15:08:43 +0100 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> <871sjhcetm.fsf@web.de> <83po70gnhy.fsf@gnu.org> <877et8ymiz.fsf@web.de> <83d12zhq71.fsf@gnu.org> Date: Fri, 29 Dec 2017 15:08:41 +0100 In-Reply-To: <83d12zhq71.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 27 Dec 2017 22:27:14 +0200") Message-ID: <87a7y1hbiu.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:sjlJjol/SKdoPDMkN86tYOASlvtqS5o6ouppwVYzS+BEa4ZCiQV nVWV9CisqkI+UDzSrJLh2M2NHVsi98qWMUTh40rk6pWz0tyPRH8p+onx3n2MVE0/jUDwAPx Yaknllr0KvAj02XOQSlHORZ8Dd+dMJKCBZ9b+nJWj64YCW2gHkcGzrTFAZJixP+E3pwHc9a wlb8mevjsyt4giRSfTwlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:MkdB49VcSsc=:rYtw/pHS80h8uwAqkrkhbD fZ1swDDiQfSXEOgzsJitVxj+XV7FAR2Wb63dZdWItQ+1xAAcZErxklOvY4eUiMfZJVONrXWCI J78kOBtev5i/FeE6kAax/wDYjHzHI0+NK5uk4a7qNJdFwtmjEB7UR2exSeLpnI/QPwYANAoJn R4NahhFqXQwLLT2uRWELgWYSYIJ87cf1hCUXzqqFEpPFyVU99gBzuZf40GHbMEZbb0TbkR7wK qqpkKaMfGhv+JuCN8iEBlcqvrOK7WXUdDT3gBQqMPPV/rCLcVeJssabnXZ+2HDYdmObrRkzA6 rNxkJxOhBhxSEEjdpv0Ni7OZ9akYuy2Flcw/UckJCZmRNclMtck/pnAs104UnFVSvR96eqvfq os6e0C/UQNN9YRTDiHFfdUucKPJliv+GcVXPNScsUO4mKp8dNiV95jjxXpinQvs3bgsYVDFN8 Y9eVrLWi0evSV/371cHH6EHiZrxGcUFaIUO66uSqS61/GiGC1gwcmz/6Bd2iywEGBtqR5fokc s2DZq4eR4vaegad53yBMnRY/LlkwT2QqnxAiD/TE6QGcHosiXQXqfotxwOtNeYT+NtsoPxtGp ptsg8cqsuPmtAqLSYUxlT1th0D3S69MbamCp8geALtDjRMOv+hWLJiQNOP6m5s9OwPM1/vlWo sD97VLh3MdduuMCvabezzGN4f3CDhLmAEnNXOkRYuZIMacjlTZz4mJtjVIsggQpU9s3/vp4H4 k+zaSqZ6N8F594DcQCrynkMvGwB1gsoJT+3y8L3MxIuSI/pBKycp+q06xgvus/HfGkySfMHIr ijWz3FsyOGFGiyX3qSVdS+ZAvhlwc12uo0qoTLuy2o8r3aBaYA= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > Does this warning pop up during bootstrap, and if so, how many times? It currently would pop up five times: | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: =E2=80=98buffer= -local-value=E2=80=99 | -------------------- | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: =E2=80=98buffer= -local-value=E2=80=99 | -------------------- | electric.el:350:40:Warning: Warning: obsolete gv-setter: =E2=80=98buffer-= local-value=E2=80=99 | -------------------- | electric.el:580:39:Warning: Warning: obsolete gv-setter: =E2=80=98buffer-= local-value=E2=80=99 | -------------------- | elec-pair.el:608:38:Warning: Warning: obsolete gv-setter: =E2=80=98buffer= -local-value=E2=80=99 Yes, these would need to be treated. Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 29 11:15:04 2017 Received: (at 26624) by debbugs.gnu.org; 29 Dec 2017 16:15:05 +0000 Received: from localhost ([127.0.0.1]:56854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUxJI-0007yZ-M5 for submit@debbugs.gnu.org; Fri, 29 Dec 2017 11:15:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUxJH-0007xo-FN for 26624@debbugs.gnu.org; Fri, 29 Dec 2017 11:15:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eUxJ7-0006Eq-Fz for 26624@debbugs.gnu.org; Fri, 29 Dec 2017 11:14:58 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eUxIs-00060O-VK; Fri, 29 Dec 2017 11:14:38 -0500 Received: from [176.228.60.248] (port=3312 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eUxIs-0006iH-J8; Fri, 29 Dec 2017 11:14:38 -0500 Date: Fri, 29 Dec 2017 18:14:23 +0200 Message-Id: <83o9mhfr4w.fsf@gnu.org> From: Eli Zaretskii To: Michael Heerdegen In-reply-to: <87a7y1hbiu.fsf@web.de> (message from Michael Heerdegen on Fri, 29 Dec 2017 15:08:41 +0100) Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> <871sjhcetm.fsf@web.de> <83po70gnhy.fsf@gnu.org> <877et8ymiz.fsf@web.de> <83d12zhq71.fsf@gnu.org> <87a7y1hbiu.fsf@web.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 26624 Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Michael Heerdegen > Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, npostavs@users.sourceforge.net > Date: Fri, 29 Dec 2017 15:08:41 +0100 > > Eli Zaretskii writes: > > > Does this warning pop up during bootstrap, and if so, how many times? > > It currently would pop up five times: > > | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: ‘buffer-local-value’ > | -------------------- > | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: ‘buffer-local-value’ > | -------------------- > | electric.el:350:40:Warning: Warning: obsolete gv-setter: ‘buffer-local-value’ > | -------------------- > | electric.el:580:39:Warning: Warning: obsolete gv-setter: ‘buffer-local-value’ > | -------------------- > | elec-pair.el:608:38:Warning: Warning: obsolete gv-setter: ‘buffer-local-value’ > > > Yes, these would need to be treated. Can we treat them as part of fixing this issue? From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 29 11:21:07 2017 Received: (at 26624) by debbugs.gnu.org; 29 Dec 2017 16:21:07 +0000 Received: from localhost ([127.0.0.1]:56859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUxP9-00088M-C9 for submit@debbugs.gnu.org; Fri, 29 Dec 2017 11:21:07 -0500 Received: from mail-qk0-f179.google.com ([209.85.220.179]:45117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUxP7-00087X-8z for 26624@debbugs.gnu.org; Fri, 29 Dec 2017 11:21:05 -0500 Received: by mail-qk0-f179.google.com with SMTP id o126so40860799qke.12 for <26624@debbugs.gnu.org>; Fri, 29 Dec 2017 08:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mK5vU+W9ygy1Bcno1dsaKAlCpHEQztwUtM9TjwDV6p0=; b=eKQS2HwvHv5K3tqjgLQTmZgEvK2MvfGFmwDc5+sdtrjMVxowbxEvsDH/45FCX+/dO+ HInxhc0O2CuIsK0FS6jmVDf/z+RjZE/dblbb5ldQumPa1b8e81QPDHycrygE5IL8kBEZ 67ZYaZ/UL1aG906IvYQbcuX8yysP3Bhp2HU8WCAM54amLs6wErJf69HX3+pQcVSxjNj+ SFP247doV+8qhy8HldZ4ZOfPPrzUxocttUe1oMui10OuMl46EdXq1aPvsmRGUUZtv0pI NIagwAG+PiT1c/Zsw7XMVmPekPZ9Hreq1K6TasPY7g5yFQR12fXmUxPlvxd9qtTH/BCF 8fJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mK5vU+W9ygy1Bcno1dsaKAlCpHEQztwUtM9TjwDV6p0=; b=X9PP98DQ6NxIra3Nu8OCJYiRdh3jaLz7S09IcghKSMNUqI339SSZeiCx4dB2wxXueA 2iDzCBYffVVu14gpCrM7Roo1WxZfJ/kqIDiKu/d4SKHBzCfVuxHFk4wjfq0ERqzaaumU dmJor/wHWDvEKmslxlVKL+zVS4tg5IHSkMIQ82j0D84GQYY4rd0FfomK9Gmrc+LGjblb 40OBRF3co2y4OWHFm+3IDBhmnKI16RyQz4yXsaV28pydYVgiFTZ8U3YH1onh2Q4j6tW7 N1SHt1GIsjZDg/zsqC6y75Q+HU64hsGfY3Le81JBi3IWtw23okU/1T/1BPfPu7355TXi Vfww== X-Gm-Message-State: AKGB3mL/IY+lir7f1e2QBG5AUV9pwI4fVeTKDZ+aH7PYHedVlSbRcHyM EAAWdy/XeAV2uzigXvaI0f2jM1H7FbOvFmPtVf0= X-Google-Smtp-Source: ACJfBosrjlbVCle8v4CiWgZ59erHSNmGHdSllKIZ5eeYKg6qqTR/iVjyYlQcLF7Uyaq3WRIz+hALdm5YfbAu13rBajU= X-Received: by 10.55.20.198 with SMTP id 67mr2624153qku.55.1514564459614; Fri, 29 Dec 2017 08:20:59 -0800 (PST) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <87d16gm1qf.fsf@users.sourceforge.net> <837ewi9c4z.fsf@gnu.org> <837ewg65vl.fsf@gnu.org> <871sjhcetm.fsf@web.de> <83po70gnhy.fsf@gnu.org> <877et8ymiz.fsf@web.de> <83d12zhq71.fsf@gnu.org> <87a7y1hbiu.fsf@web.de> <83o9mhfr4w.fsf@gnu.org> In-Reply-To: <83o9mhfr4w.fsf@gnu.org> From: Philipp Stephani Date: Fri, 29 Dec 2017 16:20:49 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Eli Zaretskii Content-Type: multipart/alternative; boundary="001a11447f109ad8e705617d04fb" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26624 Cc: Michael Heerdegen , 26624@debbugs.gnu.org, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a11447f109ad8e705617d04fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eli Zaretskii schrieb am Fr., 29. Dez. 2017 um 17:15 Uhr: > > From: Michael Heerdegen > > Cc: p.stephani2@gmail.com, 26624@debbugs.gnu.org, > npostavs@users.sourceforge.net > > Date: Fri, 29 Dec 2017 15:08:41 +0100 > > > > Eli Zaretskii writes: > > > > > Does this warning pop up during bootstrap, and if so, how many times? > > > > It currently would pop up five times: > > > > | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: > =E2=80=98buffer-local-value=E2=80=99 > > | -------------------- > > | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: > =E2=80=98buffer-local-value=E2=80=99 > > | -------------------- > > | electric.el:350:40:Warning: Warning: obsolete gv-setter: > =E2=80=98buffer-local-value=E2=80=99 > > | -------------------- > > | electric.el:580:39:Warning: Warning: obsolete gv-setter: > =E2=80=98buffer-local-value=E2=80=99 > > | -------------------- > > | elec-pair.el:608:38:Warning: Warning: obsolete gv-setter: > =E2=80=98buffer-local-value=E2=80=99 > > > > > > Yes, these would need to be treated. > > Can we treat them as part of fixing this issue? > Yes, but I think changing them should be a separate commit because it's not straightforward. These are all modes that can be locally or globally enabled. I think typically such modes would be defined using `define-minor-mode` and `define-globalized-minor-mode`, but the electric modes are defined the other way round, i.e. the main modes are global, and then there are local modes that use `buffer-local-value` as mode variable. I'd suggest to turn this around to use `define-minor-mode` for the local modes and `define-globalized-minor-mode` for the global ones. Would that have any downsides? --001a11447f109ad8e705617d04fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Fr., 29. Dez. 2017 um 17:15=C2=A0Uhr:
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: p.steph= ani2@gmail.com,=C2=A0 26624@debbugs.gnu.org,=C2=A0 npostavs@users.sourceforge.net > Date: Fri, 29 Dec 2017 15:08:41 +0100
>
> Eli Zaretskii <el= iz@gnu.org> writes:
>
> > Does this warning pop up during bootstrap, and if so, how many ti= mes?
>
> It currently would pop up five times:
>
> | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: =E2=80=98b= uffer-local-value=E2=80=99
> | --------------------
> | ../lisp/electric.el:Warning: Warning: obsolete gv-setter: =E2=80=98b= uffer-local-value=E2=80=99
> | --------------------
> | electric.el:350:40:Warning: Warning: obsolete gv-setter: =E2=80=98bu= ffer-local-value=E2=80=99
> | --------------------
> | electric.el:580:39:Warning: Warning: obsolete gv-setter: =E2=80=98bu= ffer-local-value=E2=80=99
> | --------------------
> | elec-pair.el:608:38:Warning: Warning: obsolete gv-setter: =E2=80=98b= uffer-local-value=E2=80=99
>
>
> Yes, these would need to be treated.

Can we treat them as part of fixing this issue?

Yes, but I think changing them should be a separate commit because= it's not straightforward.
These are all modes that can be lo= cally or globally enabled. I think typically such modes would be defined us= ing `define-minor-mode` and `define-globalized-minor-mode`, but the electri= c modes are defined the other way round, i.e. the main modes are global, an= d then there are local modes that use `buffer-local-value` as mode variable= . I'd suggest to turn this around to use `define-minor-mode` for the lo= cal modes and `define-globalized-minor-mode` for the global ones. Would tha= t have any downsides?=C2=A0
--001a11447f109ad8e705617d04fb-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 09:33:48 2018 Received: (at 26624) by debbugs.gnu.org; 24 Jan 2018 14:33:48 +0000 Received: from localhost ([127.0.0.1]:40484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeM7X-0006N5-T1 for submit@debbugs.gnu.org; Wed, 24 Jan 2018 09:33:48 -0500 Received: from mout.web.de ([212.227.15.4]:62914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eeM7V-0006Mm-VZ for 26624@debbugs.gnu.org; Wed, 24 Jan 2018 09:33:46 -0500 Received: from drachen.dragon ([94.216.137.3]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MC1ho-1eVah11PW4-008sTW; Wed, 24 Jan 2018 15:33:39 +0100 From: Michael Heerdegen To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> Date: Wed, 24 Jan 2018 15:33:38 +0100 In-Reply-To: (Philipp Stephani's message of "Sun, 02 Jul 2017 16:53:33 +0000") Message-ID: <87mv13mim5.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:VBa9A8ArFg+dkY38xhCtJu/meBAdh/nleNdmoyxNpzmgFduPrMh BdhcgC/o/N65cCNSIEDwaXmkGj38BfRznZZusEezfrf4EZHgHF8YZ4Mya7SctkrDT+r5mT4 MfIyiI8SUdBBFg4AOwtFW9YwZvRA5Mb8tlECIOp4QM1mfuvL4saEf/rbna4zZ7Nua2jYDum 7SvE4cm7zzmgcGxP43RHw== X-UI-Out-Filterresults: notjunk:1;V01:K0:4RgCl8slgks=:fQP3s3qLBYP0lku+LFGyl8 cllXCawxUimySn98xQMbUXOYf1RoYOsfjKaryY48KqxpIDEU7nLiIU2FJqGfUDSHuZ93oRs7a rh/vlmYlaaRUTlbBG+XXZTxTkSVr0hWCnEsAeZKoKUXfBPyEkhzsZufZeoK9PCaAFu1aOm6HD /IRNknLy8cbj2kJQVms90bOLInIfc331s2degqE9kzL40XutyBGoy1SwBbZ55/RLfvQt7EwRj 4/P6D57IUaItnV3SAZyFYBCGxRwaBpn8dUSyNlIJwbImSGQcKMvCTuCXbhWeaeMaapeZD5QEX Em0zmiVtvYz/aQyD4nKAak05JakLzu2rBg24YFe8Z/yYE2AXUeZv1gSmwqtaXV/vg55q74UEb ryuZT1nNSqnOmZSHK8EXQogv9lNS5Ppvae22QvIiAUx7awpXCQReYTUek8SdXht72H89+zM8z ykQGDrOeuDXz7cSQz02hA/59/c8v1vDwNuAM+sofTozlaCeHCrvyhWflMSwinGpCxYmCHsWtt h2TVFUen/Rjm8T6k94/E4g4830smc9L9sYBKaNxNIJIiTPhiySbpilFJfU/kYvf7WFcKw14I8 QFziz+Njg202mjYE8X4CtWETIh+3JWtTT4SxcYCPCws4fHhyvp4i9IBA8B5yWD+bsXp/w81gJ bV5xQ1s0QOsK4UzdudJadAY/zUw6lXYOZm6mXsHZSpCE6BqmJQarh9QdWw91GxP+dJySIJsk2 EYYmjIqx7kvU7XmKwMhaypAnqoeREN9+H/v9iad7xz11xunfcFjCE5BH2QBrAQqJ8vxCYvfUG KvavEkBE+HBYmhIC/nc+qBbfo1lIRU+NfIBBSh0UfLRwWqjeRg= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Philipp Stephani writes: > Thanks for this great analysis. Given this, it seems that the place > definition for `buffer-local-value' should be removed from gv.el. But hmm - surely there are other functions where `cl-letf' doesn't exactly restore the previous state - `alist-get', for example: #+begin_src emacs-lisp (setq my-alist '((x . 1))) (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) my-alist ==> ((y) (x . 1)) #+end_src (admittedly, this is not as serious as the `buffer-local-value' case). Also, as another, different problematic case, the manual warns about `point' to be used with `cl-letf'. So, I wonder if, instead of removing the gv-setter definition for `buffer-local-value', we should instead add some more text about how `cl-letf' can have surprising effects to the manual. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 04 14:01:33 2018 Received: (at 26624) by debbugs.gnu.org; 4 Feb 2018 19:01:34 +0000 Received: from localhost ([127.0.0.1]:57335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiPXh-0007Nn-Le for submit@debbugs.gnu.org; Sun, 04 Feb 2018 14:01:33 -0500 Received: from mail-lf0-f51.google.com ([209.85.215.51]:46817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiPXf-0007Nb-Sv for 26624@debbugs.gnu.org; Sun, 04 Feb 2018 14:01:32 -0500 Received: by mail-lf0-f51.google.com with SMTP id q194so38725289lfe.13 for <26624@debbugs.gnu.org>; Sun, 04 Feb 2018 11:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YWeHbmk2UKue9segs+RsUtqaTF5E83BMbKaBwMzrCqs=; b=rym1s0gudg5bmCr3VfTHkDPx3eWpIY5ZP/BGRaW5LVM5PbMFoBr7wCbmV7WDNUkF+J cSFDZjvzPpkMp+PpU+q21we8fVGtvS1Ch6JPy7EQFfpcc66Xwm3MigLsYbnlVQ41W2g5 WIbjyprL5O7XkgWs0qDovXLaYJ8eMhMruwb4qVW3pZHx7wcas7F+BYfeAMsJtX9S60Q3 de08XpeGglNaBmpQg+l5IViqdwGO4L3a8RkaA5x+Zget3ZGaBPOoY4wAQABQBiQp7hJq WQZ22nx+DAN+8D6WA32W3uyE/5R3rjzoI4N9z2p1P22xgzmwfwQWTjOJTCO8XE611EKz MliA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YWeHbmk2UKue9segs+RsUtqaTF5E83BMbKaBwMzrCqs=; b=leLcrDbXn8ihsPegg9oRxUyIR38fu2MKiNNDnkQiMd/cLNvxuEVur+Ez92OqHB4bbH sydzwZxCXy9nspl/8QqaB+7WGjTCafGn6GPuzw/E3iQGbO6J8EqQMFMx1WR3NFOqv35k 0YruawqvT0XuM8iRlK7xiZKsfpdcDJ/z40iJoOQgeZfAtUx23MT60J9yrg88ekLcDxsh A8upQX77AuRofYLnildTsp8efd1z7Kb+RpBSAivWcEtGiK+ttU8sq1uoqtQo8MC0sW7O LliIDb5ssVwXhRwsjlt3PGuDY3HsPWKUeX0lLBt58kPcAwGt87n0+q714i3JrKS8O43r oNRQ== X-Gm-Message-State: AKwxytc+EaBvUqP9sEf/4xFnJC35kFKMbwQeuDWfvAmeaPoH1X9HxykP vUd4Dcg8ssIv9PmxwJtBMA99pVi11HV5tTMrbx8= X-Google-Smtp-Source: AH8x227n18TDqVpVa5j52EZBoCj74i8kvSYC431e8I1OclkF7/9qqHtAKx+W2+TNAPDm3dHvIBgmTXmUUSA+9GecOdE= X-Received: by 10.25.149.143 with SMTP id x137mr30421011lfd.119.1517770885897; Sun, 04 Feb 2018 11:01:25 -0800 (PST) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> <87mv13mim5.fsf@web.de> In-Reply-To: <87mv13mim5.fsf@web.de> From: Philipp Stephani Date: Sun, 04 Feb 2018 19:01:15 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Michael Heerdegen Content-Type: multipart/alternative; boundary="001a1147dcfe81228905646792bf" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a1147dcfe81228905646792bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael Heerdegen schrieb am Mi., 24. Jan. 2018 um 15:33 Uhr: > Philipp Stephani writes: > > > Thanks for this great analysis. Given this, it seems that the place > > definition for `buffer-local-value' should be removed from gv.el. > > But hmm - surely there are other functions where `cl-letf' doesn't > exactly restore the previous state - `alist-get', for example: > > #+begin_src emacs-lisp > (setq my-alist '((x . 1))) > (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) > my-alist > =3D=3D> ((y) (x . 1)) > #+end_src > > (admittedly, this is not as serious as the `buffer-local-value' case). > Also, as another, different problematic case, the manual warns about > `point' to be used with `cl-letf'. > > So, I wonder if, instead of removing the gv-setter definition for > `buffer-local-value', we should instead add some more text about how > `cl-letf' can have surprising effects to the manual. > > > I think we should spend significant efforts to avoid surprises. In this case, if it means we should remove `alist-get' as well from the forms supported by `cl-letf', then I think that's what we should do. The documentation for `cl-letf' clearly states: "On exit, either normally or because of a =E2=80=98throw=E2=80=99 or error, the PLACEs are set back to t= heir original values." If it can't do that for some place form, it shouldn't be allowed. --001a1147dcfe81228905646792bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am Mi., 24. Jan. 2018 um 15:33=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> writes:<= br>
> Thanks for this great analysis. Given this, it seems that the place > definition for `buffer-local-value' should be removed from gv.el.<= br>
But hmm - surely there are other functions where `cl-letf' doesn't<= br> exactly restore the previous state - `alist-get', for example:

#+begin_src emacs-lisp
(setq my-alist '((x . 1)))
(ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist))
my-alist
=3D=3D> ((y) (x . 1))
#+end_src

(admittedly, this is not as serious as the `buffer-local-value' case).<= br> Also, as another, different problematic case, the manual warns about
`point' to be used with `cl-letf'.

So, I wonder if, instead of removing the gv-setter definition for
`buffer-local-value', we should instead add some more text about how `cl-letf' can have surprising effects to the manual.



I think we should spend significant ef= forts to avoid surprises. In this case, if it means we should remove `alist= -get' as well from the forms supported by `cl-letf', then I think t= hat's what we should do. The documentation for `cl-letf' clearly st= ates: "On exit, either normally or
because of a =E2=80=98thr= ow=E2=80=99 or error, the PLACEs are set back to their original
v= alues." If it can't do that for some place form, it shouldn't = be allowed.
--001a1147dcfe81228905646792bf-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 04 16:02:47 2018 Received: (at 26624) by debbugs.gnu.org; 4 Feb 2018 21:02:47 +0000 Received: from localhost ([127.0.0.1]:57382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiRR1-0001lV-HP for submit@debbugs.gnu.org; Sun, 04 Feb 2018 16:02:47 -0500 Received: from mout.web.de ([212.227.15.4]:64193) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiRQz-0001lF-BC for 26624@debbugs.gnu.org; Sun, 04 Feb 2018 16:02:46 -0500 Received: from drachen.dragon ([92.74.163.15]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0Md4ZG-1eQE3g2gRW-00IAlQ; Sun, 04 Feb 2018 22:02:38 +0100 From: Michael Heerdegen To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87mv13mim5.fsf@web.de> Date: Sun, 04 Feb 2018 22:02:37 +0100 In-Reply-To: (Philipp Stephani's message of "Sun, 04 Feb 2018 19:01:15 +0000") Message-ID: <87inbcwjrm.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:37EPwsvAcDL8hZV+6/FWQzWO/TSdlPSDw/Ony926AfhjFd3BQa5 qFJKc6qx2YHwgqX/J3YwjZfJVGsjaUS+eJa6SN2+C7DUieGYrHhbya7uUXP8zca327ewDfz 3gyVt+alPMOE7Snz+VvziYEPvlwDrGMendS7UjAXgcr0dlMeX6E5wa6TjIVxdeqR/XbHXAM wFr+vYptTk6XvR416TDIA== X-UI-Out-Filterresults: notjunk:1;V01:K0:cG714Cf1Qc0=:tBFkkG0z0rkzunftaUwXXV 7ThiTGoi4AmX7k3hMaK/diiOll4d0VztPgpl0D5jefjzW7oNwc1yPjOci093IMtAgogp48J72 W6HLugnmI9MdnT0+YB/n6Cv+sjeEm095+QNHgQsXqLPUNM5hgBXa03Gpci6LoOwCouAD+9LNt HZ18MYPT8/P6yLGMV+/NNKbOIMJPhcosCNHLhglsvDHseYM84RRNGbf6AftmrQ3SHRz0TSA+Q lRiSe9gWEabNrTMHnOQFxpB80yVs5xedbyv7EeOM+MVGnaQK+PYM5fHF7RP6RjA+X6eU4zxzL YFLd8S4Bi8nOESoRz+sYGAx6t7cC5ovL5Q5hPrhiBShoh9AABG6utwOx4fFqoRDQCv3Jrw6pJ IkxSfE07uFkIiHJGlE0sb3DrWpi0gWKRUUB8u2BqLsIH0HnpQ5sGbPt3usK2NBlqsgflTXKFL 0A6aG6Fq0fGk+DAsYBDgt21r74QzDTSwYgkL8kiGjHq+v5zdUN/08WQnq4O7faSciaD8RqnxH zmK+MFYh4H1gbAq4gkCpFnkhXqN2ktzElU7Q0NuYcB/I/s3vmtBShR3lV1ssbsNJdTNCudWZt 66BUl0yjObkl4MOPVtc8DeE0bDL2Hgu7Wl2oj5z1qm4APGucy6udoTqh4L7AiLOtzBgWyKqjk FSSaOCoL5G6QpMIpbvcEiNFs4OW6va+fifi2Nuaso2zceJdc8E2boFfnI9O1vueIRSK3qmIeI ScQvfQrIdrfKl/MTfG4llUO8ssdLaO349BvHto2k2/JuqGRPZan1H5qj+0Fc8JmwDl9Vk2KVK ry0UhMnlgMdtEWEXmSYi1F2+MAohqhNhK2GJN82JEHNPbJPvCw= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Philipp Stephani writes: > #+begin_src emacs-lisp > (setq my-alist '((x . 1))) > (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) > my-alist > =3D=3D> ((y) (x . 1)) > #+end_src > I think we should spend significant efforts to avoid surprises. In > this case, if it means we should remove `alist-get' as well from the > forms supported by `cl-letf', then I think that's what we should > do. The documentation for `cl-letf' clearly states: "On exit, either > normally or because of a =E2=80=98throw=E2=80=99 or error, the PLACEs are= set back to > their original values." If it can't do that for some place form, it > shouldn't be allowed. But (alist-get value my-alist) doesn't change for any value (especially for y), so the alist, or the `alist-get' place expressions, aren't effectively changed. The object that represents the alist changes, however. Is that a problem or an internal implementation detail? Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 12:54:23 2018 Received: (at 26624) by debbugs.gnu.org; 11 Feb 2018 17:54:23 +0000 Received: from localhost ([127.0.0.1]:38574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvpX-00053C-4e for submit@debbugs.gnu.org; Sun, 11 Feb 2018 12:54:23 -0500 Received: from mail-lf0-f49.google.com ([209.85.215.49]:34396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvpU-00052z-Ud for 26624@debbugs.gnu.org; Sun, 11 Feb 2018 12:54:21 -0500 Received: by mail-lf0-f49.google.com with SMTP id k19so17583321lfj.1 for <26624@debbugs.gnu.org>; Sun, 11 Feb 2018 09:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kbBgANKupFujrcUAKxqrdD2WfLIS0w5n/uBmLQ1kvok=; b=FxpkM5hr/Q4LcrrZOYB1qdDnTTkLJyk28blSZ4whrhYu6NzxKDh+AVajarIcyan9El na6koKoS2AxmV6vV1O8/A0A5hYvWEc0PUOdV8azn8Ii8s62S/Qjp6yvN0eOw4vGYA+Ac JPTeldmt8QdyIXhmUVOi8E0wZsqjKhVtXGm+n4BeucmVrRXOytBPLaxLMlPOpiNpxcAN v118C765frdG5b19g/4udBFSZ0nYKnkh4dybK9Q/CJ36bqoAyzmBQEhiWf8rDsrgxxiS ecKS9Y+BSDjn5qIrdUHuzQ+hI1gafdWTIfC8IVXy/6/4THQ/OHH91snMJUZbRO9CFNjY Pv0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kbBgANKupFujrcUAKxqrdD2WfLIS0w5n/uBmLQ1kvok=; b=f28THe8SGJz5S0oNs7AtrCur8PTuP29q4gcb1VfeHRQ1ThHTKExRhz9U27Mnt/XIOp VEGEhVI1QOHxgNElXNpDZBIlFdQB6pylXlay2vbl2Xsjv26OtNwhUDS+9EAGJNt6w0Qx QHrp1a5Aw6R6PyNa2udElZuzK55eSVcGmwn+50gOAk48m1NFbGpl9zGj+SlI17YNtgcx bT2Mxkk1SksYpviPwEifuEfKDxkPu7qnCAlg3Ja310L7RpAi02frCslANdUtEGdF5KSi 9i4D38kJurWqfyFVQlbUg+tpVMhBhwbToCE6sbzsDEBQAVf204KxsomrtxXswRJ2L2h/ Q0Gw== X-Gm-Message-State: APf1xPCirXK+D+rX78Wfpz4Q4KqNZSnosIXITQBQAtsBDhS5si3U2dGc 6y1/DqXCBtzf132zpQEx3K5cvHQjbMgAq2Vsae0= X-Google-Smtp-Source: AH8x225cyauCRNjG1xCMJFVBEHUvSXl0qMx1ACcnJuzfXWBQokiDY4ERD5fj/dtbzPaO5gaaLdqsBuPEES5QN4XBLqM= X-Received: by 10.25.149.143 with SMTP id x137mr6271526lfd.119.1518371654729; Sun, 11 Feb 2018 09:54:14 -0800 (PST) MIME-Version: 1.0 References: <87zid6udys.fsf@drachen> <87mv13mim5.fsf@web.de> <87inbcwjrm.fsf@web.de> In-Reply-To: <87inbcwjrm.fsf@web.de> From: Philipp Stephani Date: Sun, 11 Feb 2018 17:54:02 +0000 Message-ID: Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag To: Michael Heerdegen Content-Type: multipart/alternative; boundary="001a1147dcfe1e05270564f3736f" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a1147dcfe1e05270564f3736f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael Heerdegen schrieb am So., 4. Feb. 2018 um 22:02 Uhr: > Philipp Stephani writes: > > > #+begin_src emacs-lisp > > (setq my-alist '((x . 1))) > > (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) > > my-alist > > =3D=3D> ((y) (x . 1)) > > #+end_src > > > I think we should spend significant efforts to avoid surprises. In > > this case, if it means we should remove `alist-get' as well from the > > forms supported by `cl-letf', then I think that's what we should > > do. The documentation for `cl-letf' clearly states: "On exit, either > > normally or because of a =E2=80=98throw=E2=80=99 or error, the PLACEs a= re set back to > > their original values." If it can't do that for some place form, it > > shouldn't be allowed. > > But > > (alist-get value my-alist) > > doesn't change for any value (especially for y), so the alist, or the > `alist-get' place expressions, aren't effectively changed. The object > that represents the alist changes, however. Is that a problem or an > internal implementation detail? > > > Since it affects user-visible behavior, I wouldn't classify it as internal implementation detail. It seems to me that the approach that `cl-letf` takes is too naive: binding a generalized variable is never the same as setting it and later resetting it to the previous value, not even for simple dynamic symbols (consider unbound variables). Rather than having `(cl-letf ((place val)) body)` expand to (let ((oldval place)) (setf place val) (unwind-protect body (setf place oldval))) it should rather expand to (let ((old-state (internal-get-state place))) (setf place val) (unwind-protect body (internal-reset-state place old-state))) with suitably defined `internal-get-state` and `internal-reset-state`. For most use cases `internal-get-state` and `internal-reset-state` could just be `identity` and `setf`, but for the cases discussed here they would contain additional information. --001a1147dcfe1e05270564f3736f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am So., 4. Feb. 2018 um 22:02=C2=A0Uhr:
=
Philipp Stephani <p.stephani2@gmail.com> writes:
>=C2=A0 #+begin_src emacs-lisp
>=C2=A0 (setq my-alist '((x . 1)))
>=C2=A0 (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) >=C2=A0 my-alist
>=C2=A0 =3D=3D> ((y) (x . 1))
>=C2=A0 #+end_src

> I think we should spend significant efforts to avoid surprises. In
> this case, if it means we should remove `alist-get' as well from t= he
> forms supported by `cl-letf', then I think that's what we shou= ld
> do. The documentation for `cl-letf' clearly states: "On exit,= either
> normally or because of a =E2=80=98throw=E2=80=99 or error, the PLACEs = are set back to
> their original values." If it can't do that for some place fo= rm, it
> shouldn't be allowed.

But

=C2=A0 (alist-get value my-alist)

doesn't change for any value (especially for y), so the alist, or the `alist-get' place expressions, aren't effectively changed.=C2=A0 Th= e object
that represents the alist changes, however.=C2=A0 Is that a problem or an internal implementation detail?



Since it affects user-visible behavior= , I wouldn't classify it as internal implementation detail.
I= t seems to me that the approach that `cl-letf` takes is too naive: binding = a generalized variable is never the same as setting it and later resetting = it to the previous value, not even for simple dynamic symbols (consider unb= ound variables). Rather than having `(cl-letf ((place val)) body)` expand t= o

(let ((oldval place))
=C2=A0 (setf pla= ce val)
=C2=A0 (unwind-protect body
=C2=A0 =C2=A0 (setf= place oldval)))

it should rather expand to
<= div>
(let ((old-state (internal-get-state place)))
= =C2=A0 (setf place val)
=C2=A0 (unwind-protect body
=C2= =A0 =C2=A0 (internal-reset-state place old-state)))

with suitably defined `internal-get-state` and `internal-reset-state`. Fo= r most use cases `internal-get-state` and `internal-reset-state` could just= be `identity` and `setf`, but for the cases discussed here they would cont= ain additional information.
--001a1147dcfe1e05270564f3736f-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 11 15:56:56 2018 Received: (at 26624) by debbugs.gnu.org; 11 Feb 2018 20:56:56 +0000 Received: from localhost ([127.0.0.1]:38653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekygC-0000iI-LA for submit@debbugs.gnu.org; Sun, 11 Feb 2018 15:56:56 -0500 Received: from mout.web.de ([212.227.17.12]:44381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekygA-0000i5-M5 for 26624@debbugs.gnu.org; Sun, 11 Feb 2018 15:56:55 -0500 Received: from drachen.dragon ([188.99.169.170]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LtFQN-1ef5iG3G7H-012tU4; Sun, 11 Feb 2018 21:56:47 +0100 From: Michael Heerdegen To: Philipp Stephani Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag References: <87zid6udys.fsf@drachen> <87mv13mim5.fsf@web.de> <87inbcwjrm.fsf@web.de> Date: Sun, 11 Feb 2018 21:56:47 +0100 In-Reply-To: (Philipp Stephani's message of "Sun, 11 Feb 2018 17:54:02 +0000") Message-ID: <878tbz6y9c.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:NssP/fopwL8ufE0KCsfVMtjzyWPHodecZh1/YpBQ/aboW043iK2 KHsxT9P+32ZBbbFJneWI73JC9qEMHnnDSUk/5QEN0kFzkNZniXCqZrMPUNWQTb9BLfLNl9N yftFWo+5PDujZ4bB1tMCzUgT1kuhKMR5nvPq00+P7pJ32BWALCEmkxMXfWF14cCr0DWirSZ JDeGun3nJ5Pn5jsFiGecg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ogPFtYLrIA4=:1SbWMH9rTQdHuRiKlOrJo5 ROhDqJDL8bh8ro4KNBxNChckYh/LAXexEhtY2eN308Ncgu87roUhQOcUQvcdHlpmgSynVYXrA Z7DrfH00K4jtgZyuMovTFwsY02cJMYjQJFLWwXPWfs4KsGRRLNvk4zJEFOSBq0i+ciSHhMteU Z9SITYIGnc4ycTnGesBu20O3QA5eGBwIQPGu14lkJduAC61LFi/vi0P0MI7qmCsI/i1aEXjqA So/G2JkkjnU4DnaSfzdkplRYFVAMyQuYviG/dy8NfxOt9wqmB/Orz1VnuUflF05LEajmmuVHH mxM8iJgUnFqu04dB1noORvcr359WlDPFG1fuPYMCMCvyRMz7HQ3h/pRLfq5iYk6SNaV+dajDC NRJx+Y1KdR2Hifk6ezNHVuWz3sb64+bZSB4uUO4sLgK/EYbWHPH4IIgtj/SVxppUWojhWSBq/ ixpbFhylgR9ozNMqGi6/ltTd0WV6cDx489ysEtaVBzLSEAOIvpKGy+SvJx2cud2JWr4PDMu5D /ducQ0Gi76JYn5oigH4dpMXhp7jRhqMXfgW4wMbk6onjG/yzlHISJ4nV2UFG1k2V6V0jDAlGB 8KnfdmQCsBtOSJvNOQcJqNg2+pMNRBP4Epq6tygEa4oM1DFuCJPjALo+EMsrqX6pjD8r3iS0N XeRVIsuZ7UK/Vjek1PVcDvN37LJw6wrzMKS10sZc3CUUQGwFtlzWujAplexspTuhFlgrdYk4U VDZWz+d4YefxLRgG5nKyG4vIW+WhkIK5ssozq97SjgyX8fsRaIpE9cBZ59koYmwq19YmiMOc1 AI+d1SCQxr9/WkyAd02Y2gADg2C2McpngRDRShkKOQ7Ceqg8Zs= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Philipp Stephani writes: > it should rather expand to > > (let ((old-state (internal-get-state place))) > (setf place val) > (unwind-protect body > (internal-reset-state place old-state))) > > with suitably defined `internal-get-state` and > `internal-reset-state`. For most use cases `internal-get-state` and > `internal-reset-state` could just be `identity` and `setf `, but for > the cases discussed here they would contain additional information. Is that even well-defined? What happens when the code inside `letf' also alters this state? For example, code like #+begin_src emacs-lisp (let ((my-alist '((x 1)))) (cl-letf (((alist-get 'y my-alist) 2)) (push (cons 'y 17) my-alist)) my-alist) #+end_src or #+begin_src emacs-lisp (cl-letf (((buffer-local-value 'x my-buffer) 20)) ... (with-current-buffer my-buffer (set (make-local-variable 'x) 0)) ...) #+end_src what would "reset the state" mean? Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 21 17:38:52 2022 Received: (at 26624) by debbugs.gnu.org; 21 Aug 2022 21:38:52 +0000 Received: from localhost ([127.0.0.1]:36963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPsei-0001Go-8h for submit@debbugs.gnu.org; Sun, 21 Aug 2022 17:38:52 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPsee-0001GW-Aw for 26624@debbugs.gnu.org; Sun, 21 Aug 2022 17:38:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YBB6ZUxxX0a9Fh9pTPv3fvUkV8+LjK93VksqKssNzjI=; b=PqhLEnzQ7Fo+HkIhVdXq4SISh9 Y17Na5N6iTrxATuhggzHGDvqlCBp5sjxCmNI5+U9yR2QJLt3Ay6fDV0MCPJ4ReouWly8dV/lzrnCV lL/0MiErJnO10s8+WlRsHi/9ubZNM2r0REhyZ8Xy54cYbC5h0//AVCSiI65/elj9nuGU=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPseU-0006Kw-WA; Sun, 21 Aug 2022 23:38:41 +0200 From: Lars Ingebrigtsen To: Noam Postavsky Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag In-Reply-To: <87o9q0m77u.fsf@users.sourceforge.net> (Noam Postavsky's message of "Sun, 24 Sep 2017 11:44:53 -0400") References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> X-Now-Playing: Mimi Goese and Ben Neill's _Life You Are_: "You4ia" Date: Sun, 21 Aug 2022 23:38:34 +0200 Message-ID: <875yilmg4l.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Noam Postavsky writes: > Philipp Stephani writes: > >> * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. > > Is it possible to just give an obsolete warning first? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 26624 Cc: Michael Heerdegen , Philipp Stephani , 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Noam Postavsky writes: > Philipp Stephani writes: > >> * lisp/emacs-lisp/gv.el (buffer-local-value): Remove. > > Is it possible to just give an obsolete warning first? I've added a mechanism for obsoletion, and I've now followed Michael's recommendation about buffer-local-value not being well-defined as a generalized variable, and obsoleted it in Emacs 29. I'm therefore closing this bug report. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 21 17:38:57 2022 Received: (at control) by debbugs.gnu.org; 21 Aug 2022 21:38:57 +0000 Received: from localhost ([127.0.0.1]:36966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPsen-0001H8-Ir for submit@debbugs.gnu.org; Sun, 21 Aug 2022 17:38:57 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPsek-0001Gd-5q for control@debbugs.gnu.org; Sun, 21 Aug 2022 17:38:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=oCqmPXDSkJ5pUzjIqKx7rxOFENCOzkwmnS/H8J5vMLI=; b=YUodfB5OsmlPorRL6Zj2zujjg5 uY0+3W1rC8lMX/VQfJZZBcQxaokwheEKpldi8k8jcglyZrE3DkF0gSMQ04r4CJ9gg1NGlWphB0UBJ ZYp4fH5supKQdZ1u/SgfLsuIirt9CxZOz3KcOFMFgNuE3TXXL9sIh23P0pL1IM4NrpW8=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPsec-0006L7-6g for control@debbugs.gnu.org; Sun, 21 Aug 2022 23:38:48 +0200 Date: Sun, 21 Aug 2022 23:38:45 +0200 Message-Id: <874jy5mg4a.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #26624 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 26624 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 26624 29.1 quit From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 21 18:21:45 2022 Received: (at 26624) by debbugs.gnu.org; 21 Aug 2022 22:21:45 +0000 Received: from localhost ([127.0.0.1]:37012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPtKC-0006iX-Vx for submit@debbugs.gnu.org; Sun, 21 Aug 2022 18:21:45 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPtKB-0006iB-2l for 26624@debbugs.gnu.org; Sun, 21 Aug 2022 18:21:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fgI4bneIgoTiv0M1vEf0Chze7+tEX9CQvKVUGEkHOkE=; b=aGIQnHrAjgDnbDMzKpcFuK1P/Y ijWX8A520FOrT8Oz0EtbtnSC174mZmbydTbg+eL/lcDZ7vClCtJM1m54YuXmMN772At9fY6jK7lsO LpVZ1dvm+tYDsS9MtRuUF5C8/fWrFtTtTNYffUU81lWmWVEPu61YCmWbXrxajW+BtiWE=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPtK2-0006hK-Af; Mon, 22 Aug 2022 00:21:36 +0200 From: Lars Ingebrigtsen To: Noam Postavsky Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag In-Reply-To: <875yilmg4l.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 21 Aug 2022 23:38:34 +0200") References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <875yilmg4l.fsf@gnus.org> X-Now-Playing: Mimi Goese and Ben Neill's _Life You Are_: "Endure (Head In Hands Quarantine dub)" Date: Mon, 22 Aug 2022 00:21:33 +0200 Message-ID: <87zgfxkzki.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > I've added a mechanism for obsoletion, and I've now followed Michael's > recommendation about buffer-local-value not being well-defined as a > generalized variable, and obsoleted it in Emacs 29. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 26624 Cc: Michael Heerdegen , Philipp Stephani , 26624@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen writes: > I've added a mechanism for obsoletion, and I've now followed Michael's > recommendation about buffer-local-value not being well-defined as a > generalized variable, and obsoleted it in Emacs 29. It turns out that while not well-defined, it's useful here: (define-minor-mode electric-indent-local-mode "Toggle `electric-indent-mode' only in this buffer." :variable (buffer-local-value 'electric-indent-mode (current-buffer)) Rewriting this to avoid this is slightly cumbersome, it turns out. So I'm not sure it's worth obsoleting the form, and we just have to live with the somewhat odd semantics. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 22 02:54:22 2022 Received: (at 26624) by debbugs.gnu.org; 22 Aug 2022 06:54:22 +0000 Received: from localhost ([127.0.0.1]:37645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ1KH-0007dP-OK for submit@debbugs.gnu.org; Mon, 22 Aug 2022 02:54:21 -0400 Received: from mout.web.de ([212.227.15.4]:34007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ1KF-0007d6-Uj for 26624@debbugs.gnu.org; Mon, 22 Aug 2022 02:54:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1661151236; bh=qWTwfJ4uO7g9DNm/aHHpEQGpra482PqCZi+DB9u7vag=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=dH0EnZQTjq23d4afSclXkgtF/V9yovkxp7alH4XWa+1tq9x4hP33PHpLXKsnV8X9t 4ZjmGLH0cHyz1XMKJ7s+j5ILtETKFKlNwAYSS7YW8ll2+HrEo2jZMUUOSe1TousUTE txZXZg78E7jcBTDXslFc1oxA9PlmiArS2j5bIzVU= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1N14pS-1pRQsw2XMY-012lc0; Mon, 22 Aug 2022 08:53:56 +0200 From: Michael Heerdegen To: Lars Ingebrigtsen Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag In-Reply-To: <87zgfxkzki.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 22 Aug 2022 00:21:33 +0200") References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <875yilmg4l.fsf@gnus.org> <87zgfxkzki.fsf@gnus.org> Date: Mon, 22 Aug 2022 08:53:53 +0200 Message-ID: <87r11822gu.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:B42TAd0Un/DLAgN9wFnDTHcfA0f/bRmF8GZ6Afxy7bdO8QlJews teH2VpGLIN3MTe8hxCuVh2QnpOOTzsz4iEiUcMatT2ZekXVqB/3fUCM92CLuwk4HD3vLqhI ijFsO3pDTRdnMNy+0x/Sc3gcuVeS4eZ2aVLANmpkKKNnYiMgykVcn+IVIofWQB2Aryzm+ye liPxUArewr8a5CkBgo9dg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:FOSWgmxBaQQ=:BbEsWMmjStCAXvhyJx8KMT Yo4j081Wjfj0x+8ZvM2OtXCXKSlAz+qVyjHytHXyioS2cqtwyXn6DP1oZIN6rpSl1kmaGX7Sr Bm7gpzNSj/3rfIYcLSOJ5dxIuRH0nnG5nXfxxicZIz4veVco/OtAy5YFNPgEehr8vfalqrhAV 1A1zvi+Z9N9/567VRCfKdGeqoQOJn6kyOJphx8HmzgL27TMEHwzYgOE7dCcetYiZbToAX9DR5 ff+TQeAYI5BRL9R5PyGyM074UJvtlCQgdUVla37eTDRxwCKw8ZOOpN7nTk8lGIeC18c0srgPv Hvyp5fKNcohIG1rEAb566T2t9TXCD+C5JqeZkxP2NfTpohk+jtl8FJ3t870iCY48LPxR2WrbJ t89ANrMtY5Y4wsAeUfonNsh4BCCQ8I1FqoazAS04NwDjCDLUE58iy+VTSteMsBcb/IcFIDclj b04DKeGqdDqGDeMAOgun6gV649FIsde9dI3mFQweCkYl4SGBh5+4qos5zoKBIisX7qG40FzxW Euharl9qd6nWWYmfaNSqu2VvTG819EWgfiVj3AlpVmMnfjwHEhWsU55t/HknxbXHlDA2BG6Kl dumQoaaKeSgbvXeOxOb+yONLq4Tw4Aen6sTb7nwdCwhcf3L6oDSvPPQcGuO/6KP7FYl+dXHyv En7s3QudvMdiUHPeQc59sRCtOaehrt9Ub9c73EMRgR4D56tvZgBMbpzIHJJaXKS9rYUDNWWYd AxHNKgE3r/lZY2pjBA6w0VqQDZELSGv7fHKV8nGDd6HD+4uZAYvEjQ28YzlrmpdnFlEVfo4um tW4qI754XywnBhZhEqbJNESdBGdSJwkpO8HRi9CZAHWNbvnmMBUqtNJYtJQSR8xEF65+TNnY/ CPxKRFSuGF7B0TDagOdbnoYBhTrrewxTsk8bTMXcOxJDoAomGryMli+6cMmXw8uE3+tpGoPZ5 pKrsA7FaCxEkfSTjJqErYihjsKiYLJOIyqUCNcShmXskr8JufVvuVO9AIqy3lcs3o0i5Ky3Vo UrHmqcOe2XBjmNN1ZHMtGcvBRzVWeUVdoi78Gwnm2A8zPArrIIs7iTqRD8gPuo19l1/ZMR+w1 5IZBtmB6sjlwVKfHXQL7vllwfyXM1IH1zqaH35oru4X9LAFoGOk6qJEpg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: Philipp Stephani , 26624@debbugs.gnu.org, Noam Postavsky X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > It turns out that while not well-defined, it's useful here: > > (define-minor-mode electric-indent-local-mode > "Toggle `electric-indent-mode' only in this buffer." > :variable (buffer-local-value 'electric-indent-mode (current-buffer)) > > Rewriting this to avoid this is slightly cumbersome, it turns out. Why not use the (GET . SET) syntax for :variable? Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 22 06:10:54 2022 Received: (at 26624) by debbugs.gnu.org; 22 Aug 2022 10:10:54 +0000 Received: from localhost ([127.0.0.1]:37951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ4OU-0006U3-3K for submit@debbugs.gnu.org; Mon, 22 Aug 2022 06:10:54 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQ4OS-0006Tq-B5 for 26624@debbugs.gnu.org; Mon, 22 Aug 2022 06:10:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LMXzLI4T4/Bbl9XZdtzUpQCB0hzS5iE2BjxSz5UEt1E=; b=ZP9LlljYKZ4IAlGx7ahQyo91aN ixJqbyvjCyDArvHMsHf2/2rNeZSOUkWw4oTtRFOAdsFs3Q7pMZoFTQs7qX8yZVgMnpI1eu9dyMrPA t1QER7XNVRAY15YNumeh1vXTpzfAmJfwQJnMTFWDnfHzShcPZduLd5YEuOsV3qHYu60M=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQ4OJ-0004I5-Ub; Mon, 22 Aug 2022 12:10:46 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag In-Reply-To: <87r11822gu.fsf@web.de> (Michael Heerdegen's message of "Mon, 22 Aug 2022 08:53:53 +0200") References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <875yilmg4l.fsf@gnus.org> <87zgfxkzki.fsf@gnus.org> <87r11822gu.fsf@web.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEUpJisPDBBXVFp8 fYShoqe9vsTR09jw8fL////l0XS0AAAAAWJLR0QIht6VegAAAAd0SU1FB+YIFgoDISMY1/YAAAG4 SURBVDjLpdLNktowDABgJZPhbJU+QPDC9kohpVd2semV7sTh2tnB8gu09utX+bXD0lPFgYm+kSX/ QAa5lE+V0sYYpXayBMgQMwQUIKWslOK0Ou1kl+cARCG7kja/l3MopdwrdQ52XKlbCkVe5lyiHdHt DoAH+BGsIeJ8AtCCpzbehhYdIAMU3rf0G9oEihEEFCF4ct5tZ8B/DF0ce4AJFtTDpQPuNMKhcW3e HbGvyIYeQhtybZvXft9jc8RDB8GeZsAfZ8vDBm9mFTwcbqiximr1ikOMUDRElmy9+gCax/LuHR+B d3SZQTvV0jTE5368A77gSnN7k91BhplYE5lfeA/8Ew3ZN5GCKLkAyyWvRNejgAk+bfluS8mnZbX9 s5ZQwgBq/XTSujY88c2YqpDbAfan5VrzS2yCMzdbF7AaeuyKXDd8JFdvrCWT50NFO9Yz54fLpVU8 Esi/7VWlTr18nYCPf+PCFC8J4Cbmw8/pojgWMe8vacV/AT0EzzCb6kuE8BhccDP4HoHSneMhgVUK OoLNEhBqAn/DBJZ1hPcUPpt/wCICbxwiPFs3wUv3ZAc422sEwU8rw79xYN9+0S2V8QAAACV0RVh0 ZGF0ZTpjcmVhdGUAMjAyMi0wOC0yMlQxMDowMzozMyswMDowMLGuQFgAAAAldEVYdGRhdGU6bW9k aWZ5ADIwMjItMDgtMjJUMTA6MDM6MzMrMDA6MDDA8/jkAAAAAElFTkSuQmCC X-Now-Playing: Bertine Zetlitz's _Beautiful So Far_: "Lovers Do" Date: Mon, 22 Aug 2022 12:10:43 +0200 Message-ID: <87mtbwbnbw.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: >> (define-minor-mode electric-indent-local-mode >> "Toggle `electric-indent-mode' only in this buffer." >> :variable (buffer-local-value 'electric-indent-mode (current-buffer)) >> >> Rewriting this t [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 26624 Cc: Philipp Stephani , 26624@debbugs.gnu.org, Noam Postavsky X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: >> (define-minor-mode electric-indent-local-mode >> "Toggle `electric-indent-mode' only in this buffer." >> :variable (buffer-local-value 'electric-indent-mode (current-buffer)) >> >> Rewriting this to avoid this is slightly cumbersome, it turns out. > > Why not use the (GET . SET) syntax for :variable? Let's see... would this work? :variable (electric-indent-mode . (lambda (val) (setq-local electric-indent-mode val))) From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 22 17:44:02 2022 Received: (at 26624) by debbugs.gnu.org; 22 Aug 2022 21:44:03 +0000 Received: from localhost ([127.0.0.1]:41955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQFDG-0007gn-LV for submit@debbugs.gnu.org; Mon, 22 Aug 2022 17:44:02 -0400 Received: from mout.web.de ([212.227.15.3]:53417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQFDB-0007g2-05 for 26624@debbugs.gnu.org; Mon, 22 Aug 2022 17:44:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1661204611; bh=sGXum/Cl6iCwJcDZjZ78dYzMGY1Xh8kucsTL9GJXXo0=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=qt5OIcLU7Ze1sOzZ4G7McMYdbDsBn+IQ2W82ox70FKUEgCn+rEuJXWR6D5oAuW/7Z eZc5vLPH6Kn7AvQqGSB4BQZmlfSkZrKnd5M/qny5+N4dzWimOnMxe9yDCkwsE8ROY+ 8F/wxb+liqQcgrmfRhr0b1LntPOz0ZYdi0Faq60U= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1Mm9VU-1p84Lj0SXo-00iXrU; Mon, 22 Aug 2022 23:43:31 +0200 From: Michael Heerdegen To: Lars Ingebrigtsen Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag In-Reply-To: <87mtbwbnbw.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 22 Aug 2022 12:10:43 +0200") References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <875yilmg4l.fsf@gnus.org> <87zgfxkzki.fsf@gnus.org> <87r11822gu.fsf@web.de> <87mtbwbnbw.fsf@gnus.org> Date: Mon, 22 Aug 2022 23:43:30 +0200 Message-ID: <87bksc0xa5.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:dtbaA59iUV4MN0SolRseolidJa7FwweJo2WxeKFwDvvs66osppq tG6UXCl7pvD0qvdUv70aYOpsqvtVBTwV2ivpo0jIryspH5oldLraFblJszh6OanKQ0izLws PMy3Lgl3QFY6wdiCde9CPXLhSnE93BPZQgjYGNjvyw8v+XhWIoDrXU1MsbHTJqWweekY6QP L4t0HkXVstZpfRvSRbyUA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Xp0qiGdh6uo=:Spidhkvpc14LMgFrT8Frjk IgV0Bbd6nJTZsfd/+ptnm1Rm5zQ8DBmJl3KbFl4HVjQSCw0GdxJpYybZiUTjjbOdUJCeJ8ray DwJNO+Q2hr7yfXmHUMHwdKSHiJyWJtY5lKHhrswH4z+z8kNFDeGp/9bdqLpRq+/H7V0SlMSoK tFxHafgz+IwNPxAFDyrMDuq5+AD3fAz4/DKWHulifhG3YYEssn/SOgjtVQzytBzwpPEG7keAm Y50prlULrB/hacLs5Yb7i34+uOeGQjOqrCV0wRW0u3yivCT+0F7hogIyi20Nnf9T/nfnp/3xH OenW50MMLYLk9skmLtW5igNXB4MIH5lMAywwtn6jJrZDQB1hMqTwgR0DGptlFJqj4AYcj0/o2 KL2wi5K+eDshX/u3/qHRifMAgdyEje76Wdc5BIYKFpfaSEpa0/F7MT10x8E4xP8KuMr9D5BYN p1PGB5uOGnN+5Gg5M0wNJ38hzBFchYLsN8J3MShZEeLBKsnJisWueFu79FJs0rZMd4o9nLtRv s9AQf0PsoM1bnKfUNKZuy+3rmhvW4fezhn9zHnJh6lfTiQ6CccVrtpyn7smGM/wD5sBa6cCGR JrfjpplSDcZBJGE9dMMFKrN7VMDsVaoMcmelUn41WhETAKiEHdSQX4mPuekrcmZf+EPCZ6GQ/ JRsm95/a/mfo9xnpdsdvOCTUSzBHIu0K6gWIyzTX3Uyq1JQGzyYo+2KnBMXIAAJCVeN67rKum TM1UGT3mTXZKfn8OUZZ3DcSjnGrJq/lhCGPMfako2hQqofgs4lVTgQuhK5dXpWSZ+YTbOi7w8 mUGXf79buzWbW93qM6kxcHRwDJi/mVpbcPsNBaQU6kY7k+XvfA9GQgiM4t7lzJNsxcmuoaMjS Ny3h6w3MrLI4xroZjUb0m6w3Yjxt+XoHdGcWA/z8u25e711do9n/K8kiRzBaJI2WsebwK3SSo CjTwT2U1U50ZKybVlTHIyPBTPggEs0D+zfRA5BCymcH36XT4tA/535ifNddrnT6qbQS4q78Gb kBEbNhqgnA4/NPnjtfE96rt4cZvRBSNM0TwK2WCWPVQnosPk4WqElFObufirYuEoaXee0tLzA xK2RO8QwKy2Hhlyhp5uSxrgKSYT7VtyQQC1DARGTZoX3X5+lSQJDX6ynQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26624 Cc: Philipp Stephani , 26624@debbugs.gnu.org, Noam Postavsky X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > Let's see... would this work? > > :variable (electric-indent-mode . > (lambda (val) (setq-local electric-indent-mode val))) Looks good - similar specs are already used in other places. BTW: I find the definition of `electric-indent-local-mode' inelegant: the handling of the variable is split between the :variable spec and the body. The body enables the global mode and sets the global variable back to nil - quite hackish. Anyway, if this is needed in more places it cries for a `define-localized-mode'. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 23 06:28:58 2022 Received: (at 26624) by debbugs.gnu.org; 23 Aug 2022 10:28:58 +0000 Received: from localhost ([127.0.0.1]:42715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQR9W-0008UP-8K for submit@debbugs.gnu.org; Tue, 23 Aug 2022 06:28:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQR9U-0008UB-AS for 26624@debbugs.gnu.org; Tue, 23 Aug 2022 06:28:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=mGQ1MHZeeLSudFCB+vMbENw7qPpkFadw7NR4NsLxX6I=; b=ri8Q6kTj3ftGxlknJqBt9pL1qr eZ50VOCx2uepppX5qQtInUtqn2MJXB14bc87pKxQSfRceT95Ui6UXgrjPzNIvU2PUx0GcEx387Vle rDA84bSBgS4IqCC4zdSPsEPJlGcZEThKbGyC4PS9L+lltp6p+65sBsjWSLBl5PAsFH8E=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQR9M-0007Ql-4R; Tue, 23 Aug 2022 12:28:50 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag In-Reply-To: <87bksc0xa5.fsf@web.de> (Michael Heerdegen's message of "Mon, 22 Aug 2022 23:43:30 +0200") References: <87zid6udys.fsf@drachen> <87o9q0m77u.fsf@users.sourceforge.net> <875yilmg4l.fsf@gnus.org> <87zgfxkzki.fsf@gnus.org> <87r11822gu.fsf@web.de> <87mtbwbnbw.fsf@gnus.org> <87bksc0xa5.fsf@web.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEXaZTP7lUnrWBDM NAWjJAV7EgL72cL///8JScQPAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YIFwoIDtOBVAEAAAGBSURB VDjLlZPbbcMwDEWZxwBOAuTboTwBqQGKSt4gGSAokP1HKB+iLaftRy9iOdIxSZGUAFQn14CwGxBx 1H+9sFNb2tskkTzMjPKA/JZPuRPUwr8KqikvOD5sQCQLMuRa30HNbehAXimXNcZ8r70OAe7zY40j QcJiXkEhLmXaU2rgEa4oUS4TpQA1QEmUavKqMDzE4jg7sDXyyoAGGMIXYi4ewvIoDj7VhNWEIsHh qEnSVEh8iVmAfDn6pgqSAW2Mgo8vKwZLORAn24KDcrEtpaxBJiuigwpScPk428DE1vPIjpHUjDO1 w6CLWi2ZW6AFAHg3iMnLuoKWNSfvUQpw8B5KIxz4OSIATc7PQFk8JbWoDbRm4wZwbmcjQgswT5zq dllAdtD56RKUFdukpEI9WNqpzmgtSTHf3GdnoFjQ0bvQxWhB7e68A7UHT2vRLW7ZqLdwPHdgH6Y6 O2GMt81tvp3Ouq4jxt1Xwc5eZyM92Aher3VyfT2vHfip519A9X/wDbU84Ai1SWu2AAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIyLTA4LTIzVDEwOjA4OjE0KzAwOjAwYKQTzQAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMi0wOC0yM1QxMDowODoxNCswMDowMBH5q3EAAAAASUVORK5CYII= X-Now-Playing: David Allred's _Smells Like Everyone's Watching_: "Your Way" Date: Tue, 23 Aug 2022 12:28:47 +0200 Message-ID: <877d2ztfs0.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: >> :variable (electric-indent-mode . >> (lambda (val) (setq-local electric-indent-mode val))) > > Looks good - similar specs are already used in other places. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 26624 Cc: Philipp Stephani , 26624@debbugs.gnu.org, Noam Postavsky X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: >> :variable (electric-indent-mode . >> (lambda (val) (setq-local electric-indent-mode val))) > > Looks good - similar specs are already used in other places. Now pushed to Emacs 29 (and I've made buffer-local-value obsolete again as a generalized variable). > BTW: I find the definition of `electric-indent-local-mode' inelegant: > the handling of the variable is split between the :variable spec and the > body. The body enables the global mode and sets the global variable > back to nil - quite hackish. Yes, it's not ideal at all. > Anyway, if this is needed in more places it cries for a > `define-localized-mode'. I hope it's not used a lot -- we'd rather have modes work in the opposite direction. That is, the mode is local, and then we have globalized versions of it. From unknown Mon Jun 23 04:10:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 20 Sep 2022 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator