From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag Date: Sun, 24 Sep 2017 15:19:48 +0000 Message-ID: References: <87zid6udys.fsf@drachen> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="001a113cde84ade0fb0559f0f93d" X-Trace: blaine.gmane.org 1506266481 8599 195.159.176.226 (24 Sep 2017 15:21:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2017 15:21:21 +0000 (UTC) Cc: 26624@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 24 17:21:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dw8iU-0001Xb-Bz for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Sep 2017 17:21:10 +0200 Original-Received: from localhost ([::1]:38487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dw8ib-0005wr-LU for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Sep 2017 11:21:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dw8iT-0005we-Ne for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2017 11:21:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dw8iN-0002ME-Ir for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2017 11:21:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47516) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dw8iN-0002M8-Dm for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2017 11:21:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dw8iN-0003sp-7v for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2017 11:21:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Sep 2017 15:21:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26624 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26624-submit@debbugs.gnu.org id=B26624.150626640714818 (code B ref 26624); Sun, 24 Sep 2017 15:21:03 +0000 Original-Received: (at 26624) by debbugs.gnu.org; 24 Sep 2017 15:20:07 +0000 Original-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 Original-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 Original-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) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:137339 Archived-At: --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--