Open memeplex opened 5 years ago
Implementing this feature will mostly solve the problem of notebooks nested in a hierarchy as discussed in https://github.com/orgzly/orgzly-android/issues/485.
I believe this feature is low cost and pays too much: by simply differentiating between file:/xxx
and file:xxx
you get:
Consistency between the links in your computer and the links in orgzly.
Consistency between the tree structure in your computer and the flattened structure in orgzly.
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!!!
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 sdcardfile:xxx
relative to notebook, which currently is equivalent to relative to repofile:/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 1a63a685bc987a3e7693ff216eac380ba60e689c):
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).
Where would fit this syntax? [[file-on-main-storage.txt]]
[[file-on-main-storage.txt]]
This is the same as file:file-on-main-storage.txt
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
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
So, does anyone know how to write file links for using with both Emacs and Orgzly?
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.
@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
@vit1-irk could it be definitively solved using org-attach feature? https://github.com/orgzly/orgzly-android/issues/1
@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
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
From SO answer, got this link to manual on attachments. Can we replicate this functionality?
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.
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.
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.
@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.
@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.
@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!
@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 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.
@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.
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.