From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: New feature? Remove duplicate subheadings, preserving order Date: Wed, 03 Jan 2018 01:24:25 -0600 Message-ID: <87fu7nv1zq.fsf@alphapapa.net> References: <87a7xxx5c5.fsf@nicolasgoaziou.fr> <87tvw5cu5t.fsf@nicolasgoaziou.fr> <87mv1wvr70.fsf@alphapapa.net> <87r2r8w73n.fsf@alphaville.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eWdPw-00030X-Jc for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 02:24:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eWdPt-0002DY-CN for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 02:24:52 -0500 Received: from [195.159.176.226] (port=39609 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eWdPt-0002CW-4s for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 02:24:49 -0500 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eWdNq-0003IV-Es for emacs-orgmode@gnu.org; Wed, 03 Jan 2018 08:22:42 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Allen Li 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