From: Mikhail Skorzhisnkii <firstname.lastname@example.org>
To: Kyle Meyer <email@example.com>
Subject: Re: [org-save-all-org-buffers] Saving is not reliable?
Date: Wed, 09 Dec 2020 11:16:55 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
(defadvice save-buffer (before save-buffer-always activate)
"always save buffer"
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)
Kyle Meyer <email@example.com> writes:
> Mikhail Skorzhisnkii writes:
>> Hello forum,
>> I start noticing some time ago that saving org-mode buffers
>> 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
>> 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
>> | + (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
>> 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
>> 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
> 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
> (setq files-done
> (lambda (buffer)
> (and (buffer-live-p buffer)
> (buffer-modified-p buffer)
> (not (buffer-base-buffer buffer)) ; <- skip
> indirect buffers
> (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
> (if arg
> (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
> '("buffer" "buffers" "save")
next prev parent reply other threads:[~2020-12-09 10:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 16:22 [org-save-all-org-buffers] Saving is not reliable? Mikhail Skorzhisnkii
2020-12-09 6:16 ` Kyle Meyer
2020-12-09 10:16 ` Mikhail Skorzhisnkii [this message]
2020-12-09 10:30 ` Eric S Fraga
2020-12-12 23:50 ` Samuel Wales
2020-12-13 15:08 ` Mikhail Skorzhisnkii
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).