all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Ido org-refile results in misfiling
@ 2012-06-01  2:51 Samuel Wales
  2012-06-01 21:45 ` Darlan Cavalcante Moreira
  2013-07-17 23:31 ` Samuel Wales
  0 siblings, 2 replies; 4+ messages in thread
From: Samuel Wales @ 2012-06-01  2:51 UTC (permalink / raw)
  To: emacs-orgmode

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/".  This is 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".  Also 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.  A nice feature.)

  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 that the reason for the unexpected behavior is related (in
some way) to
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 /happened/ to match 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.

===

Is there any way to fix this?  I tried looking at ido
customizations and got lost.

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

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ido org-refile results in misfiling
  2012-06-01  2:51 Ido org-refile results in misfiling Samuel Wales
@ 2012-06-01 21:45 ` Darlan Cavalcante Moreira
  2012-06-01 22:13   ` Samuel Wales
  2013-07-17 23:31 ` Samuel Wales
  1 sibling, 1 reply; 4+ messages in thread
From: Darlan Cavalcante Moreira @ 2012-06-01 21:45 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode


One thing that may help is using "C-space" to lock previous matches with
ido completion.

For instance, you start ido completion (does not matter in which context:
buffers, files, functions, etc) and start typing This will give you a bunch
of matches. Then use C-space to "lock these matches" and it is like
starting ido completion again but limited to whatever matched the previous
typing. Using this method when you have many matches is usually much easier
then trying to find what you want in a single pass.

--
Darlan

At Thu, 31 May 2012 19:51:36 -0700,
Samuel Wales <samologist@gmail.com> wrote:
> 
> 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/".  This is 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".  Also 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.  A nice feature.)
> 
>   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 that the reason for the unexpected behavior is related (in
> some way) to
> 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 /happened/ to match 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.
> 
> ===
> 
> Is there any way to fix this?  I tried looking at ido
> customizations and got lost.
> 
> If you can't reproduce witn your ido settings, I'll try to
> provide an MCE at some point.  Might take a while though.
> 
> Thanks.
> 
> Samuel
> 
> -- 
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ido org-refile results in misfiling
  2012-06-01 21:45 ` Darlan Cavalcante Moreira
@ 2012-06-01 22:13   ` Samuel Wales
  0 siblings, 0 replies; 4+ messages in thread
From: Samuel Wales @ 2012-06-01 22:13 UTC (permalink / raw)
  To: Darlan Cavalcante Moreira; +Cc: emacs-orgmode

Hi Darian,

I use the technique you describe all the time for other purposes, and
I agree it is wonderful.

However, that solves almost exactly the *opposite* problem.  :)  In
this case, it would lock in a default selection that is already locked
in.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Ido org-refile results in misfiling
  2012-06-01  2:51 Ido org-refile results in misfiling Samuel Wales
  2012-06-01 21:45 ` Darlan Cavalcante Moreira
@ 2013-07-17 23:31 ` Samuel Wales
  1 sibling, 0 replies; 4+ messages in thread
From: Samuel Wales @ 2013-07-17 23:31 UTC (permalink / raw)
  To: emacs-orgmode

I'd like to bump this bug as I have a minimal test case for it now.

Save the whole thing to one file, and the subtree labeled "test case"
to another file.

*** bad refile example 1                                             :refile:
***** save test case to a file, and make it accessible to ido refiling
with flex matching
***** don't save these instructions to the file because they will interfere :)
***** refile this entry to the entry labeled 3 by typing 3
***** now try to refile this entry to the entry labeled 2 by typing 2
***** notice how the default provided is 3.  this is the bug.
it is of course ok that the default is 3 /before/ you
type 2.  that is not a bug.

the bug is that the default is 3 /after/ you type 2.
***** test case
******* i want this 2                                                :refile:
********* i get this 3                                               :refile:

The bug is explained in more detail below.

Thanks.

Samuel

On 5/31/12, Samuel Wales <samologist@gmail.com> wrote:
> 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/".  This is 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".  Also 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.  A nice feature.)
>
>   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 that the reason for the unexpected behavior is related (in
> some way) to
> 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 /happened/ to match 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.
>
> ===
>
> Is there any way to fix this?  I tried looking at ido
> customizations and got lost.
>
> If you can't reproduce witn your ido settings, I'll try to
> provide an MCE at some point.  Might take a while though.
>
> Thanks.
>
> Samuel
>
> --
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Denmark: free Karina Hansen NOW.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-07-17 23:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-01  2:51 Ido org-refile results in misfiling Samuel Wales
2012-06-01 21:45 ` Darlan Cavalcante Moreira
2012-06-01 22:13   ` Samuel Wales
2013-07-17 23:31 ` Samuel Wales

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.