From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matthew White Newsgroups: gmane.emacs.devel Subject: Re: eval-print-last-sexp: "Selecting deleted buffer" error when the current buffer is killed evaluating the expression Date: Fri, 30 Jul 2021 16:07:53 +0200 Message-ID: <20210730160753.3ca3bcb4@pineapple> References: <20210730005551.5c77f879@pineapple> <831r7gs5px.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/nVA44NW86OpeqL/Tgdt/jYO"; protocol="application/pgp-signature"; micalg=pgp-sha256 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14665"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 30 16:11:08 2021 Return-path: Envelope-to: ged-emacs-devel@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 1m9TEC-0003bb-8V for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jul 2021 16:11:08 +0200 Original-Received: from localhost ([::1]:41742 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9TEA-00026Y-Qm for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Jul 2021 10:11:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9TBI-0005G1-C3 for emacs-devel@gnu.org; Fri, 30 Jul 2021 10:08:08 -0400 Original-Received: from devianza.investici.org ([198.167.222.108]:46623) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9TBF-00041Q-NI for emacs-devel@gnu.org; Fri, 30 Jul 2021 10:08:08 -0400 Original-Received: from mx2.investici.org (unknown [127.0.0.1]) by devianza.investici.org (Postfix) with ESMTP id 4Gbq420pk7z6vHw for ; Fri, 30 Jul 2021 14:08:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1627654082; bh=Tn1L2pN6wUhaZ40AZG7vpITblGlJn831uc6eUHmWIDM=; h=Date:From:To:Subject:In-Reply-To:References:From; b=nqilfGPtwGlQKTzkmizY5iCDSkPFlouTonZ9eoHn4qsVeJfCpjsVKxdYg7BNPp4OH qlf6ZtrMO3MiXGmRCk6k2HuIV8ws9FUCwIZDbGv7z9sGc3ONILfPThPy9W5LmHrCTE hmmFinFKudRTH2cR+qNz+qrCbS+I1K/R4NzQOLRQ= Original-Received: from [198.167.222.108] (mx2.investici.org [198.167.222.108]) (Authenticated sender: mehw.is.me@inventati.org) by localhost (Postfix) with ESMTPSA id 4Gbq414GLJz6vHK for ; Fri, 30 Jul 2021 14:08:01 +0000 (UTC) In-Reply-To: <831r7gs5px.fsf@gnu.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Received-SPF: pass client-ip=198.167.222.108; envelope-from=mehw.is.me@inventati.org; helo=devianza.investici.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271849 Archived-At: --Sig_/nVA44NW86OpeqL/Tgdt/jYO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 30 Jul 2021 08:58:34 +0300 Eli Zaretskii wrote: > > Date: Fri, 30 Jul 2021 00:55:51 +0200 > > From: Matthew White > >=20 > > I tumbled on the error in the subject, "Selecting deleted buffer", > > evaluating the following line in the "*scratch*" buffer with C-j: > >=20 > > (kill-buffer (current-buffer)) > >=20 > > When the other buffer isn't read-only, suppose "*foo*" is selected > > after killing the current buffer "*scratch*", the error "Selecting > > deleted buffer" appears into the echo area and the return value of > > the evaluation is printed into the other buffer "*foo*". > >=20 > > If the other buffer is "*Messages*", which is read-only, the error > > "Buffer is read-only: #" will appear instead. > >=20 > > I'd like to discuss the possibility to enforce printing the output > > either to the initial current buffer when eval-print-last-sexp has > > been called, or to the echo area when the prefix '-' is given. If > > the initial current buffer (aka standard-output) is killed, during > > the evaluation of the expression, we fall back to the echo area as > > the output medium. =20 >=20 > Could you please tell what are the real-life situations where this > problem happens and causes trouble? Killing the current buffer this > way is unusual, so why isn't what we have now sufficient? You tried > to insert something into a killed buffer, Emacs told you it cannot do > that; why is that a problem? I understand that such occasions are rare, I mean killing the current buffer evaluating an expression also in the current buffer like: (kill-buffer (current-buffer)) eval-print-last-sexp is trying to insert something into a dead buffer, by calling terpri with standard-output set to the dead buffer. This could be prevented by checking standard-output: (when (buffer-live-p standard-output) (terpri)) Less uncommon than killing the current buffer evaluating an expression with C-j, is redirecting the output to the echo area with a '-' prefix C-u - C-j. I'd expect no output into the current buffer, and the call to eval-last-sexp respects this, while terpri does not and prints into the standard-output (aka current buffer at the time C-j was pressed). There's also the strange behavior of printing to a buffer which is not the one where the expression was evaluated. This is also rare, happens when the buffer is killed, like described previously: ;; Always prints to the actual current buffer. (eval-last-sexp (or eval-last-sexp-arg-internal t)) >=20 > IME, trying to "fix" such obscure problems causes problems of its own > that we then get to rectify for several releases in the future, so the > net gains are very small if there are any. I agree, there is a little gain into that. I just explored the source of the problems to understand what they are. IMHO, when C-u - C-j is used terpri shouldn't print to stadard-output, since the evaluation's return value is destined to the echo area. And checking if standard-output is a live buffer is also trivial. What do you think? Thanks. -Matthew --Sig_/nVA44NW86OpeqL/Tgdt/jYO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEHleiF1SoBpqVdUvfw5wJ3TZNsgAFAmEEB7kACgkQw5wJ3TZN sgBjYwf/bIoGrorEg9tFjEyTt/64PEE3jETS7JkLeTaET8I8V5Xo3jAkntgbbM/2 oKOI11ku2OZ+oSppcvhNhxgddXut9r8b/K8UBmt9ZDOgebQNg22Umz3H2fuhCOOk pm4hcMMK4U32MENmxEoG6nYo3kZRp75cHQEgmc9RfLU5xq0n5UDBMaCdTgP1QSnQ 1TVdlDsSTmbXfNW5XV4eLTUOdul7GQ1SUYGuJN95BqMHpf/p5Q/z0BVS2bWtBAzs rcKBhSOr+b9a6MupN/BruvAf8uS0QtCadboE2Nfz5373JuukIuv7Plrs5GUYv8HR LjuNYlAy84qjwC5r9dH8+NdTpMAiBQ== =S1y7 -----END PGP SIGNATURE----- --Sig_/nVA44NW86OpeqL/Tgdt/jYO--