From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id IHWXBf9r0F/RKwAA0tVLHw (envelope-from ) for ; Wed, 09 Dec 2020 06:17:35 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SB9bAf9r0F+hKQAAB5/wlQ (envelope-from ) for ; Wed, 09 Dec 2020 06:17:35 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DB47E94060F for ; Wed, 9 Dec 2020 06:17:32 +0000 (UTC) Received: from localhost ([::1]:56816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmsn4-0002Tv-KC for larch@yhetil.org; Wed, 09 Dec 2020 01:17:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmsma-0002SM-Ve for emacs-orgmode@gnu.org; Wed, 09 Dec 2020 01:17:00 -0500 Received: from out1.migadu.com ([2001:41d0:2:863f::]:7578) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmsmY-0000L7-UL for emacs-orgmode@gnu.org; Wed, 09 Dec 2020 01:17:00 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kyle Meyer To: Mikhail Skorzhisnkii Subject: Re: [org-save-all-org-buffers] Saving is not reliable? In-Reply-To: <87sg8h8sw4.fsf@eml.cc> References: <87sg8h8sw4.fsf@eml.cc> Date: Wed, 09 Dec 2020 01:16:54 -0500 Message-ID: <87eejz33mx.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2001:41d0:2:863f::; envelope-from=kyle@kyleam.com; helo=out1.migadu.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-TUID: 90/faN8OnGaV Mikhail Skorzhisnkii writes: > Hello forum, > > I start noticing some time ago that saving org-mode buffers works > unreliably in my setup. Most of the time I am using function > `org-save-all-org-buffers' from core org. Unreliable in that some Org buffers are left in a modified state? [...] > Possibly there is something wrong in my customisations. But without a > reproduction scenario, I don't see a way to prove it. However, after I > made a tiny change to the function, I stopped seeing these problems at > all. Here is the fix I have applied: > > ,---- > | diff --git a/lisp/org.elf b/lisp/org.el > | index df3f377f6..448dc4a88 100644 > | --- a/lisp/org.el > | +++ b/lisp/org.el > | @@ -15229,7 +15229,9 @@ The value is a list, with zero or more of the symbols `effort', `appt', > | "Save all Org buffers without user confirmation." > | (interactive) > | (message "Saving all Org buffers...") > | - (save-some-buffers t (lambda () (derived-mode-p 'org-mode))) > | + (save-some-buffers t (lambda () > | + (and (derived-mode-p 'org-mode) > | + (not (buffer-base-buffer))))) > | (when (featurep 'org-id) (org-id-locations-save)) > | (message "Saving all Org buffers... done")) > `---- > > My theory was that `save-some-buffers' may work unreliably with indirect > buffers, so I've excluded them from the saving. Again, I have tried to > prove it by using indirect buffer and saving it instead of base buffer. > But it worked without a problem. So even if my theory is correct, bug > not reproducing every time. Nevertheless I am having this change already > for two weeks and I don't have reproduction of this bug. Previously I've > noticed loosing data every day or so. Hmm, I may be completely missing something, but for what it's worth, I'd be surprised if indirect buffers are the culprit. When you save an indirect buffer directly, it should just save the base buffer. And in any case, save-some-buffers should skip indirect buffers. Here is the relevant handling from save-some-buffers, with the key line marked: (setq files-done (map-y-or-n-p (lambda (buffer) (and (buffer-live-p buffer) (buffer-modified-p buffer) (not (buffer-base-buffer buffer)) ; <- skip indirect buffers (or (buffer-file-name buffer) (with-current-buffer buffer (or (eq buffer-offer-save 'always) (and pred buffer-offer-save (> (buffer-size) 0))))) (or (not (functionp pred)) (with-current-buffer buffer (funcall pred))) (if arg t (setq queried t) (if (buffer-file-name buffer) (format "Save file %s? " (buffer-file-name buffer)) (format "Save buffer %s? " (buffer-name buffer)))))) (lambda (buffer) (with-current-buffer buffer (save-buffer))) (buffer-list) '("buffer" "buffers" "save") save-some-buffers-action-alist))