Agenda buffer and relative links

Agenda buffer and relative links

[François Pinard]

Hi again, Org people.

When Org mode defines a link for me, it sometimes changes it so it
becomes relative.  If within the file ~/fp/notes/notes.org, I wanted to
create the link:

[[file:~/fp/notes/VCS/GitHub.org][GitHub]]

Org mode really creates:

[[file:VCS/GitHub.org][GitHub]]

I presume this is because of the location of "notes.org" rather than
because of the value of org-directory, which happens to be "~/fp/notes".
This is OK in general, but not always.

For example, doing "C-a a a" today, I get this line among others
(squeezed so it fits in this message):

 notes: Scheduled: TODO *[[file:Informatique/Entretien.org][Entretien]]

and clicking on the displayed "Entretien" link yields a white window.

The problem is that the *Org Agenda* buffer is associated with the "~/"
directory, and the relativized name is then wrong.

Because all my agenda-files happen to be directly within org-directory,
a sufficient counter-measure is to have this line in my ~/.emacs file:

(add-hook 'org-agenda-mode-hook (lambda () (cd org-directory)))

While it solves my problem, I have feeling that there is something
deeper which might likely affect many Org mode users, and for which I
have no general solution to offer.  In the worst scenario, the solution
might be to never relativize links, but maybe someone would have a
better idea about this.  In any case, I decided to report it.

François

Re: Agenda buffer and relative links

[Nick Dokos]

François Pinard <pinard@iro.umontreal.ca> wrote:

> Hi again, Org people.
> 
> When Org mode defines a link for me, it sometimes changes it so it
> becomes relative.  If within the file ~/fp/notes/notes.org, I wanted to
> create the link:
> 
> [[file:~/fp/notes/VCS/GitHub.org][GitHub]]
> 
> Org mode really creates:
> 
> [[file:VCS/GitHub.org][GitHub]]
> 
> I presume this is because of the location of "notes.org" rather than
> because of the value of org-directory, which happens to be "~/fp/notes".
> This is OK in general, but not always.
> 
> For example, doing "C-a a a" today, I get this line among others
> (squeezed so it fits in this message):
> 
>  notes: Scheduled: TODO *[[file:Informatique/Entretien.org][Entretien]]
> 
> and clicking on the displayed "Entretien" link yields a white window.
> 
> The problem is that the *Org Agenda* buffer is associated with the "~/"
> directory, and the relativized name is then wrong.
> 
> Because all my agenda-files happen to be directly within org-directory,
> a sufficient counter-measure is to have this line in my ~/.emacs file:
> 
> (add-hook 'org-agenda-mode-hook (lambda () (cd org-directory)))
> 
> While it solves my problem, I have feeling that there is something
> deeper which might likely affect many Org mode users, and for which I
> have no general solution to offer.  In the worst scenario, the solution
> might be to never relativize links, but maybe someone would have a
> better idea about this.  In any case, I decided to report it.
> 
> François
> 
> 

Check

   (info "(org) Handling links")

in the manual, particularly the doc for C-u C-c C-l.

Nick

Re: Agenda buffer and relative links

[François Pinard]

Nick Dokos <nicholas.dokos@hp.com> writes:

> François Pinard <pinard@iro.umontreal.ca> wrote:

>> When Org mode defines a link for me, it sometimes changes it so it
>> becomes relative.  [...] This is OK in general, but not always.
>> [...]  I have feeling that there is something deeper which might
>> likely affect many Org mode users, and for which I have no general
>> solution to offer.

> Check
>    (info "(org) Handling links")
> in the manual, particularly the doc for C-u C-c C-l.

Hi, Nick, and gang.

Yes, I knew about prefixes to C-c C-l, which may be used to force links
to be absolute.  Systematic use of C-u C-u C-c C-l instead of C-c C-l
would be tedious, that's why I think there is a deeper problem about the
current defaults.

There is a virtue in relative links which I recognize.  So having an
option to force all links to be absolute might not be a solution.
Having all links relative just cannot work.  Letting the user properly
manage is quite error-prone, and fairly annoying at least.

If you put a gun on my head and say "suggest something", without much
time to think, I would go something that way:

* cutting part of a buffer containing links, links should be
  turned absolute before going in the clipboard or kill ring,

* pasting text containing links, links should be turned relative
  whenever it makes sense to do so.

What is "making sense", above?

* if a file receiving the link is not part of the agenda files, the
  current algorithm is OK,

* if a file receiving the link is part of the agenda files, and that
  agenda file is directly under org-directory, the current algorithm
  is OK,

* if a file receiving the link is part of the agenda files, and that
  agenda file is not directly under org-directory, make the link
  absolute,

This would have consequences:

* the agenda buffer should automatically be cd'ed to org-directory,

* adding (removing) a file to (from) the list of agenda-files becomes a
  complex operation, requiring all links to be adjusted.

All of the above is surely very debatable, and other people may likely
devise other approaches.  That's why I say it may require deeper
thought.  I would only like to stress that there is a problem.

François


P.S. I have lot of links, and I often move contents around in files.
Adjusting links while doing so has been a bit painful all along.  So
far, I used mixes of Python scripts, editionswith Vim, or sometimes
editions with Emacs in fundamental mode.  And I wrote a cross-checking
and diagnosis tool which I run at least daily, at backup time.

Re: Agenda buffer and relative links

[Sebastien Vauban]

Hi François,

François Pinard wrote:
> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>
>> François Pinard <pinard-CRDzTM1onBSWkKpYnGOUKg@public.gmane.org> wrote:
>
>>> When Org mode defines a link for me, it sometimes changes it so it
>>> becomes relative.  [...] This is OK in general, but not always.
>>> [...]  I have feeling that there is something deeper which might
>>> likely affect many Org mode users, and for which I have no general
>>> solution to offer.
>
>> Check
>>    (info "(org) Handling links")
>> in the manual, particularly the doc for C-u C-c C-l.
>
> Hi, Nick, and gang.
>
> Yes, I knew about prefixes to C-c C-l, which may be used to force links
> to be absolute.  Systematic use of C-u C-u C-c C-l instead of C-c C-l
> would be tedious, that's why I think there is a deeper problem about the
> current defaults.
>
> There is a virtue in relative links which I recognize.  So having an
> option to force all links to be absolute might not be a solution.
> Having all links relative just cannot work.  Letting the user properly
> manage is quite error-prone, and fairly annoying at least.

Would this help you?

    ┏━━━━
    ┃ org-link-file-path-type is a variable defined in `org.el'.
    ┃ Its value is adaptive
    ┃ 
    ┃ Documentation:
    ┃ How the path name in file links should be stored.
    ┃ Valid values are:
    ┃ 
    ┃ relative  Relative to the current directory, i.e. the directory of the file
    ┃           into which the link is being inserted.
    ┃ absolute  Absolute path, if possible with ~ for home directory.
    ┃ noabbrev  Absolute path, no abbreviation of home directory.
    ┃ adaptive  Use relative path for files in the current directory and sub-
    ┃           directories of it.  For other files, use an absolute path.
    ┗━━━━

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Agenda buffer and relative links

[François Pinard]

"Sebastien Vauban"
<wxhgmqzgwmuf@spammotel.com> writes:

> Hi François,

Hello, Sebastien!

> François Pinard wrote:
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>>> François Pinard <pinard@iro.umontreal.ca> wrote:

>>>> When Org mode defines a link for me, it sometimes changes it so it
>>>> becomes relative.  [...] This is OK in general, but not always.

>> There is a virtue in relative links which I recognize.  So having an
>> option to force all links to be absolute might not be a solution.

> Would this help you?

>     ┏━━━━
>     ┃ org-link-file-path-type is a variable defined in `org.el'.
>     ┗━━━━

Maybe, I might even end up using it, who knows.  It does not solve the
problem I tried to describe.  Relative links allow for moving whole
hierarchies elsewhere, so the current default Org behaviour is good.

But not good enough for the agenda buffer.  Links do not always work in
there, and this is the problem to solve.  The problem has ramifications.

François

P.S. Nice way to quote, by the way! :-)

Re: Agenda buffer and relative links

[François Pinard]

pinard@iro.umontreal.ca (François Pinard) writes:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.orgmode as well.

Hmph, I now wonder if the link is bidirectional, and if messages posted
to gmane.emacs.orgmode actually end up on emacs-orgmode@gnu.org.  I'm
repeating it all below, quoted.  (Would someone be kind enough to tell
me if it was seen on the mailing list?)

A good solution imposed itself to my mind, a few minutes ago.  I do not
know how easy to implement it would be however.

The real problem is that relative links within the agenda buffer are
interpreted relative to the directory (M-x pwd) of the agenda buffer.
Happily enough, each line of the agenda buffer is somehow associated
with the buffer it comes from.  Links within the agenda should be
interpreted relative to the base directory of the buffer they come from,
rather than from the agenda buffer itself.

François



> "Sebastien Vauban"
> <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

>> Hi François,

> Hello, Sebastien!

>> François Pinard wrote:
>>> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>>>> François Pinard <pinard-CRDzTM1onBSWkKpYnGOUKg@public.gmane.org> wrote:

>>>>> When Org mode defines a link for me, it sometimes changes it so it
>>>>> becomes relative.  [...] This is OK in general, but not always.

>>> There is a virtue in relative links which I recognize.  So having an
>>> option to force all links to be absolute might not be a solution.

>> Would this help you?

>>     ┏━━━━
>>     ┃ org-link-file-path-type is a variable defined in `org.el'.
>>     ┗━━━━

> Maybe, I might even end up using it, who knows.  It does not solve the
> problem I tried to describe.  Relative links allow for moving whole
> hierarchies elsewhere, so the current default Org behaviour is good.

> But not good enough for the agenda buffer.  Links do not always work in
> there, and this is the problem to solve.  The problem has ramifications.

> François

> P.S. Nice way to quote, by the way! :-)

Re: Agenda buffer and relative links

[Sebastien Vauban]

Hi François,

François Pinard wrote:
> pinard-CRDzTM1onBSWkKpYnGOUKg@public.gmane.org (François Pinard) writes:
>
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.emacs.orgmode as well.
>
> Hmph, I now wonder if the link is bidirectional, and if messages posted
> to gmane.emacs.orgmode actually end up on emacs-orgmode-0jIIvIziipk@public.gmane.org  I'm
> repeating it all below, quoted.  (Would someone be kind enough to tell
> me if it was seen on the mailing list?)

I saw your posting of 18:39... Reading this ML through Gmane, though.

> A good solution imposed itself to my mind, a few minutes ago.  I do not
> know how easy to implement it would be however.
>
> The real problem is that relative links within the agenda buffer are
> interpreted relative to the directory (M-x pwd) of the agenda buffer.
> Happily enough, each line of the agenda buffer is somehow associated
> with the buffer it comes from.  Links within the agenda should be
> interpreted relative to the base directory of the buffer they come from,
> rather than from the agenda buffer itself.

I must admit I'm not hit -- yet? -- by your problem, as I "never" (I should
never say that) have links in my headings. So, what I would do, is jump to the
referenced heading (using RET or SPC) and activate it from there.

BTW, just to confirm, is it the same is the link is in the very first line
under a heading, and made visible from the agenda through `E':

    ┏━━━━
    ┃ E runs the command org-agenda-entry-text-mode, which is an interactive Lisp
    ┃ function in `org-agenda.el'.
    ┃ 
    ┃ It is bound to E, <menu-bar> <Agenda> <View> <Show some entry text>.
    ┃ 
    ┃ (org-agenda-entry-text-mode &optional ARG)
    ┃ 
    ┃ Toggle entry text mode in an agenda buffer.
    ┗━━━━

>> "Sebastien Vauban"
>> <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>>> Hi François,
>
>> Hello, Sebastien!
>
>>> François Pinard wrote:
>>>> Nick Dokos <nicholas.dokos-VXdhtT5mjnY@public.gmane.org> writes:
>>>>> François Pinard <pinard-CRDzTM1onBSWkKpYnGOUKg@public.gmane.org> wrote:
>
>>>>>> When Org mode defines a link for me, it sometimes changes it so it
>>>>>> becomes relative.  [...] This is OK in general, but not always.
>
>>>> There is a virtue in relative links which I recognize.  So having an
>>>> option to force all links to be absolute might not be a solution.
>
>>> Would this help you?
>
>>>     ┏━━━━
>>>     ┃ org-link-file-path-type is a variable defined in `org.el'.
>>>     ┗━━━━
>
>> Maybe, I might even end up using it, who knows.  It does not solve the
>> problem I tried to describe.  Relative links allow for moving whole
>> hierarchies elsewhere, so the current default Org behaviour is good.
>
>> But not good enough for the agenda buffer.  Links do not always work in
>> there, and this is the problem to solve.  The problem has ramifications.
>
>> François
>
>> P.S. Nice way to quote, by the way! :-)

M-x boxquote, with custom settings.

Best regards,
  Seb

-- 
Sebastien Vauban