emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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 

  (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

  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:

  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 \


* 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).