From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72229: (setq overriding-terminal-local-map nil) in isearch-done Date: Tue, 23 Jul 2024 18:05:31 +0200 Message-ID: <87h6cg856c.fsf@web.de> References: <87r0bmer66.fsf@web.de> <87sew17fs1.fsf@web.de> <864j8gsk4i.fsf@mail.linkov.net> Reply-To: Michael Heerdegen Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40527"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 72229@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 23 18:06:58 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sWI2T-000AKJ-0k for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Jul 2024 18:06:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWI1t-0005Ca-Hw; Tue, 23 Jul 2024 12:06:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sWI1b-0004lu-AX for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2024 12:06:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sWI1W-0003jW-6N for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2024 12:06:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sWI1a-0002yo-JM for bug-gnu-emacs@gnu.org; Tue, 23 Jul 2024 12:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jul 2024 16:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72229 X-GNU-PR-Package: emacs Original-Received: via spool by 72229-submit@debbugs.gnu.org id=B72229.172175070911372 (code B ref 72229); Tue, 23 Jul 2024 16:06:02 +0000 Original-Received: (at 72229) by debbugs.gnu.org; 23 Jul 2024 16:05:09 +0000 Original-Received: from localhost ([127.0.0.1]:60597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sWI0i-0002xM-VP for submit@debbugs.gnu.org; Tue, 23 Jul 2024 12:05:09 -0400 Original-Received: from mout.web.de ([212.227.15.4]:57589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sWI0e-0002wk-9y for 72229@debbugs.gnu.org; Tue, 23 Jul 2024 12:05:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1721750687; x=1722355487; i=michael_heerdegen@web.de; bh=E3EtNT9OBYBHQCZNBaO1AYVH30DvaF5zDTIAqhHWhiU=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=CxYwPQHAfm4uUbP84+JkhD872bQidDdgCAplVaRXwk0yPCWP9BJ8zlYYbVNhEnwG 6NsDi+JHl2yTehrkwmE0Uawrgqj78po7vkv6TBBhiX3zaROTxSeN53ptUPUI1l+wc sV5Tvdlzq62gYKt3CFbq5lOSnAjL5w8aKBUjt4RTq1cLc53LW4xBPnGFg7q1J8zEq UsMtreNboQFGitoJMU+uvc9ytbRU07u+ItpfyVLVThhvZ4Dzx7Smik0OosHKnk6BQ H74ZuPIGi71GUAhuhY6koDNzUr4eEZIjE6ac7ELo0teRjcsH1NNuR0+iVwTNuo82D vzAmONnWrjFNPqjjCg== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([84.59.210.113]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MxYbN-1s7bNO1FRR-0131JC; Tue, 23 Jul 2024 18:04:47 +0200 In-Reply-To: <864j8gsk4i.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 23 Jul 2024 09:32:21 +0300") X-Provags-ID: V03:K1:VKhPdYwtPOKCOe4mwF2h2R2k3RJliUacafHyYrAFgTfBkg9ff0c q4b/N7QkAL17tsH5yXZzrwf67ykFJ9RepXtLrPkcBZKwk/J3HeYX7La46mHAMXjAAlithm2 5a2lswPCdIV9kd5YMuKpzo42uqrf3iIOoqYK6oam26EgBlhcIjjf1PxxT4sZ9uBnZdYctRj SOJtVaFPDLj+3SEA65mFQ== UI-OutboundReport: notjunk:1;M01:P0:wWcGfI0I4KI=;vFU80vrHlqCduo8ah282UvIC+Bw VWjWu2DMYZg+24/2gN/lvVUu3H3BPogNW3FAMNZ5aP16iet6x888IX5X4fIojxKKf4ZaElRqP 15mwaiZCMXqgWHRXhQA+Z18sDbLO28Hlx85QFAjy+C3lDxt4z3cvVspwG2/6wF50vOazBV7rn YlrsffJ2Cm/xwZOYlPgeQm1D/gCBmwiCRY4cx5wCYZK7seEOob+2wr8Dtrot8PF2uwhIzhrjL MPKNjTzar2wLL5NHDNJFPk8d71/UjPH4jvcExZDgvgDZjqlG8mwM5q8Fxgo7eZQkaCVVxmXTw kqoffoG+Kf06TMR5CE78i1+/icqkhU6Vu0be/2bpGSaEWGK72LAfpGMoP4FzRoMkFnUL1d0o5 HvPtG84qAcJac8ZrL8AUb5Hk813YFx7VkU/WXvfQt2mZMkeVXmbekzSHa7js+adVgWwlmXr9M 84gXXMXtLcieGB4oR0YC4RLTfCMnFV3Qs6mkpIuu/lP0gD811i3PFl/itBw0ikTm7/c5qgZ99 SVx7cukvui+lj2egWSLqAsUGytNd8BxRyu5haqXqQRSpJzaM0NRHkSAd6kcPkrM46AxIv+x4V p1jd+xxc2zyrqyU9bIhdOidz0YbD5puIcqSHfJUNcnltr7hiKOfYPz9bfRf1Lej1fBvKJLWJJ RqaINFZX5SYZdDrdRfQwJo/vvodh7lzKoPTednKQyOJPEri30Tsi6Bxwe4Ma4w6c1jJqxrD1G deXF5fQoFxX0ZKrs2S2S0DJik82NSBf7r/XHcptmulhMeIhbiPcz+JoaA/xBtF0sjuiwEzHI X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:289177 Archived-At: Juri Linkov writes: > Indeed, you are right, `isearch-done' should restore the original value. > The existing variable `isearch--saved-overriding-local-map' can't be used, > so a similar variable should be added like in this patch: LGTM for master - thank you. > This mechanism looks like a variable watcher enabled by > `add-variable-watcher'. > So you could add a watcher that conditionally controls variable > modifications. I don't think variable watchers are very helpful here. They don't solve the underlying problem: potentially infinite variables of the same name can exist, shadowing each other, with values partly sharing structures. Using variable watchers I can see whether a variable value gets shadowed or unassigned using a set operation - but I can't know whether the previous value still exists, as binding of some other variable, and if it will be stored back into the variable. Nor do I have access to old bindings and their values until the program assigns it back to the variable. I saw that in Bug#70938. Manipulations of a variable can interfere in annoying ways. Functions are different. You have only one dynamic binding (unless in the rare case of using `cl-letf', which is extremely rare). And you always have access to it to undo any prior modification. Michael.