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 OG+QIvlczl/oIwAA0tVLHw (envelope-from ) for ; Mon, 07 Dec 2020 16:48:57 +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 CLV0Hvlczl8xYQAAB5/wlQ (envelope-from ) for ; Mon, 07 Dec 2020 16:48:57 +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 E74499405D4 for ; Mon, 7 Dec 2020 16:48:54 +0000 (UTC) Received: from localhost ([::1]:55608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmJgy-0007EG-RA for larch@yhetil.org; Mon, 07 Dec 2020 11:48:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmJg4-0007DC-6q for emacs-orgmode@gnu.org; Mon, 07 Dec 2020 11:47:58 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:38433) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmJg1-00019J-4m for emacs-orgmode@gnu.org; Mon, 07 Dec 2020 11:47:55 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 65D8D453 for ; Mon, 7 Dec 2020 11:47:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 07 Dec 2020 11:47:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eml.cc; h=from :to:subject:date:message-id:mime-version:content-type; s=fm1; bh=yFFYI5sFTjLtuRwiylW6YC+zzy2Y+TOhAVQjTPyn+Wg=; b=rBmABZAp2PXw ND2BJDhp8urNPPK9x0A3zmay3eNNFo8sc8Avh65/8vIyNG9wx/F5O0YFl7XPxTQz 8nsHYLrrmZES9ZnLEZR0lvOiq3Qjrf7eMCgF3zgggWnGC8B0bcF0EBetGnsMfckL eUgC0lLhbUdmbfcUn3zufsBLUQuv4yKHnEZ6AF+tt6ouMBJcxg0Y6otnCSCfhSCH bwQPPJB0c5rsE3jMiMYjcPWqgKd7YDwHvZPK6RYNGHfQmneFEFJJQcS8Zk/3nCTC Ut4FCV6BA/kNDPdBGnJ+tnH6SIYt6XtJUe6QCN2HeX/K8BZ0OvfJpJBRYo3LAgYu GHarcjjrFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=yFFYI5sFTjLtuRwiylW6YC+zzy2Y+ TOhAVQjTPyn+Wg=; b=SVZVEkAeFhmCAEKKMlL7+AjL2GCLhg3Vok9YYYOwVFGaC sr/CDMDmn0zyHzdv4O7KrI5jM160U/4yuZFtg5JTH2Pj8NxsEecF2TQE4beoaVlf LQfjkjDpD7PEA0dZM+lJiwAeukt8ExHPi8EXz81J8R56os/XEuy507RDLo6MCzRr pQWV2aEH5ONwMgFNjOLRxXy4NQOu+6yf81/RxIPaULy6Ti1HAk1ytKBzhTuhlpK+ qdlHuXYxrx5ZwresDP+O1MZwQPbQAgvRl1rr8keOt0R1yCq0lP558G03IebWvVCW dzgXsGXBL4cX+M9xPuJJqEYNKQ9PnovDilKsN8uoQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgledvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdlfedtmdenucfjughrpefhvf fuffgfkfggtgesrgdtreertderjeenucfhrhhomhepofhikhhhrghilhcuufhkohhriihh ihhsnhhkihhiuceomhhskhhorhiihhhinhhskhhihiesvghmlhdrtggtqeenucggtffrrg htthgvrhhnpedvleekhfehudeugeeujefgtdejgeelveffgfdtvefghfeuledvlefgteet jeehjeenucfkphepkeekrddvudehrddutdefrddvfeeinecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhskhhorhiihhhinhhskhhihiesvghm lhdrtggt X-ME-Proxy: Received: from YogaTux (unknown [88.215.103.236]) by mail.messagingengine.com (Postfix) with ESMTPA id 9BABE108005B for ; Mon, 7 Dec 2020 11:47:47 -0500 (EST) From: Mikhail Skorzhisnkii To: emacs-orgmode@gnu.org Subject: [org-save-all-org-buffers] Saving is not reliable? Date: Mon, 07 Dec 2020 17:22:54 +0100 User-agent: mu4e 1.4.13; emacs 27.1 Message-ID: <87sg8h8sw4.fsf@eml.cc> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" Received-SPF: pass client-ip=64.147.123.25; envelope-from=mskorzhinskiy@eml.cc; helo=wout2-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, HTML_MESSAGE=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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.00 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=eml.cc header.s=fm1 header.b=rBmABZAp; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=SVZVEkAe; 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: E74499405D4 X-Spam-Score: -2.00 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: J/SlU6ynlyJG --=-=-= Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hello forum,

I start noticing some time ago that saving org-mode buffers works unreliabl= y in my setup. Most of the time I am using function org-save-all-org-buffers<= /code> from core org. Unfortunately I don=E2=80=99t have a good reproductio= n scenarios of this bug. In fact I don=E2=80=99t have reproduction scenario= at all. It just happens sometimes: I am sure I saved all org buffers I had= , then restart emacs and then I see that some changes were not actually sav= ed.

Possibly there is something wrong in my customisations. But without a repro= duction scenario, I don=E2=80=99t see a way to prove it. However, after I m= ade 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-locatio=
ns-save))
   (message "Saving all Org buffers... done"))

My theory was that save-some-buffers may work unreliably with indirect= buffers, so I=E2=80=99ve excluded them from the saving. Again, I have trie= d 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 t= wo weeks and I don=E2=80=99t have reproduction of this bug. Previously I=E2= =80=99ve noticed loosing data every day or so.

I don=E2=80=99t suggest to apply this patch, but may be someone have\had th= e same problem or have a deeper insight how indirect buffers work and why m= y fix may be a working solution?

Kind regards,
Mikhail Skorzhinskii

--=-=-= Content-Type: text/plain Content-Disposition: inline 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. Unfortunately I don't have a good reproduction scenarios of this bug. In fact I don't have reproduction scenario at all. It just happens sometimes: I am sure I saved all org buffers I had, then restart emacs and then I see that some changes were not actually saved. 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. I don't suggest to apply this patch, but may be someone have\had the same problem or have a deeper insight how indirect buffers work and why my fix may be a working solution? Kind regards, Mikhail Skorzhinskii --=-=-=--