Re: [O] New feature? Remove duplicate subheadings, preserving order

[Adam Porter]

Allen Li <address@hidden> 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