From: Mikhail Skorzhisnkii <mskorzhinskiy@eml.cc>
To: Kyle Meyer <kyle@kyleam.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [org-save-all-org-buffers] Saving is not reliable?
Date: Wed, 09 Dec 2020 11:16:55 +0100 [thread overview]
Message-ID: <87czzjgu7c.fsf@eml.cc> (raw)
In-Reply-To: <87eejz33mx.fsf@kyleam.com>
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 <kyle@kyleam.com> 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
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
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czzjgu7c.fsf@eml.cc \
--to=mskorzhinskiy@eml.cc \
--cc=emacs-orgmode@gnu.org \
--cc=kyle@kyleam.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).