From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer Date: Sat, 07 May 2022 09:51:54 -0400 Message-ID: References: <165162665935.26821.8964921720746152690@vcs2.savannah.gnu.org> <20220504011059.9F667C009A8@vcs2.savannah.gnu.org> <87levhdfeh.fsf@athena.silentflame.com> <87y1zhe5qz.fsf@athena.silentflame.com> <87levhe24h.fsf@athena.silentflame.com> <871qx74or6.fsf@melete.silentflame.com> <83r1571an1.fsf@gnu.org> <871qx6ea2x.fsf@athena.silentflame.com> <83tua1zz8h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31642"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Sean Whitton , rpluim@gmail.com, emacs-devel@gnu.org, 55257-submitter@debbugs.gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 07 15:53:06 2022 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 1nnKrq-00080s-NI for ged-emacs-devel@m.gmane-mx.org; Sat, 07 May 2022 15:53:06 +0200 Original-Received: from localhost ([::1]:50818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nnKro-0003yO-SO for ged-emacs-devel@m.gmane-mx.org; Sat, 07 May 2022 09:53:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnKqq-0003Cq-DH for emacs-devel@gnu.org; Sat, 07 May 2022 09:52:04 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnKqm-0000h8-Re; Sat, 07 May 2022 09:52:02 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 58F03440C44; Sat, 7 May 2022 09:51:58 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C8175440ABD; Sat, 7 May 2022 09:51:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651931516; bh=FHmSdTLH8rXojfrzyZW2XtHHG4IDfm7kqAg65AODB+0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=b3YjXSvj6OajgVn0eU6F2IKuY3hp3lUQBpNz2DBvEk2hEvXiGhSN1rFo5RX9x9EwJ NwP5oN7kNicO5gHIvcvKf4V74EK1QVwFUpVITzqXSSpJVh8CXSFcA6/qq55+6cuGNe DJJ9TByg7ED+mE8/+zVjiFaNCdm5dH6vxUzbMbfP+WVbbmvKeCYtdflm7DPcw8ATS3 sUHQaLoTuKD89BmTEp7GNPvKuJY9dex0+kwM/ORY6O+uQDd3LpmghFJpCgzbR5nnbn P9Zm2OlZBkwPrfmMYOFDVbCFVlGPS8SBMCbIJq+HmlO5vNcIjh0JzzcNR5D84KArlx xugTq7WyTERgA== Original-Received: from alfajor (modemcable034.207-20-96.mc.videotron.ca [96.20.207.34]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 75127120278; Sat, 7 May 2022 09:51:56 -0400 (EDT) In-Reply-To: <83tua1zz8h.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 07 May 2022 08:30:06 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:289392 Archived-At: >> I had the same intuition at first, but I don't think there is another >> way -- the code wants to touch the buffer at all only if it wasn't >> already there. > What do you mean by "touch"? Modify the buffer in any way (change its content or some of its buffer-local variables (e.g. the major mode)). His code just reproduces the existing code's behavior, AFAICT. > Doesn't get-buffer already "touch" the buffer if it exists? > And determining whether the buffer has any stuff in it (if this is the > concern here) is just one function call away, and is very fast. Not sure what it is we'd be gaining. The code is just trying to avoid modifying the buffer in any way (since that would likely lose information or undo something the user did, without its explicit request). > But get-buffer-create already does all that internally, and it exists > for this very purpose. I don't really understand the objections, to > tell the truth. Unless some more fundamental problem is involved, > which is why I asked about the reasons. Indeed `get-buffer-create` begins by calling `get-buffer` so there's redundancy at run-time. But we don't export any `create-buffer` function which presumes that there is no buffer by that name, so when we want to create a buffer named *scratch* and we know there is no such buffer yet, we still have to call `get-buffer-create` :-( Since we want to preserve the invariant that there can't be two buffers with the same name, we don't have much choice in this matter (we couldn't offer a `create-buffer` and just trust users to only call it when it's safe, tho we could do that in the C code that's not exported to ELisp). > My bother is that the function you call could signal an error at some > point, and that could cause trouble to some of the callers, perhaps. > Calling Lisp from C should always assume this could happen, because > basically the Lisp function you call is out of your control, and you > cannot reliably assume anything about what it does or will do at some > future time. I think this is not needed here, or at least we haven't needed it so far: the old C code called `Fset_buffer_major_mode` which itself calls `call0 (function);` where `function` is the `initial-major-mode`. Stefan