Gnorb and org-refile-use-outline-path

Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Hi,

would it make sense to provide an Gnorb version of the
org-refile-use-outline-path option (with a non-nil default value)?

I find the current dialog to which heading to associate an article
confusing because it doesn't show me the full paths.  I thought things
are broken until I studied the code and found
org-refile-use-outline-path.  Maybe Org fans are not suprised, I dunno.


Thanks,

Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Hi,
>
> would it make sense to provide an Gnorb version of the
> org-refile-use-outline-path option (with a non-nil default value)?
>
> I find the current dialog to which heading to associate an article
> confusing because it doesn't show me the full paths.  I thought things
> are broken until I studied the code and found
> org-refile-use-outline-path.  Maybe Org fans are not suprised, I dunno.

Oh, inside `gnorb-gnus-outgoing-do-todo'? Sure, I'd be happy to add
that. You think t would be a reasonable default? I'd never noticed since
my org-refile seems to have been taken over by helm.

Eric

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> > would it make sense to provide an Gnorb version of the
> > org-refile-use-outline-path option (with a non-nil default value)?
> >
> > I find the current dialog to which heading to associate an article
> > confusing because it doesn't show me the full paths.  I thought things
> > are broken until I studied the code and found
> > org-refile-use-outline-path.  Maybe Org fans are not suprised, I dunno.
>
> Oh, inside `gnorb-gnus-outgoing-do-todo'?

I wanted it for `gnorb-gnus-incoming-do-todo', but yes.

> Sure, I'd be happy to add that. You think t would be a reasonable
> default? I'd never noticed since my org-refile seems to have been
> taken over by helm.

Helm is the better interface here, the vanilla completion doesn't show
all candidates unless you enter parts of the path.

Anyway, the only difference between org-refile-use-outline-path -> t and
org-refile-use-outline-path -> 'file seems to be that t uses paths of
the format

  x/y/z/ (todo.org)

while 'file uses

  todo.org/x/y/z/

'file behaves much better IMHO: it feels more logical, while t also has
some issues, for example in one case I got something illegal like

  x/y/z/ (todo.org) (todo.org)

Also when hitting tab, often the cursor lands after (todo.org), and you
have to move it after /z/ to add something to the path.

So I would suggest 'file as default, but note I only tried a couple of
times.  Dunno if this setting influences how Helm behaves - it would
hopefully just ignore it.


Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> > would it make sense to provide an Gnorb version of the
>> > org-refile-use-outline-path option (with a non-nil default value)?
>> >
>> > I find the current dialog to which heading to associate an article
>> > confusing because it doesn't show me the full paths.  I thought things
>> > are broken until I studied the code and found
>> > org-refile-use-outline-path.  Maybe Org fans are not suprised, I dunno.
>>
>> Oh, inside `gnorb-gnus-outgoing-do-todo'?
>
> I wanted it for `gnorb-gnus-incoming-do-todo', but yes.

I'll wrap it around everywhere that Gnorb uses the refile interface.

>> Sure, I'd be happy to add that. You think t would be a reasonable
>> default? I'd never noticed since my org-refile seems to have been
>> taken over by helm.
>
> Helm is the better interface here, the vanilla completion doesn't show
> all candidates unless you enter parts of the path.
>
> Anyway, the only difference between org-refile-use-outline-path -> t and
> org-refile-use-outline-path -> 'file seems to be that t uses paths of
> the format
>
>   x/y/z/ (todo.org)
>
> while 'file uses
>
>   todo.org/x/y/z/
>
> 'file behaves much better IMHO: it feels more logical, while t also has
> some issues, for example in one case I got something illegal like
>
>   x/y/z/ (todo.org) (todo.org)
>
> Also when hitting tab, often the cursor lands after (todo.org), and you
> have to move it after /z/ to add something to the path.
>
> So I would suggest 'file as default, but note I only tried a couple of
> times.  Dunno if this setting influences how Helm behaves - it would
> hopefully just ignore it.

I fooled with it, and it looks like Helm ignores the value of
org-refile-use-outline-path. I'm running a patch version that sets
gnorb-gnus-refile-use-outline-path to the value of
org-refile-use-outline-path, which I expect will be the best way to not
surprise users.

Eric

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I fooled with it, and it looks like Helm ignores the value of
> org-refile-use-outline-path. I'm running a patch version that sets
> gnorb-gnus-refile-use-outline-path to the value of
> org-refile-use-outline-path, which I expect will be the best way to not
> surprise users.

Hmm, the default value of `org-refile-use-outline-path' is in my
experience not really usable with Gnorb.  Maybe the default of
gnorb-gnus-refile-use-outline-path would better be

  (or org-refile-use-outline-path 'file)

?

I hate to change such defaults, too, but what I got when I tried to
associate a message with Gnorb looked not only surprising but broken.
It gets even problematic if you have different equal headlines in
different positions, then it's not possible to select one of them AFAICT
(you get only one completion candidate with that name).  I didn't try
what happens if multiple files get into play.  I guess it gets even
worse.

What I'm probably actually saying is that org-refile-use-outline-path ->
nil gives you a confusing behavior, no matter if using Org or Gnorb.


Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I fooled with it, and it looks like Helm ignores the value of
>> org-refile-use-outline-path. I'm running a patch version that sets
>> gnorb-gnus-refile-use-outline-path to the value of
>> org-refile-use-outline-path, which I expect will be the best way to not
>> surprise users.
>
> Hmm, the default value of `org-refile-use-outline-path' is in my
> experience not really usable with Gnorb.  Maybe the default of
> gnorb-gnus-refile-use-outline-path would better be
>
>   (or org-refile-use-outline-path 'file)
>
> ?
>
> I hate to change such defaults, too, but what I got when I tried to
> associate a message with Gnorb looked not only surprising but broken.
> It gets even problematic if you have different equal headlines in
> different positions, then it's not possible to select one of them AFAICT
> (you get only one completion candidate with that name).  I didn't try
> what happens if multiple files get into play.  I guess it gets even
> worse.
>
> What I'm probably actually saying is that org-refile-use-outline-path ->
> nil gives you a confusing behavior, no matter if using Org or Gnorb.

I was sort of thinking that if the Gnorb option were set to the value
of the Org option, then users would just end up with the same behavior
in Gnorb that they'd customized in Org. Sometimes I get confused about
the order of evaluation of custom options, though -- maybe they would
get the pre-customization, default Org value?

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I was sort of thinking that if the Gnorb option were set to the value
> of the Org option, then users would just end up with the same behavior
> in Gnorb that they'd customized in Org. Sometimes I get confused about
> the order of evaluation of custom options, though -- maybe they would
> get the pre-customization, default Org value?

Yes, the result would simply depend on whether they set the Org option
before loading Gnorb.  There is no good solution to that problem I
guess.  You could make it so that the default value of the Gnorb option
would make Gnorb check the value of the Org option dynamically at run
time.  If it is non-nil, we would use that value, if it is nil, we could
use 'file instead.


Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I was sort of thinking that if the Gnorb option were set to the value
>> of the Org option, then users would just end up with the same behavior
>> in Gnorb that they'd customized in Org. Sometimes I get confused about
>> the order of evaluation of custom options, though -- maybe they would
>> get the pre-customization, default Org value?
>
> Yes, the result would simply depend on whether they set the Org option
> before loading Gnorb.  There is no good solution to that problem I
> guess.  You could make it so that the default value of the Gnorb option
> would make Gnorb check the value of the Org option dynamically at run
> time.  If it is non-nil, we would use that value, if it is nil, we could
> use 'file instead.

So like this?

(eval-after-load 'org
  (unless gnorb-gnus-refile-use-outline-path
    (setq gnorb-gnus-refile-use-outline-path
	  org-refile-use-outline-path)))

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> I was sort of thinking that if the Gnorb option were set to the value
>>> of the Org option, then users would just end up with the same behavior
>>> in Gnorb that they'd customized in Org. Sometimes I get confused about
>>> the order of evaluation of custom options, though -- maybe they would
>>> get the pre-customization, default Org value?
>>
>> Yes, the result would simply depend on whether they set the Org option
>> before loading Gnorb.  There is no good solution to that problem I
>> guess.  You could make it so that the default value of the Gnorb option
>> would make Gnorb check the value of the Org option dynamically at run
>> time.  If it is non-nil, we would use that value, if it is nil, we could
>> use 'file instead.
>
> So like this?
>
> (eval-after-load 'org
>   (unless gnorb-gnus-refile-use-outline-path
>     (setq gnorb-gnus-refile-use-outline-path
> 	  org-refile-use-outline-path)))

Quoted, of course....

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> > So like this?
> >
> > (eval-after-load 'org
> >   (unless gnorb-gnus-refile-use-outline-path
> >     (setq gnorb-gnus-refile-use-outline-path
> > 	  org-refile-use-outline-path)))
>
> Quoted, of course....

(or just `with-eval-after-load'?).

You can do that, but of course only if
gnorb-gnus-refile-use-outline-path -> nil is not a significant value.
Which, I guess, is in your case.  There should still be a way for the
user to set gnorb-gnus-refile-use-outline-path nil while having
org-refile-use-outline-path non-nil.

What I often do in my code instead is: I make such options have an extra
dedicated value, say 'use-org-value-maybe, to mean, in this case, use
the org value or 'file, for example And in the code, whenever the
variable is referenced, I would use

(let ((org-refile-use-outline-path
       (if (eq gnorb-gnus-refile-use-outline-path 'use-org-value-maybe)
           (or org-refile-use-outline-path 'file)
         gnorb-gnus-refile-use-outline-path)))
  code...)

That's cleaner than silently changing values of options which can lead
to confusion.  You would want to make that dedicated value the default,
obviously.


Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> > So like this?
>> >
>> > (eval-after-load 'org
>> >   (unless gnorb-gnus-refile-use-outline-path
>> >     (setq gnorb-gnus-refile-use-outline-path
>> > 	  org-refile-use-outline-path)))
>>
>> Quoted, of course....
>
> (or just `with-eval-after-load'?).
>
> You can do that, but of course only if
> gnorb-gnus-refile-use-outline-path -> nil is not a significant value.
> Which, I guess, is in your case.  There should still be a way for the
> user to set gnorb-gnus-refile-use-outline-path nil while having
> org-refile-use-outline-path non-nil.
>
> What I often do in my code instead is: I make such options have an extra
> dedicated value, say 'use-org-value-maybe, to mean, in this case, use
> the org value or 'file, for example And in the code, whenever the
> variable is referenced, I would use
>
> (let ((org-refile-use-outline-path
>        (if (eq gnorb-gnus-refile-use-outline-path 'use-org-value-maybe)
>            (or org-refile-use-outline-path 'file)
>          gnorb-gnus-refile-use-outline-path)))
>   code...)
>
> That's cleaner than silently changing values of options which can lead
> to confusion.  You would want to make that dedicated value the default,
> obviously.

Huh. That looks like a lot of work, but maybe you're right it's the only
way to have complete control. I might raise this on emacs.devel and see
what they think.

Thanks,
Eric

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> > (let ((org-refile-use-outline-path
> >        (if (eq gnorb-gnus-refile-use-outline-path 'use-org-value-maybe)
> >            (or org-refile-use-outline-path 'file)
> >          gnorb-gnus-refile-use-outline-path)))
> >   code...)
> >

> Huh. That looks like a lot of work

Not really.  What is really nontrivial work is to find out all places
where you need to bind `org-refile-use-outline-path'.

Then factor the

(if (eq gnorb-gnus-refile-use-outline-path 'use-org-value-maybe)
    (or org-refile-use-outline-path 'file)
  gnorb-gnus-refile-use-outline-path)

part into a defun `gnorb-get-gnus-refile-use-outline-path', and all you
have to do is to bind `org-refile-use-outline-path' to
(gnorb-get-gnus-refile-use-outline-path) instead of
gnorb-gnus-refile-use-outline-path in all those places.

If you had to treat several variables this way, it would be better to
define a macro `gnorb-with-org-bindings' that expands into a `let'.  But
that's still a small and trivial change.


Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> > (let ((org-refile-use-outline-path
>> >        (if (eq gnorb-gnus-refile-use-outline-path 'use-org-value-maybe)
>> >            (or org-refile-use-outline-path 'file)
>> >          gnorb-gnus-refile-use-outline-path)))
>> >   code...)
>> >
>
>> Huh. That looks like a lot of work
>
> Not really.  What is really nontrivial work is to find out all places
> where you need to bind `org-refile-use-outline-path'.

Well that's not too hard, there are only four spots, I think.

> Then factor the
>
> (if (eq gnorb-gnus-refile-use-outline-path 'use-org-value-maybe)
>     (or org-refile-use-outline-path 'file)
>   gnorb-gnus-refile-use-outline-path)

> part into a defun `gnorb-get-gnus-refile-use-outline-path', and all you
> have to do is to bind `org-refile-use-outline-path' to
> (gnorb-get-gnus-refile-use-outline-path) instead of
> gnorb-gnus-refile-use-outline-path in all those places.

This should work fine, right?

#+begin_src elisp
(let ((org-refile-use-outline-path
       (if (eq gnorb-gnus-refile-use-outline-path 'org)
	   org-refile-use-outline-path
	 gnorb-gnus-refile-use-outline-path)))
  ...)
#+end_src

Then default the gnorb option to 'org.

> If you had to treat several variables this way, it would be better to
> define a macro `gnorb-with-org-bindings' that expands into a `let'.  But
> that's still a small and trivial change.

Yup, I'll leave that for later.

Thanks,
Eric

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> This should work fine, right?
>
> #+begin_src elisp
> (let ((org-refile-use-outline-path
>        (if (eq gnorb-gnus-refile-use-outline-path 'org)
> 	   org-refile-use-outline-path
> 	 gnorb-gnus-refile-use-outline-path)))
>   ...)
> #+end_src
>
> Then default the gnorb option to 'org.

Sure.

I only wonder if defaulting to the org behavior is good, since the
default of `org-refile-use-outline-path' is not a good default for Gnorb
IMHO.  My initial suggestion was to use the new gnorb option to provide
a better default for Gnorb.  Just one opinion, of course.


Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> This should work fine, right?
>>
>> #+begin_src elisp
>> (let ((org-refile-use-outline-path
>>        (if (eq gnorb-gnus-refile-use-outline-path 'org)
>> 	   org-refile-use-outline-path
>> 	 gnorb-gnus-refile-use-outline-path)))
>>   ...)
>> #+end_src
>>
>> Then default the gnorb option to 'org.
>
> Sure.
>
> I only wonder if defaulting to the org behavior is good, since the
> default of `org-refile-use-outline-path' is not a good default for Gnorb
> IMHO.  My initial suggestion was to use the new gnorb option to provide
> a better default for Gnorb.  Just one opinion, of course.

Oh, I see. But... I think it would be less surprising to just have Gnorb
behave the same way Org does. You never know what people think about
the defaults, and it seems likely that users who are annoyed by Org's
default behavior would have already changed it.

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Oh, I see. But... I think it would be less surprising to just have Gnorb
> behave the same way Org does. You never know what people think about
> the defaults, and it seems likely that users who are annoyed by Org's
> default behavior would have already changed it.

I can't estimate.  However, I would expect that there are also some
Gnorb users that don't use Org that much (or at all) to know about
org-refile-use-outline-path.  If you think that most people using Gnorb
also know Org and that option, is it really a win to provide an extra
Gnorb option at all?  I guess most people would at least want the same
behavior for both Org and Gnorb.

So, while I'm a bit Org agnostic, in my opinion the best thing to do
would be to change the default of the Org option.

Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Oh, I see. But... I think it would be less surprising to just have Gnorb
>> behave the same way Org does. You never know what people think about
>> the defaults, and it seems likely that users who are annoyed by Org's
>> default behavior would have already changed it.
>
> I can't estimate.  However, I would expect that there are also some
> Gnorb users that don't use Org that much (or at all) to know about
> org-refile-use-outline-path.  If you think that most people using Gnorb
> also know Org and that option, is it really a win to provide an extra
> Gnorb option at all?  I guess most people would at least want the same
> behavior for both Org and Gnorb.

Gnorb is almost completely useless without Org, so yes, I'm assuming
that Gnorb users would have already run into this issue and, if it
annoyed them, changed the Org default. I guess now that I think about
it, you're probably right that this just isn't a very useful option to
have in Gnorb. The Gnorb version of refile targets I still think is
useful, because users might want to confine their Gnorb activity to a
smaller range of Org files/headings. But I wouldn't want to provide this
option just because users might be annoyed by the Org defaults. I'll
think about this a bit, but might revert the addition.

> So, while I'm a bit Org agnostic, in my opinion the best thing to do
> would be to change the default of the Org option.

I think that's the right solution, and it's worth bringing up on the Org list!

Re: Gnorb and org-refile-use-outline-path

[Michael Heerdegen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I think that's the right solution, and it's worth bringing up on the
> Org list!

Does that mean that you want to do that?  I'm not using that list.  But
maybe you can CC me?

Thanks,

Michael.

Re: Gnorb and org-refile-use-outline-path

[Eric Abrahamsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I think that's the right solution, and it's worth bringing up on the
>> Org list!
>
> Does that mean that you want to do that?  I'm not using that list.  But
> maybe you can CC me?

Sure, I can do that.