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 CEQkMk6k0F/DHAAA0tVLHw (envelope-from ) for ; Wed, 09 Dec 2020 10:17:50 +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 YAq4LU6k0F+pbgAAB5/wlQ (envelope-from ) for ; Wed, 09 Dec 2020 10:17:50 +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 2AFA494023C for ; Wed, 9 Dec 2020 10:17:50 +0000 (UTC) Received: from localhost ([::1]:49556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmwXd-0002D0-3L for larch@yhetil.org; Wed, 09 Dec 2020 05:17:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmwWZ-0002CY-He for emacs-orgmode@gnu.org; Wed, 09 Dec 2020 05:16:43 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:52529) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmwWX-0008BE-Df for emacs-orgmode@gnu.org; Wed, 09 Dec 2020 05:16:43 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6AD5B5C0387; Wed, 9 Dec 2020 05:16:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 09 Dec 2020 05:16:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eml.cc; h= references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; s=fm1; bh=OxpWud1z1eu3E+V42pQdz0O55C WPANrt5/JkZKmx+hE=; b=LtOQb0XZEUU+7pHTe7rSTRqI6yLz/Fsa4kzh/YRdWN Ffu7k8Xa+AnhNp4BRPwASMPjQDnfUj7wdm/MwaYWd2um1TijVR9vAQnTe8a+Mzt0 bmRwpr28MegxmY0QW3ziTZsR2sxRsHF7U5F4no5LpEdIwicjeiytM7MPQD3bdgjq MyRFU1WJcQuxC5pmBRhIg4rzxVK80h/34pcDBUN/cC7Apiq5riUesf+3XNBjsXlY NMI/FM3j1lggWwaG4uvCjA27azvk20OrXpL4z6/EJcTcoklK2IjqDF+vwv/qTZa+ +ol9tGWm4yMAz6Ihy3eCQ6MVOFywWTFBK8ZMEU+PZGFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OxpWud 1z1eu3E+V42pQdz0O55CWPANrt5/JkZKmx+hE=; b=Wm54JzAMsrOTcZFuHGJT70 JGJFIjsGFlue9NC8tyh/+bT9YX+tBATEREjxGUUa9mZT8ez/aV+qa8bvpj0UKb/H 3RGvcwU1DhAZSz0fiuiN2465zwGkecQ42HpgfBxn6N8z0l2zDg7hMK/TQUpBwER8 R4YS72g4PM3FzcXN7AuXADrgkcI00F0qwBU1xnz3Ad6cJn3eiF4ToVqunG52F7pe 1Plb8bgNaG45LbcwTmsOIyED9Zq6ou4X8EMbLgbAVCBqZ1kre0YRdeY021T32VFi U8gJiOX+q6DK5GERNJYM6APmj3p/wanJMBYe7F1Eo7yV+7lOaLYCAsfPQDL1O8Mw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejkedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdludehmdenucfjughrpehffgfhvffujgffkfggtgesthdtredttder tdenucfhrhhomhepofhikhhhrghilhcuufhkohhriihhihhsnhhkihhiuceomhhskhhorh iihhhinhhskhhihiesvghmlhdrtggtqeenucggtffrrghtthgvrhhnpedtgfeuhfeffeeu hedvueevhfduffdvjedvveetueffieejjeekgfefkeduhfegjeenucffohhmrghinhepsh htrggtkhhovhgvrhhflhhofidrtghomhenucfkphepkeekrddvudehrddutdefrddvfeei necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhskh horhiihhhinhhskhhihiesvghmlhdrtggt X-ME-Proxy: Received: from YogaTux (unknown [88.215.103.236]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D5FD108006D; Wed, 9 Dec 2020 05:16:38 -0500 (EST) References: <87sg8h8sw4.fsf@eml.cc> <87eejz33mx.fsf@kyleam.com> User-agent: mu4e 1.4.13; emacs 27.1 From: Mikhail Skorzhisnkii To: Kyle Meyer Subject: Re: [org-save-all-org-buffers] Saving is not reliable? In-reply-to: <87eejz33mx.fsf@kyleam.com> Date: Wed, 09 Dec 2020 11:16:55 +0100 Message-ID: <87czzjgu7c.fsf@eml.cc> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=66.111.4.26; envelope-from=mskorzhinskiy@eml.cc; helo=out2-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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -0.51 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=eml.cc header.s=fm1 header.b=LtOQb0XZ; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=Wm54JzAM; dmarc=pass (policy=none) header.from=eml.cc; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 2AFA494023C X-Spam-Score: -0.51 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: MS+PS3U9hDVI Hi, Kyle, Thank you for finding time to take a look at this. I have experienced data loss once again, so you're right. This is not indirect buffers, i.e. my fix is not working. I was just lucky. Fortunately I managed to capture the moment in emacs when it happens. It's kind of reproduction scenario. Basically I need to modify buffer from search-type agenda. For example, search for tags and then change TODO state or add a note. Then use `org-save-all-org-buffers`. Function will report that it is done its job and buffers will be marked as non-modified. But in fact they are modified and unsaved. I can't reproduce this in emacs without my configuration (i.e. only emacs and most recent org-mode). So it must be something that interfere with buffer "modified" state. I guess I need to review every hook related to buffer saving. I think (but unsure) it is start happening when I have start enabling follow-mode in agenda from start up. For the time being I have applied advice from this stack overflow question: https://stackoverflow.com/questions/3215866/how-to-force-emacs-to-save-even-if-it-thinks-no-changes-need-to-be-saved (defadvice save-buffer (before save-buffer-always activate) "always save buffer" (set-buffer-modified-p t)) It looks like it helps me. I'll report back to this thread when I find the offender. I guess I'm calling (set-buffer-modified-p nil) somewhere unknowingly. Mikhail Skorzhinskii Kyle Meyer writes: > 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)) -- --- Mikhail Skorzhinskii