Hi, this a great feature, just wanted to point out that the documentation lists this option as already available while it's actually yet to be released.

Is there a way to filter the overdue tasks out? I tried using something like s.ge.today but repeated tasks dont show up. And the repeat task shows in the overdue section (eg. There is a task scheduled every week and I have completed it today. I mark it as done -> org mode shifts the date to next week. but the task is still showing in the overdue section) #650 also makes it a bit weird. Thanks

Is there a way to filter the overdue tasks out? I tried using something like s.ge.today but repeated tasks dont show up. And the repeat task shows in the overdue section (eg. There is a task scheduled every week and I have completed it today. I mark it as done -> org mode shifts the date to next week. but the task is still showing in the overdue section) #650 also makes it a bit weird. Thanks

After upgrading to Android 11, Syncthing only works reliably on the internal memory, and not on the SD card. This seems to break the possibility to display inline images using orgzly.

Previously, I could use links like

[[/storage/3738-3234/Syncthing/org/foo.png]]

But now, on the internal storage, my org files seem to be located at

[[content://com.android.externalstorage.documents/tree/primary%3ASyncthing%2Forg%2Ffoo.png]]

(at least that's what I deduce by looking at the path that orgly lists for its synced folders)

However, this link does not work.

What is the required syntax to display images on internal storage under Android 11?

I'd like to use this library in my Java program, but it currently being licensed under the GPLv3 would mean I'd have to license my program under the GPLv3 as well, which is not possible. Is it possible to relicense the library with the Classpath exception or under the LGPL so that non-GPL programs can use the library?

I've resolved the discussion, it was indeed on an old diff so not blocking, sorry for the ping 😅

Hello, Regarding this PR, I think that @debanjum still has a discussion opened, could you close it if the changes are ok for you ?

Not sure how to close the discussion but that discussion shouldn't block this PR. And the changes look good to me! 😃

Hello, Regarding this PR, I think that @debanjum still has a discussion opened, could you close it if the changes are ok for you ? Regarding your comment @lytex, I've just checked and it still seems to be building on my side, with the latest android-studio, are you up to date or maybe using a different setup that could cause the update you mention to be required ? 🤔 I think that the suggestion from @xiaoruoruo to have a persistent notification is a very good idea, maybe this could be a good idea to open an issue to keep this suggestion in the backlog ? And do this as a second step ! Please @nevenz do tell me, if I have to apply some additional modifications, I'll try my best to take some time for them !

Option 3: Copy file into a ID property based directory (org-attach style)

Maybe it should work too with a DIR property based directory

  :PROPERTIES:
  :DIR: folder/
  :END:

Where seems to lie one difficulty is in the compatibility of paths and syntax between orgmode and orgzly.

Looks like there might be two different desires on managing the paths?

Ideally this results in the same directory structure that org-mode creates: A “data” directory with a two-level subfolder structure for all uuids. Each node/heading that has at least one attachment gets a uuid as ID property. Thus one can change the node’s name without the attachment folder having to be touched.

This is one way, I understand it is the org-attach way. The file is stored in a two-level subfolder within "data", and accessed via "attachment:" Link. This will be a bit more work to fully implement because orgzly currently don't know how to resolve "attachment:" links.

* Heading
:PROPERTIES:
:ID: 82bd9766-d8bd-418f-a5bb-5c569e488915
:END:
[[attachment:image.jpg]]

(The file image.jpg lives in a subfolder data/82/82bd9766-d8bd-418f-a5bb-5c569e488915)

The other way is simply storing the file into one subfolder that holds all attachments. The file can then be accessed via "file:" Link. With #496 implemented, user can control where the subfolder is to resolve the relative path starting with "file:".

* Heading
[[file:image.jpg]]

(The file image.jpg lives in the same folder as the org file)

Which one of the two ways to organize the paths would we prioritize for?

I am using attachments more intensively on orgmode lately. It seems to me that orgzly should resolve "attachment" links.

It is very fast to create links using attachments feature. Orgmode looks if there is a PROPERTY with a path SET (or ID) and searchs in it the linked or to be linked file. And it is hereditary, like tags, so there is no needed to add a PROPERTY in every heading.

I just wanted to note that Keybase support is a feature I’d really appreciate! Has there been any progress on this? (Also, support for Keybase’s encrypted git storage would be amazing; not sure if that would be easier/harder than supporting Keybase’s regular encrypted file storage, though.)

This would be a real killer. Current integrations with assistants' lists and notes are awful.

I would prefer it if after a refile a selection of the item or items does not stay around in a location where I can't (possibly) see it anymore.

When I select the next item (to refile it or e.g. to change it's todo state), I usually have to realize that now I have a combined selection of the old refiled items plus the new item. This is not handy.

My rationale would be: When I refile items, I want to be done with them. :)

;) My point of view which is one step further away: Sync with local file system is implemented. But it handles deletions wrong. Hence I would call it a bug rather than a missing feature.

This is a great workaround, thank you!

I worked around it by giving my entries a habit tag, and add .t.habit to searches to hide them in Orgzly. That's good enough for me now.

@Ekleog Seconded this feature. It would be great already not to show them at the top.

Android can copypaste text with formatting, I expect it can also share that. Just a matter of implementing it, if so.

(Being able to choose formatted text or the underlying org format source could still be handy, like exporting an individual note.)

• I have searched for existing issues that may be the same as or related to mine.

The list of repositories uses %3A as a separator for the user-selected portion of the path, making it hard to read and compare the different paths. It should display /.

Consider the general move away from the file systems, it would be useful to support displaying remote images in the same way as local. Instead of synchronising the images along with the text files, I am storing them on the web and use the HTTP url to link in the notes. Unfortunately, these are not shown inline.

What does this option even mean? I am scared to enable it, because it suggests "updating all your notes".

People above saying that the Agenda time range is fixed as 7 days....

I was just experimenting and it seems to work if I touch the search icon and change "ad.7" to "ad.20" (for example).

@aancel @nevenz Specifically... What do you think would be needed to move this conversation forward, so this PR could eventually be merged? Whereas I don't know much Kotlin, I might be able to help...

• [x] I have searched for existing issues that may be the same as or related to mine.

I would like to be able to open a specific file via Intent. Potentially navigating to a specific item within (via line number?). In my case, using Orgro for a read-only (over-)view but would want to open the specific file in the Orgzly editor.

Potential use cases:

• Orgro
• use with Tasker or Termux

The whole concept needs to be worked-out into more details and potentially coordinated with Orgro project.

Found a small issue I want to resolve before commit.

Added an option to enable the reminders to be sticky and not swiped away until completed.

There is already #566

Depends on your definition of a bug. Bugs usually indicate something that was implemented and is now broken. Why would it be a bug if it was never implemented?

Added an option to enable the reminders to be sticky and not swiped away until completed.

@lytex I understand, but anything is better than nothing. Title + formatting-stripped contents. or all the relevant note as-is from the file (as if copied from the org file itself using a text editor). or some other solution.