From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#56110: 27+; switching from line-mode to char-mode Date: Thu, 23 Jun 2022 18:56:30 +0200 Message-ID: <87k097mi81.fsf@web.de> References: <875ykvs9gq.fsf@electra.home.arpa> <87wndaw84w.fsf@web.de> <87sfnyw6m7.fsf@web.de> <877d58obnn.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19321"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: "C. Michailidis" , 56110@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 23 19:19:54 2022 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 1o4QUk-0004oK-IA for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 19:19:54 +0200 Original-Received: from localhost ([::1]:51680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4QUj-0007cj-FP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Jun 2022 13:19:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60992) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Q8c-0002rL-Ui for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 12:57:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45814) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4Q8c-0006SS-Mj for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 12:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o4Q8c-0000PL-H5 for bug-gnu-emacs@gnu.org; Thu, 23 Jun 2022 12:57: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: Thu, 23 Jun 2022 16:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56110 X-GNU-PR-Package: emacs Original-Received: via spool by 56110-submit@debbugs.gnu.org id=B56110.16560034041540 (code B ref 56110); Thu, 23 Jun 2022 16:57:02 +0000 Original-Received: (at 56110) by debbugs.gnu.org; 23 Jun 2022 16:56:44 +0000 Original-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 1o4Q8J-0000Om-LV for submit@debbugs.gnu.org; Thu, 23 Jun 2022 12:56:43 -0400 Original-Received: from mout.web.de ([212.227.15.3]:47287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4Q8H-0000OS-9t for 56110@debbugs.gnu.org; Thu, 23 Jun 2022 12:56:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1656003391; bh=IEcUusQRcjkhWfpaJygkfPeXHChEACc9ykUrvgXy3mI=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=pnwjz1eM36E+/NXJB+vAz2DlgL8gkQBXrQR1uLIzW7dckNUNDyLx3HcYFYMzuqWCe UtPrL8QPVxByjldomW2qnXsvZwdaH4RsM7yUT6SiWbJdlgQGAfOq6z3ZZpK0nY0p5u VP7uMwNNurwjTPSXC4ESu8GI/mG6Xzsf7F9PL0uE= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Original-Received: from drachen.dragon ([88.66.201.45]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MmQcf-1nMav0252X-00iJiR; Thu, 23 Jun 2022 18:56:31 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 22 Jun 2022 20:02:55 -0400") X-Provags-ID: V03:K1:jxGtTtm/zT5ce4OWplqJDirG7/YzIN2jakTNHqvdH1JX3JWDF5I 3Ub/dY8n24k04aN5vBbgcOhrC7OjX/UjTEFlvpzkWd2I/GeIqyegm35h9ydVgmk4blywsmC VK2nTMjO2VPQ3dd86p1nVvLibq+BJPN7D/YgBNK0a5yjX0rc/5fVHG13hhdvi4nMh3+HzTb Pb/ZUFwSfo4Xa0yRW6k3A== X-UI-Out-Filterresults: notjunk:1;V03:K0:1XpQKZfD7Xc=:a5QBgd+IbbRnxgSr2e6aey 2YNKwf9/mQ9GX3hKeR13dRQsA/AYILLClQHz1vwAC8d4AdPGoCuO1f98P9ZJEbk4lUD4B/Fl1 QRhaH/Db2HMrqDPN5kf51OzTv5KwTvnluLfneUyJspZucEV7PCzKFic57NToZEUYdzSbolWLe SJvJO/lhhZpgPRahMIYOyE01YPbWD+dFxElXHID7BT42s5gAkl7XAUsuegLYLZBsNTQW+F+fu QcaO7y3/MIkRYI2FaPsrcJKrT4GqFg91PeO4XYkzoOX4l8sraMiT6kuT+ej/0ZR+btq1SGJms AxBl0WfxBZNWCN42000l7thRSO1DNyeiDqyp8rCYiclcK+mIg5H5u1MTpSnETiSd7U3yo3Qo4 pqEfXMjnU646LB9qq1I/nXsB7ius4qhNiFliV5arCyy1loBOPLoeQI0GhrYw/sY+4lum//KEG jbX7dl4YqXaq2RayFJQ9o4lWCAkU/BbgB3TM4UqYAQ8IBO0zTvACdxYwir8fUrCX5U4m8nfBk SlKbYQ4Kb+ZBEfRgyKmxsYULG8A+l16HtZXV12b8zXbSD9RFl3rTAvFCccUMRBOhxLDMAoaBd 93gtAJBpN3VyTULPDIZPUi2CbMUEI73njYEZiaGGHOenMe9BDSmp26887YE5J/XsdjeKnWwvK 897i2R18iXKlpJ1h44q6uib6rtCxHwRmdcoDl6O80GqVllmomtfxFsJBPgvNrnzx5L8TjWzqW WGEXLgJqLKx9imPfudMthuOjmRIzs4ckd4ZSzSkM+/GomIx+4H+8et1mwH0yo7FqPyNASx5W 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" Xref: news.gmane.io gmane.emacs.bugs:235124 Archived-At: Stefan Monnier writes: > > That works - but I fail to understand why a simple `let' doesn't suffice > > (which works as well): > > Depends if you want to have to think about what other code does or > not. I want. The initial revision by Richard already looks like #+begin_src emacs-lisp (unwind-protect (progn (setq term-input-sender (symbol-function 'term-send-string)) (end-of-line) (term-send-input)) (setq term-input-sender save-input-sender)) #+end_src I checked (using variable watchers) that when I replace unwind-protect+setq with let, the executed code doesn't leave the scope of the let. So why was it written like that? `term-input-sender' has a buffer local binding (it already had in the initial revision from 1994) - but the current buffer is not changed in between. Did `let' back then not work with buffer-local bindings - or what could have been the intention to avoid `let'? > If you don't, then `let` is not the same: e.g. if some other code uses > `add/remove-function` on that variable within your `let`, their changes > will be lost when your `let` ends. Yeah, such things - but I don't think anything like this is crucial here. Thanks, Michael.