emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Kyle Meyer <kyle@kyleam.com>
To: Mikhail Skorzhisnkii <mskorzhinskiy@eml.cc>
Cc: emacs-orgmode@gnu.org
Subject: Re: [org-save-all-org-buffers] Saving is not reliable?
Date: Wed, 09 Dec 2020 01:16:54 -0500	[thread overview]
Message-ID: <87eejz33mx.fsf@kyleam.com> (raw)
In-Reply-To: <87sg8h8sw4.fsf@eml.cc>

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


  reply	other threads:[~2020-12-09  6: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 [this message]
2020-12-09 10:16   ` Mikhail Skorzhisnkii
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=87eejz33mx.fsf@kyleam.com \
    --to=kyle@kyleam.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mskorzhinskiy@eml.cc \
    /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).