emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Kyle Meyer <kyle@kyleam.com>
To: No Wayman <iarchivedmywholelife@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]
Date: Mon, 06 Apr 2020 05:51:30 +0000	[thread overview]
Message-ID: <87lfn917rx.fsf@kyleam.com> (raw)
In-Reply-To: <87zhcybjz5.fsf@gmail.com>

No Wayman <iarchivedmywholelife@gmail.com> writes:

> The logic for saving the archive buffer in org-archive-subtree 
> does not consider the (default) value  of 'from-org for 
> org-archive-subtree-save-file-p.

Hmm, indeed, the change from 3d0282ef8 (New option
`org-archive-subtree-save-file-p', 2020-01-31) looks incomplete.

> While patching this, I realized I'm not sure I understand the 
> intended logic of each value for org-archive-subtree-save-file-p.

From digging a bit, I think the history went like this:

  * All the way back in 4be4c5623 (version 4.12a, 2008-01-31),
    org-archive-subtree saved the archive buffer, except when it was the
    current buffer.

  [ The next two aren't relevant for the save part, but I'm noting
    because we should cleaned them up. ]

  * As of bf09955fe (Bugfix for `org-archive-subtree', 2008-03-01), the
    buffer was killed after being saved.

  * 343f3c478 (Keep archive buffer after archiving something to it,
    2009-10-28) reverted the killing, though it left behind a stale
    comment saying the buffer will be killed.

  * 63f6e851b (Do not save target buffer after archiving subtree,
    2017-11-25) stopped saving the buffer for performance reasons.

  * Some users preferred the older behavior.  An associated Debian bug
    was opened.


    In response, Bastien committed 3d0282ef8 to offer more control over
    when saving happens.

> When setting it to 't', the defcustom :tag string claims "Always 
> save the archive buffer".
> This is not the case if archiving from within the current buffer. 
> Perhaps a clearer :tag string?
> #+begin_src emacs-lisp
> (defcustom org-archive-subtree-save-file-p 'from-org
>   ;;...
>   (const :tag "Save the archive buffer unless it is the current 
>   buffer" t)
>   ;;...
>   ))
> #+end_src

Yeah, I'd say that's an improvement, though the same "unless it is the
current buffer" would be true for from-org as well, were it wired up.

> The value 'from-org also still saves the archive buffer when 
> archiving from a buffer that is not in Org mode.

I'm confused by this statement.  To me it looks like save-buffer will
_never_ be called when org-archive-subtree-save-file-p is from-org:

    (unless (eq this-buffer buffer)
      (when (or (eq org-archive-subtree-save-file-p t)
                (and (boundp 'org-archive-from-agenda)
                     (eq org-archive-subtree-save-file-p 'from-agenda)))

> I'm not entirely sure of its purpose. If the intent is to allow an 
> option that prevents saving only when archiving from the agenda,
> I suggest a single option excluding that case and saving for 
> other, non-nil values:

Based on the history above, I believe the main purpose is to give users
a way to reverse the "no saving" behavior made in 63f6e851b (Do not save
target buffer after archiving subtree, 2017-11-25).  I'm _guessing_
that, on top of that, the idea adding a from-agenda value was that some
users may want to save only when archiving from the agenda, because in
that case they're a bit removed from the buffer and might not think to
save it, or something along those lines.

> #+begin_src emacs-lisp
> (defcustom org-archive-subtree-save-file-p 'unless-agenda
>   "Conditionally save the archive file after archiving a subtree.
> The value 'unless-agenda prevents saving from the agenda-view.
> Other non-nil values save the archive buffer unless it is the 
> current buffer."
>   :group 'org-archive
>   :package-version '(Org . "9.4")
>   :type '(choice
>           (const :tag "Do not save archive buffer when archiving 
>           from an agenda view" unless-agenda)
>           (const :tag "Save the archive buffer unless it is the 
>           current buffer" t)
>           (const :tag "Do not save the archive buffer")))
> #+end_src
> Then the saving logic in org-archive-subtree becomes:
> #+begin_src emacs-lisp
> (when org-archive-subtree-save-file-p
>   (unless (or (eq buffer this-buffer)
>               (and (eq org-archive-subtree-save-file-p 
>               'unless-agenda)
>                    ;;bound when called from org-agenda.el
>                    (boundp 'org-archive-from-agenda)))
>     (save-buffer)))
> #+end_src

Assuming what I said above is true, I think what you propose here loses
the ability to save only when archiving from the agenda.  And more
importantly, users would not be able to give a blanket "don't save" in
order to retain the behavior introduced by 63f6e851b (Do not save target
buffer after archiving subtree, 2017-11-25).

  reply	other threads:[~2020-04-06  6:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 20:05 Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)] No Wayman
2020-04-06  5:51 ` Kyle Meyer [this message]
2020-04-06 16:49   ` No Wayman
2020-04-07  0:37     ` Kyle Meyer
2020-04-07 19:00       ` No Wayman
2020-04-07 19:06         ` No Wayman
2020-04-08  2:58           ` Kyle Meyer

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=87lfn917rx.fsf@kyleam.com \
    --to=kyle@kyleam.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=iarchivedmywholelife@gmail.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).