From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master f2d2fe6fc8: server-execute: Initialize the *scratch* buffer Date: Sat, 07 May 2022 08:30:06 +0300 Message-ID: <83tua1zz8h.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27513"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, emacs-devel@gnu.org, 55257-submitter@debbugs.gnu.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 07 07:32:37 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 1nnD3V-0006wP-6f for ged-emacs-devel@m.gmane-mx.org; Sat, 07 May 2022 07:32:37 +0200 Original-Received: from localhost ([::1]:48206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nnD3T-0003AP-Ig for ged-emacs-devel@m.gmane-mx.org; Sat, 07 May 2022 01:32:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnD1H-00019O-D0 for emacs-devel@gnu.org; Sat, 07 May 2022 01:30:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33452) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnD1F-0000XP-Vu; Sat, 07 May 2022 01:30:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ezd5cwbbZv6RgO4trctvKfiL2GtxFUesmadHv/9ykCc=; b=G5nlKToX65g/ xsVvtbIio1IouDZWkodXbUvLfvrm33TL5uPyNOpncc40a1LG2KzXd4zZKxfC/tWvo1iqLl/5XUBsG KSjN9qbjsOTP68eXqkvQA9Da8u3xEw7aDGgXHmlnS95R7WMpjTD+5R0ecSqTk2fChUycoGrzwIwOY 7wtgI5C3etk3gNzZdcpW1qev88u+uODDE3hKBaTtD3q/B4Pu6lEeDDwAXrQiGAkmxYOtup1Lt76N1 c/tMmY0bV6UJTFjYnSGjosulozKQ4BNX/xe7tu9jcUb9pdaIFQc1m6s5E9STUIt+yaqE8p0Exb9Xv KSKhNsZo5xHTti9KvMHbrw==; Original-Received: from [87.69.77.57] (port=1780 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnD1F-00075B-Eu; Sat, 07 May 2022 01:30:17 -0400 In-Reply-To: <871qx6ea2x.fsf@athena.silentflame.com> (message from Sean Whitton on Fri, 06 May 2022 12:26:46 -0700) 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:289368 Archived-At: > From: Sean Whitton > Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, emacs-devel@gnu.org, > 55257-submitter@debbugs.gnu.org > Date: Fri, 06 May 2022 12:26:46 -0700 > > >> +(defun get-initial-buffer-create () > >> + "Return the \*scratch\* buffer, creating a new one if needed." > >> + (if-let ((scratch (get-buffer "*scratch*"))) > >> + scratch > >> + (prog1 (setq scratch (get-buffer-create "*scratch*")) > >> + (with-current-buffer scratch > >> + (when initial-scratch-message > >> + (insert (substitute-command-keys initial-scratch-message)) > >> + (set-buffer-modified-p nil)) > >> + (funcall initial-major-mode))))) > > > > It's somewhat inelegant to explicitly test for the buffer's existence > > before you call get-buffer-create. Is that only to avoid changing its > > contents? If so, can't you test for that in some other way? > > 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"? 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. > And the code path where it already exists will be by far > the most commonly called, so it seems best to avoid calling > with-current-buffer if we don't have to. 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. > >> + return call0 (intern ("get-initial-buffer-create")); > > > > get-initial-buffer-create shows the initial-scratch-message, something > > the C code you are replacing didn't do. This is a change in behavior > > that should at least be documented, if not fixed. > > This is deliberate -- to my mind I'm fixing the same bug as the one in > server.el. other-buffer recreates *scratch* for the same sort of > reasons that 'emacsclient -nc' does. > > Where were you thinking it should be documented? The Emacs Lisp changes > section of NEWS? This is not about Emacs Lisp, this is an incompatible behavior change, and we have a section for that in NEWS. > > I also wonder whether we should use safe_call in these places. > > Could you say more? 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?