From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: New feature? Remove duplicate subheadings, preserving order
Date: Wed, 03 Jan 2018 01:24:25 -0600 [thread overview]
Message-ID: <87fu7nv1zq.fsf@alphapapa.net> (raw)
In-Reply-To: CAJr1M6cVrzZ59Vw9Wc-dNsLZbCXB6OE1j7FpgZ5AR1xENBv6aQ@mail.gmail.com
Allen Li <vianchielfaura@gmail.com> writes:
> Designing around actual use cases that users have an immediate use for
> is better than trying to predict what users might need in the far
> future, especially if adding those features requires extra complexity.
You seem to be approaching this from a "use case" perspective. I and
several other posters on the list are concerned from the "potential
damage" perspective. It's vitally important as software developers to
anticipate potential user *actions*, regardless of their intentions or
needs, and to proactively defend against mistakes that may cause data
loss.
> Everyone should be keeping reliable backups. This is reiterated all
> the time, yet no one seems to follow it? =)
As I mentioned, I am not merely hypothesizing: I have experienced such
data loss myself, which I only recovered months after the fact when I
noticed and was able to track it down in the git repository I
automatically commit most of my Org files to. This was a
time-consuming, laborious, manual process which we cannot expect most
Org users to be able to do; how many Org users do you think know how to
use git and commit all their Org files to it? On top of that, as I and
others mentioned, due to the nature of Emacs, Org, and plain-text
buffers, it is very easy for such changes to happen outside the visible
portion of the buffer, in which case even the most experienced user is
unlikely to notice such data loss. In that case, it might go
permanently unnoticed. For example, I have some large Org files that I
capture data into, with hundreds or thousands of top-level headings. If
I accidentally cut one of those subtrees, outside the visible portion of
the buffer, which I had captured weeks or months earlier, how would I
even know that it was missing? Most likely I would not, because the
whole point of storing them in Org is that I will forget about them if I
don't.
An analogy is, if you ran an "rm -rf" command with a wildcard, and
accidentally left off a slash somewhere without realizing it, how long
would it be before you noticed that you had deleted the wrong data?
What if you were operating on a directory deep in a hierarchy that is
essentially an archive of rarely accessed files? How long would it be
before you noticed the mistake? Would you still be able to recover from
it? What if this happened in a script you wrote, rather than an
interactive command? Have you ever made a mistake in a Bash script that
had undesirable effects? I can't help but be reminded of this recent
classic:
https://github.com/ValveSoftware/steam-for-linux/issues/3671
Another anecdote: I once almost lost my GPG private key, because somehow
(I still have no idea what happened) it was truncated. This went
unnoticed by me for a long time, and the truncated file was *backed up*
over and over again. When I finally noticed, all of my readily
available backups had the truncated version of the file. I was
only--very luckily!--able to recover it by digging out old CD-R backups
I had made years earlier, one of which had an intact copy of the file.
That experience taught me some lessons, among which are 1. Keep your old
backups, and 2. Respect Murphy's Law.
> If you had an immediate use case in mind, I would love to hear it.
> There's no need to suggest your use case as conceivable if it's
> something you could benefit from immediately.
So the "use case" here is simply "using Org, without losing data by
accidentally activating a command in Emacs that operates on data that
may or may not be currently visible--because Emacs and Org are
incredibly complex software that is extensively customized by users in
ways that the developers often do not anticipate--therefore we should
use extra caution in code that manipulates user data in destructive
ways."
I hope that these explanations help clarify our perspectives. We are
not attacking you, your code, or its potential usefulness. We are
simply concerned about implementing such things in ways that are best
for users.
Thanks,
Adam
next prev parent reply other threads:[~2018-01-03 7:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 2:42 New feature? Remove duplicate subheadings, preserving order Allen Li
2018-01-01 5:55 ` Marcin Borkowski
2018-01-01 10:04 ` Nicolas Goaziou
2018-01-01 11:59 ` Allen Li
2018-01-01 18:26 ` Nicolas Goaziou
2018-01-01 23:04 ` Allen Li
2018-01-02 4:07 ` Adam Porter
2018-01-02 7:40 ` Allen Li
2018-01-02 14:36 ` Robert Horn
2018-01-02 21:34 ` Allen Li
2018-01-02 16:36 ` Nick Dokos
2018-01-02 21:22 ` Allen Li
2018-01-03 7:24 ` Adam Porter [this message]
2018-01-03 7:40 ` Adam Porter
2018-01-03 8:19 ` Ihor Radchenko
2018-01-03 9:39 ` Adam Porter
2018-01-02 15:28 ` Florian Beck
2018-01-02 21:28 ` Allen Li
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=87fu7nv1zq.fsf@alphapapa.net \
--to=adam@alphapapa.net \
--cc=emacs-orgmode@gnu.org \
/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).