Make file:xxx relative to notebook and file:/xxx relative to card

[memeplex]

Please, for local repositories this is very important since it allows to keep a consistent structure both in your computer and in orgzly. I think file:/xxx should be relative to your sdcard but file:xxx should be relative to your repo. I can't figure out why this isn't like that.

[memeplex]

Implementing this feature will mostly solve the problem of notebooks nested in a hierarchy as discussed in #485.

I believe this feature is low cost and pays too much: by simply differentiating between file:/xxx and file:xxx you get:

1. Consistency between the links in your computer and the links in orgzly.

2. Consistency between the tree structure in your computer and the flattened structure in orgzly.

3. Ability to access arbitrary notebooks in the hierarchy.

It's true that this still requires to manually create index files to access the content buried in the hierarchy, but it still is a far cry from not being able to access this content at all!!!

[memeplex]

I changed my mind regarding file:xxx. Despite the fact that currently "relative to repo" and "relative to file" mean the same thing, since orgzly just sees a list of files under the repo path, room should be made in advance for behavior more closely aligned with org mode, because hopefully one day file:proj1/notes.org would be accessible and then relative file links in proj1/notes.org would have to be accessed relative to proj1 as in org mode. So I propose this behavior:

• file:/xxx relative to sdcard
• file:xxx relative to notebook, which currently is equivalent to relative to repo

[nevenz]

file:/xxx relative to sdcard

There could be multiple "external" storages. For example the main emulated one, but also removable SD card at the same time. These all currently work (after 1a63a68):

file:file-on-main-storage.txt
file:/sdcard/file-on-main-storage.txt
file:/storage/emulated/0/file-on-main-storage.txt

file:/storage/0F18-3901/file-on-sd-card.txt

I think an option is needed to map / to whatever user wants it to be. Maybe the same with relative paths - some users might want file:xxx to be relative to SD card, not the repository (which might not even exist, or is remote).

[Ypot]

Where would fit this syntax?
[[file-on-main-storage.txt]]

[nevenz]

[[file-on-main-storage.txt]]

This is the same as file:file-on-main-storage.txt

[vit1-irk]

It is necessary to allow to custom-map ~ (home directory) for compatibility with desktop Emacs, not only /

But I suggested it in the another issue

[codygman]

I have recordings in an apps directory on my phone. I share those with my computer with syncthing. If I could custom map ~ I would be able to map it to something like /directory/i/have/perms-to-symlink and then emulate my computer hierarchy there like:

+ /directory/i/have/perms-to-symlink
- voice-recordings -> /path/to-android-apps/recording-file-directory
- pictures -> /DCIM/path-to-camera-pictures

[valff]

So, does anyone know how to write file links for using with both Emacs and Orgzly?

[Ypot]

Hi, was this solved? I am trying to see the same images, in the same notes (path and images duplicated) in emacs and orgzly and I can't. It seems this could be called almost a bug.

[vit1-irk]

@Ypot it is still not

workaround for notes dir: when creating note, type 2 different links, 1 for Emacs, 1 for Orgzly

for example:

[[sync-dir/picture.jpg]]
[[./picture.jpg]]

Orgzly shows you the first link image (located in /sdcard/sync-dir) while the Emacs uses relative path and shows you the second link image (located just here). Not pretty enough, but works with Syncthing

[Ypot]

@vit1-irk could it be definitively solved using org-attach feature?
#1

[vit1-irk]

@vit1-irk could it be definitively solved using org-attach feature?
#1

@Ypot IDK, but it needs some hacks both for Orgzly and for Emacs to work properly
See this: https://emacs.stackexchange.com/questions/18404/can-i-display-org-mode-attachments-as-inline-images-in-my-document

[Asalle]

I think this works, at least for files
file:/sync-dir/picture.txt - looks in /
file:picture.txt - looks in current directory

The things that doesn't work for me is links to heading inside the file, like file:my-notebook.org::*Heading1

[nickdex]

See this: https://emacs.stackexchange.com/questions/18404/can-i-display-org-mode-attachments-as-inline-images-in-my-document

From SO answer, got this link to manual on attachments.
Can we replicate this functionality?

[daraul]

The things that doesn't work for me is links to heading inside the file, like file:my-notebook.org::*Heading1

I would love to see this work like it does on desktop.

[jluttine]

One possible workaround: Use a path that works in Orgzly: file:./Orgzly-Syncdir/Images/foo.jpg, that is, the path is relative to the sdcard. Here, Orgzly-Syncdir is the directory that contains the notebooks and is synced (e.g., with syncthing). Then, inside the synced directory Orgzly-Syncdir, add a symbolic link ln -s . Orgzly-Syncdir. Now, your desktop Emacs sees a relative path ./Orgzly-Syncdir/Images/foo.jpg too. But still it would be nice to see a proper solution.

[aaaawwWWWwwwwWWW]

I have my org directory:

.
└── org
    ├── mime
    │   ├── application
    │   ├── audio
    │   ├── image
    │   │   ├── 5b556eb4-d802-488f-9647-da69a253f722.png
    │   │   └── 9e490293-9811-4aeb-9e59-81174d60e04a.png
    │   ├── text
    │   └── video
    └── roam
        ├── 000cd047-41af-4f85-8e85-16b881ad1afd.org
        └── ffdc3722-9e3a-4388-9185-403423deabd7.org

On Emacs, I can relatively link an image file in an org file on the roam directory like this (which works on Emacs):

[[file:../mime/image/5b556eb4-d802-488f-9647-da69a253f722.png]]

However, on Orgzly it won’t find the file because it skips the org directory:

File does not exist: /storage/emulated/mime/image/5b556eb4-d802-488f-9647-da69a253f722.png

Orgzly is only able to find and display the image file if I change the link to

[[file:org/mime/image/5b556eb4-d802-488f-9647-da69a253f722.png]]

For context, on Orgzly I set the repository to /storage/emulated/org/roam because if i set to /storage/emulated/org it duplicates the org files to the latter directory.

[xiaoruoruo]

@aaaawwWWWwwwwWWW this will work with the unreleased Orgzly version 1.8.5, you could see if you could try it out. Set the new setting "Root for relative links" to /storage/emulated/org/roam/ and links like file:../mime/images/file.png should work.

[ronnac]

@xiaoruoruo This works partly. However i use termux and git. The notebook and images are in the termux app data folder. Orgzly has access to the notebook, but not to the images. When I link to an image in a folder that is accessible; e.g. /storage/emulated/0/Download/ , then Orgzly displays the image.

[aaaawwWWWwwwwWWW]

@xiaoruoruo Tested and works, but as @ronnac wrote, I needed to set /storage/emulated/0/org/roam instead of /storage/emulated/org/roam. Thank you very much!

[debanjum]

@nevenz Can this issue be closed now that version 1.8.5 has been released with the ability to set root of absolute and relative links?

[ghost]

I felt into the same issue and the solution seems a bit "hackish" for me.
For the example above -it only works if we are using files in the org directory.
Would we have a notebook one step higher in the folder hierarchy, it breaks - at least if we are working with the org-file repository from both - emacs and orgzly.
Example: Assume you have this file repo:

└── org
    ├── agenda
     |  ├── gtd.org
     |  ├── gtd.csv
     |  ├── some_other_notebook.org
    ├── mime
    │   ├── application
    │   ├── audio
    │   ├── image
    │   │   ├── 5b556eb4-d802-488f-9647-da69a253f722.png
    │   │   └── 9e490293-9811-4aeb-9e59-81174d60e04a.png
    │   ├── text
    │   └── video
    └── roam
        ├── subfolder
        │   ├── test.org
        ├── 000cd047-41af-4f85-8e85-16b881ad1afd.org
        └── ffdc3722-9e3a-4388-9185-403423deabd7.org

In emacs I would have the following links in ~/org/agenda/some_other_notebook.org:

file:../mime/image/5b556eb4-d802-488f-9647-da69a253f722.png
file:gtd.csv

etc. in ~/org/roam/subfolder/test.org

file:../../mime/image/5b556eb4-d802-488f-9647-da69a253f722.png
file:../../agenda/gtd.csv

What works in emacs would break in orgzly - and the other way arround.

[cashpw]

@nevenz Can this issue be closed now that version 1.8.5 has been released with the ability to set root of absolute and relative links?

I understood the issue to be regarding links from repository A should be relative to the root of repository A. The ability to set a global root for absolute and relative links doesn't solve this problem if you have relative files in two repositories.