From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton Newsgroups: gmane.emacs.devel Subject: Re: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer Date: Sat, 07 May 2022 09:29:50 -0700 Message-ID: <871qx5uwzl.fsf@athena.silentflame.com> 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="8570"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Notmuch/0.36 Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: monnier@iro.umontreal.ca, 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 18:32:05 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 1nnNLf-0001zw-7X for ged-emacs-devel@m.gmane-mx.org; Sat, 07 May 2022 18:32:05 +0200 Original-Received: from localhost ([::1]:55024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nnNLd-0006bD-Mv for ged-emacs-devel@m.gmane-mx.org; Sat, 07 May 2022 12:32:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnNJl-0005m0-Oe for emacs-devel@gnu.org; Sat, 07 May 2022 12:30:05 -0400 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:37465) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnNJj-0005RO-Up; Sat, 07 May 2022 12:30:05 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CB0D032000D7; Sat, 7 May 2022 12:29:52 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 07 May 2022 12:29:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1651940992; x=1652027392; bh=hC iER9OVnIrtr9z+NcWKnoVzZOndiSeCDvmgYOsuWvM=; b=djPkheo5Y3AxVO3xRV lqRqHoGVePQzXSq7RulW/5IjBkPy9zk7mWAy5A0XKMnGFXAVnz3QSgeOKXY6ibDQ bD+spXk/6nEG9wwY0KNJIdfEWNUx7vCRQFnhr13HFSBU53Uy3+6a5LNd646JqVP6 cD3CyZitQ35qv97P3DR7FKq4Jd8xTzw/iLqBYnu4oQaJp0iURq8C6fVe3bA0vfxT 0+JsuxZlslAuOO5HmFD8HavrIMvgRrmiqr1O1yTgF7JUmr45FYuOFfcwk0yCFhDv 7cbEFxZRGCCctXpR0f8UAUfbjdeLLiE6uVb4/3QgNqf3Jx1OvHvJImBKwEGqRiVs mtkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1651940992; x= 1652027392; bh=hCiER9OVnIrtr9z+NcWKnoVzZOndiSeCDvmgYOsuWvM=; b=l PuyVSaKjuwPz3KDP+ytQC0LugBJlhoGFaUHtm9lWJxdBjsYeJiZC1E+zi0dmHAc6 idvXM+2oZP6as3xHLI30YOVC2EKJ+ZFJ71wiACLNK70iUAXEGKAAFgOSVkM2VKgw jbTnGcXbuI1x2mIgTLg2JMdaGmf7whOZdpPo1Kgkv3xkjZgQBNHm9ovjJDYR4Exx w0ntk/hpVJMsOEADbghOE04BZU2rLgPI9KKuTTnUxGoiEhxHNQmOrkN+pkXuLi2D ZaTS2KUj01CCiD8DRaW2WmGparBatpNKnr4QPfuXw96RRGdXflv53gdwNp4gPOWu l1Wwf+V8FfpFkcZ/OMtig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffgffkfggtgesthdttddttdertdenucfhrhhomhepufgvrghn ucghhhhithhtohhnuceoshhpfihhihhtthhonhesshhpfihhihhtthhonhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpedvjeettdeiteejgeejkefggfehtdekledtfedtteekgfeu keeftdduhfetleejkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvg X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 7 May 2022 12:29:52 -0400 (EDT) Original-Received: by athena.silentflame.com (Postfix, from userid 1000) id CE7101C0248; Sat, 7 May 2022 16:29:50 +0000 (UTC) In-Reply-To: <83tua1zz8h.fsf@gnu.org> Received-SPF: pass client-ip=64.147.123.24; envelope-from=spwhitton@spwhitton.name; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, SPF_HELO_PASS=-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:289408 Archived-At: Hello, On Sat 07 May 2022 at 08:30am +03, Eli Zaretskii wrote: > What do you mean by "touch"? 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. As Stefan said, if the user has deleted the initial scratch message, we do not want to go reinserting it. And similarly if they have changed the mode away from whatever initial-major-mode specifies, we do not want to change it back. The only time we want to do anything is when the buffer does not exist. > This is not about Emacs Lisp, this is an incompatible behavior change, > and we have a section for that in NEWS. Okay. > 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. > > Does this answer your question? I'm still not clear on what safe_call protects us from here. It's in xdisp.c and the comment next to it talks about preventing redisplay, but I don't see how redisplay is relevant to what this function does. Does safe_call also catch all signals and convert them to nil, or something? -- Sean Whitton