From: Allen Li <vianchielfaura@gmail.com>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: New feature? Remove duplicate subheadings, preserving order
Date: Mon, 1 Jan 2018 23:40:12 -0800 [thread overview]
Message-ID: <CAJr1M6dpbWzqMViNQBZ5O6F2Ht66HR_FTZE8KZ8dC8LiMsquGg@mail.gmail.com> (raw)
In-Reply-To: <87mv1wvr70.fsf@alphapapa.net>
On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter <adam@alphapapa.net> wrote:
> Allen Li <vianchielfaura@gmail.com> writes:
>
>> I don’t know if a more intelligent way of handling tags and todo
>> keywords is worth the extra complexity, but in the use case that I
>> imagine it makes sense to match using only the heading/list item:
>>
>> * Things to buy
>> ** TODO cabbage
>> ** DONE milk :store1:
>> Maybe I forgot a tag here. Oh well, I already bought the milk.
>> ** TODO carrots
>> ** TODO milk :store1:store2:
>>
>> ...
>>
>> It doesn’t make sense to include the contents because I see this as
>> primarily being useful for list items. In particular, we would want
>> to ignore log entries and properties for the sake of matching
>> (intelligent property or logbook merging might be useful, but adds
>> complexity).
>
> I think such a command should check all heading data by default,
> because that's the safest option. A user who commonly needs to ignore
> one or more types of data could use a custom function that calls the
> command with arguments to disable checking of certain types.
I don’t see a use case for checking all heading data.
>> Since the point would be remove duplicates from lists, I don’t think
>> warning is very useful. I would want to remove the duplicate list
>> items, not get a warning about it and delete them manually. Perhaps
>> that would be a useful additional feature however (like uniq -d).
>
> I think warning or asking for confirmation should be the default action,
> because it's the safest option. Users who want to skip that could use a
> prefix argument or call it from a custom command.
There is always undo and automatic Emacs file backups.
>> I don’t think doing a full text check is useful, but if someone has a
>> use case for that, please speak up.
>
> An example where this would be useful is if the user has copied and
> pasted subtrees and accidentally pasted one more than once.
In that case, the user should use undo instead of a remove duplicates
command.
> I argue here for the safest behavior by default because I've found that,
> in very large Org buffers, it's easy to lose my place in the file, and
> it's easy to accidentally do something that I didn't mean to, without
> noticing. IMO this is simply a consequence of Org buffers still being
> plain-text.
I don’t agree with this philosophy. Org and Emacs already has lots of
commands that can cause damage, for example org-sort-entries which my
remove duplicates command is modeled after (both modify the direct children
under the heading at point irreversibly ignoring undo). If this command should
warn, then org-sort-entries should also warn. If org-sort-entries does not need
to warn, then this command does not need to warn.
Emacs makes backups by default and supports undo, which under my
philosophy is good enough; we shouldn’t be constantly asking for
confirmation to prevent user error. That just causes pop-up dialog fatigue.
For example, everyone clicks OK on pop-up confirmation boxes without
reading them.
These kinds of confirmation prompts are worse than useless; they slow
down and annoy the user without providing any protection. Undo is the
better solution.
> So it is quite conceivable to me that a user might intentionally give
> two headings the same name (e.g. a user who captures quotations to an
> inbox file might have two "Quote" headings that are completely
> different), or might accidentally duplicate a subtree and then make a
> desired change to one of them without realizing there was a
> duplicate--then he might use this deduplication command and accidentally
> delete a subtree he didn't mean to, resulting in data loss.
I think it would be more useful for list members to post actual use
cases than hypothesize about what people want.
For me, the use case is filtering out duplicates from a list,
e.g. groceries to buy or links to read captured with timestamps and
other metadata, so checking the tags, todo, or body text is not useful,
warning is not useful.
Based on the responses I have gotten, it sounds like this feature is
too specialized to be worth including in Org mode, so I will stop
pursuing this unless people post actual use cases/desire for
the feature.
next prev parent reply other threads:[~2018-01-02 7:40 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 [this message]
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
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=CAJr1M6dpbWzqMViNQBZ5O6F2Ht66HR_FTZE8KZ8dC8LiMsquGg@mail.gmail.com \
--to=vianchielfaura@gmail.com \
--cc=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).