emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Gustavo Barros <gusbrs.2016@gmail.com>
Subject: Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Date: Sun, 16 Feb 2020 17:06:44 -0700	[thread overview]
Message-ID: <CAJcAo8t_cuEm-YtvuZ5LznTuJdakgSUcrGjebL6FumaGErCRuQ@mail.gmail.com> (raw)
In-Reply-To: <87blq1trjo.fsf@bzg.fr>

On 2/14/20, Bastien <bzg@gnu.org> wrote:
> What was the problem when refiling with ido?

idk if the following will be useful but here goes.

bear in mind this was a while back.  this is partly from memory.

i don't know if the fix fixed all of them, but it definitely seemed
to, at least with my ido settings.

i tried ido settings.  but i recall thinking none of them worked.  it
took years to fix it.  my computer use is limited.

- the default was screwed up (more below) causing misfiling
- there was distracting, inconsistent (sometimes appearing and
sometimes not), and possibly redundant (i.e. extra olpaths in list)
information in parentheses
- similar, except with trailing slashes (this one might have had
redundancy and inconsistency properties, the latter perhaps caused by
the former, as in: you don't know which version of the olpath you will
get in the default)

the mechanism seemed to be designed for fs paths, not olpaths.  fs
paths have a directory/nondirectory distinction, and this might have
been related.  that distinction is bad for olpaths.

i do not deal with files when refiling.  even if i did, there would
still be no need for olpath directories for ido/ivy refiling.

my olpaths when refiling are bare header lines.

i think some but not all, olpaths got trailing slashes appended.

i realize that's all vague.

however, the fix made refiling change from dangerous and iffy and
annoying to safer, more reliable, and fast (ido-clever-paths and
ido-hacks also helped).

i will not be able to retrace the problem less vaguely.


as for the issues with the default, i reported at least one to the
mailing list in some detail.  it provides repro instructions.

i suspect trailing slash also caused a default problem.

please note that i am using an old version of maint because i can't
fix a capture bug that was introduced a while back.  it has perhaps
been fixed since then, dunno.


here is the report, for what it is worth:

vvv
ido and org-refile are a superb combination that enhances
Org significantly.  It is a killer feature IMO.

However, in my usage there is a substantial risk of
misfiling:

  1) If I start from a fresh Emacs, "myorg" is sufficient to
     select "computer/emacs/org/myorg/".  Good.

  2) If I refile something to
     "computer/emacs/org/myorg/strategy and examples/various
     todo kw and maybe some tags/", "various" is enough to
     select it.  Note that this is below "myorg".  Good.

  3) (Just as an aside, if I then refile something else to
     the same entry, I don't even need to enter "various".
     It is the default.  Good.)

  4) Now suppose I want to refile something to "myorg".  I
     enter "myorg" but I get "various".

Detail on this subtle issue is below:


My expectation is that if "myorg" selects "myorg" once, it
should always do so no matter what my refile history is.
This expectation is violated.

It violates a sort of referential transparency.  The same
narrowing inputs should produce the same narrowed outputs
(in my expectation at least).


I suspect the reason for the behavior is the defaulting in
3, which is useful.  However, the false defaulting in 4 is
not useful in any obvious way.


Proposed solution:

I think that as soon as the user starts selecting something,
the default should be discarded.


With my expectation, it is never necessary to check the
offered olpaths except as a confirmation.

With the current behavior, checking is always necessary
because in edge cases, there will be a guaranteed misfile.

Here is why: the only reason that default showed up at all
is that the narrowing input matched both
headlines.  Otherwise the default would have been discarded.

So it is an edge case that allowed the offer to misfile.  In
other cases, the correct default would be provided.  If I
wanted "various", RET would be sufficient.

User checking is significantly more error-prone because one
olpath is a substring of the other.

Likewise, the requirement to navigate in the list is
burdensome as 4 is never useful as far as I can tell.


I tried looking at ido
variables and got lost.

If you can't reproduce witn your ido settings, I'll try to
provide an MCE at some point.

Thanks.

Samuel
^^^

-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

  reply	other threads:[~2020-02-17  0:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 18:34 Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)] Gustavo Barros
2020-02-12 23:35 ` Bastien
2020-02-13  1:51   ` Gustavo Barros
2020-02-13  7:45     ` Bastien
2020-02-13 19:44       ` Samuel Wales
2020-02-14 10:02         ` Bastien
2020-02-17  0:06           ` Samuel Wales [this message]
2020-02-17  0:14             ` Bastien
2020-02-17  0:17               ` Samuel Wales
2020-02-17  0:25                 ` Samuel Wales
2020-02-17  0:38                   ` Bastien
2020-02-17  1:58                     ` Samuel Wales
2020-02-17 22:55                       ` Bastien
2020-02-17  0:15             ` Samuel Wales
2020-02-13 22:53       ` Gustavo Barros
2020-02-13 23:13         ` Samuel Wales
2020-02-14 10:02         ` Bastien
2020-02-14 13:41           ` Gustavo Barros
2020-02-14 15:29             ` Bastien
2020-02-14 16:37               ` Gustavo Barros
2020-02-14 15:33           ` Gustavo Barros
2020-02-16 23:22             ` Bastien
2020-02-17  0:45               ` Gustavo Barros
2020-02-17 17:45                 ` Bastien
2020-02-13  2:06   ` Gustavo Barros
2020-02-13  7:19     ` Bastien
2020-02-13 20:51       ` Gustavo Barros

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=CAJcAo8t_cuEm-YtvuZ5LznTuJdakgSUcrGjebL6FumaGErCRuQ@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=gusbrs.2016@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).