emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Allen Li <vianchielfaura@gmail.com>
To: Nick Dokos <ndokos@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: New feature? Remove duplicate subheadings, preserving order
Date: Tue, 2 Jan 2018 13:22:23 -0800	[thread overview]
Message-ID: <CAJr1M6cVrzZ59Vw9Wc-dNsLZbCXB6OE1j7FpgZ5AR1xENBv6aQ@mail.gmail.com> (raw)
In-Reply-To: <87r2r8w73n.fsf@alphaville.usersys.redhat.com>

On Tue, Jan 2, 2018 at 8:36 AM, Nick Dokos <ndokos@gmail.com> wrote:
> Allen Li <vianchielfaura@gmail.com> writes:
>>
>> There is always undo and automatic Emacs file backups.
>>
>
> There be dragons.
>
> The problem is that some things happen invisibly and far away from
> where you are, so you don't know about it and you don't find out for a
> couple of weeks.  Undo and automatic backups are useless in that case.
>
> That *has* happened: there have been multiple postings in the ML about
> such problems. Whenever it has happened, the devs have always modified
> org to make it safer: that is the prudent thing to do and the correct
> course of action IMO.
>
> Hell hath no fury like an orgmode user who lost part of his/her
> precious org file because of an errant keystroke a month ago and was
> not aware of the loss until it was too late.

I can see where you're coming from, but for me there are various reasons
why I don’t think warning is right:

1. org-sort-entries, which performs an action of similar scope and
   destructiveness, does not need to warn so far.

2. Since I see the only use case for warning is checking beforehand, a
   user that uses this command frequently is not going to type C-c d C-u
   C-c d every time (assuming the user has bound this command to C-c d),
   they’re just going to type C-u C-c d or get frustrated and just bind
   the actual command without warning to C-c d.  So warning provides
   zero safety in practice.

   Another possibility is using a y or n confirmation prompt before
   removing duplicates, however this falls into the same trap that a
   user who uses this frequently is just going to bind the command to a
   key and disable this check.

3. I don’t propose binding this command to any key by default, and I
   don’t think M-x org-remove-duplicates RET is a very common typo.

4. The only commands in Emacs that warn beforehand are truly
   irreversible commands, like deleting in Dired or killing a buffer.
   Everything else in Emacs follows the philosophy of using undo if the
   user makes a mistake, including lots of commands that could have
   unintentional, low visibility effects.  I would prefer following this
   policy unless it proves to actually be a problem.  It seems like
   org-sort-entries in practice has not suffered from this problem, so I
   believe a remove duplicates command will similarly not suffer from
   this problem in practice.

5. Everyone should be keeping reliable backups.  This is reiterated all
   the time, yet no one seems to follow it? =)

>
> --
> Nick
>
>

  reply	other threads:[~2018-01-02 21:22 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 [this message]
2018-01-03  7:24                 ` Adam Porter
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=CAJr1M6cVrzZ59Vw9Wc-dNsLZbCXB6OE1j7FpgZ5AR1xENBv6aQ@mail.gmail.com \
    --to=vianchielfaura@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ndokos@gmail.com \
    /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).