We need to bump flutter version used?

Ref: https://f-droid.org/wiki/index.php?title=com.madlonkay.orgro/lastbuild_40&oldid=288710

It seems like there's only one font used to cover non Latin scripts? When opening files contains text in Hebrew it seems to be possible to only use one font. Also, the fonts is sans serif, which great for heading but not so much for body text.

First thank you for this awesome tool.

I just wanted to let you know that for me it crashes on chrome OS 85.

However, it works great on my Android device so it's not a deal breaker for me. I can just use emacs on my Chromebook :)

That being said I would love to be able to use this on my tablet.

Regards,
Levi

It would be nice if the app provided a bookmarks list in addition to the current recents list.

I would like to be able to organize specific org files into categories and order them by, for example, dragging the items around.

It's kinda hard to navigate org-roam files without org-roam.

it lets you search for titles: #+title: note title

and show backlinks.

Is it possible to change the filepicker when clicking on +?
The stock filepicker is not the best one for finding .org files.

Edit: Related to #18

On a sidenote: The drawback of a filepicker in general is that you cannot see the #+TITLE when searching.
This makes searching for a file much more cumbersome compared to searching by document title, e.g. implemented in org-roam as org-roam-find-file

I would like to contribute to this project but I have some troubles setting up Android Studio + Flutter + Emulator, especially performance wise. Do you have any resources/advice to make it easier?

Hi @amake,

What's the license of this project?

If it's something open-source like the GNU GPL v3 license, we could try to add it to F-Droid after that, if you're ok.

As reported in #22 (comment), a LaTeX block with a tag (implied or otherwise) will render with the tag overlapping the main body:

\begin{equation}
a + b = c
\end{equation}

I've attached a short file which is formatted badly with orgro (but it has a txt extension). I've also attached a screen shot that shows the strikethrough formatted continuing through a toplevel heading.

bad_formatting_screenshot

orgro-bad-format.txt

This doesn't happen in emacs or in beorg, and I don't know how to address it here.

In addition to #6, which might not be fully scoped yet, I'd propose a very simple and effective solution - support editing the currently open file in an external editor.
For Android, at least, this would be as simple as supporting a few pre-defined editors (not that there are too many), and firing an intent to open them.
If something is missing on the receiving side, like accepting intents or reading the intent parameters, it could be contributed to another Open Source project (i.e. Orgzly).

Potential editors:

• GitJournal
• Markor
• Orgzly

Let me extract this proposal from #5, to allow some focus.

Preface: As I mentioned in a comment there, Flutter has an option (at least on Android) to request permissions for a folder on external storage. This provides access to the whole tree below the selected location.

Proposal: Allow opening a folder location on the device and reading all the files in there.

• option to select a local folder
• display the tree structure for the sub-folders
• allow opening any .org file from the tree

This relates closely to #34, as it would use direct access to the files, without the content provider, so the files could simply be re-read after they have been edited in an external editor.

It will actually allow any sort of interaction with other applications in the OrgMode ecosystem, as well as having attachments, relative links, images, etc.

Making the application available in the F-Droid will be beneficial for google-free Android users.

The latex code is rendered incorrectly on iPad.

\begin{aligned}
y & = (x + a)^{2} \\
& = x^{2} + 2ax + a^{2}
\end{aligned}

On iPhone, the latex rendering is correct.

Hi!

I see that table lines are not wrapped. I'm going to suggest the same for drawers. Here you can see clock drawer lines being wrapped which makes them unreadable and ugly. I'm not sure if it makes sense or not.

Thanks!

Especially on small screens it would be nice to hide the app bar on scroll so that more of the document is visible.

Unfortunately I'm stuck on some unwanted scroll-into-view behavior when the search field gets focus:
https://twitter.com/amadlonkay/status/1275797711506141187?s=20
https://stackoverflow.com/q/62576622/448068

Reported here

I think one thing that would improve Orgro is a list of recently opened files, say the last 5 or 10?

Perhaps some weight based system so it's the most commonly visited files plus the most recent file?

As an an example of my use case, I have a cookbook.org file that I store recipes in, and I tend to open it commonly on my phone. Ditto for my monthly journal as well.

I suppose the possible trickiness may come in making sure that references are updated for moved files, and deleted files are able to be removed from the recents list!

Unfortunately I don't know Dart at all, so I'm not able to even attempt to try and contribute this myself but I've opted to become a Github sponsor since I'd like to see Orgro able to grow :)

Hi,
Thanks for your project. In order to judge the result, you should add at least one screenshot of your app showing some Org mode content to your README file.

Per report: https://reddit.com/r/orgmode/comments/hthpd3/_/fyis69p/?context=1

First see about filtering file picker to just show .org files.

With Emacs Org mode I use hi-lock-mode with a configuration section within my org file for coloring different keywords (RegExp).
It would be a nice addition if orgro would parse this section and color the current org file accordingly.

Here is a sample of the hi-lock section in an org file:

* hi-lock

;; EQUIPMENT
# hi-lock: ((" [Cc][Tt] \\|[Cc]omputed\\|[Tt]omography\\|[Mm]agnetic\\|[Rr]esonance\\| [Mm][Rr] \\| [Xx][Rr] \\| x-ray \\| [Uu][Ss] \\| nm \\| pet \\|pathology\\| mi \\| rt " (0 (quote hi-red-b) prepend)))
# hi-lock: (("surgery\\|treatment\\|genome\\|dental\\|orthodont\\| ecg \\|coherence\\|photon counting" (0 (quote hi-red-b) prepend)))
# hi-lock: (("transducer\\|optical\\|radiation\\|beam \\|pacs\\|archive\\|endoscop[ye]\\|microscop[ye]" (0 (quote hi-red-b) prepend)))
# hi-lock: (("[Oo]phthalmic\\|radiotherapy\\|ultrasound\\|magnetic\\|resonance\\| [Aa][Rr] \\| [Vv][Rr] \\|augmented\\|virtual\\|reality\\|collimator" (0 (quote hi-red-b) prepend)))

;; ALGORITHM
# Hi-lock: (("artificial\\| ai \\|neural\\|network\\| deep \\|learning\\|big data\\|analytic\\|cad\\|training\\|" (0 (quote hi-yellow) prepend)))
# Hi-lock: (("model\\| fusion\\|classification" (0 (quote hi-yellow) prepend)))
# Hi-lock: (("acquisition\\|detector\\|classify\\|render\\|enhance\\|register\\|registration\\| roi \\|region\\|interest\\|segment\\|blockchain" (0 (quote hi-yellow) prepend)))
# Hi-lock: (("monte carlo\\|scatter\\|probability\\|embed\\|3[Dd]\\|scan\\|voxel\\|pixel" (0 (quote hi-yellow) prepend)))

;; ANATOMY 
# Hi-lock: (("anatom[yi]\\|abdomen\\|blood\\|bone\\|brain\\|breast\\|eye\\|heart\\|endocrin\\|embryo\\|limb\\|vessel\\|corneal\\|oral" (0 (quote hi-green) prepend)))
# hi-lock: ((" angio\\|vascular\\|limb\\|neuro\\|lung\\|iris\\|tissue\\|hematom\\|cardi[ao]\\|coronary\\|thorax\\|lumbar\\|spine\\|prostate" (0 (quote hi-green) prepend)))
# hi-lock: ((" head\\|brain\\|nodule\\|thyroid\\|colon\\| liver\\|nerve\\|lymph\\|lesion\\|cerebral\\|cell\\|invitro\\|invivo\\|rectal\\|bladder\\|endometrial" (0 (quote hi-green) prepend)))
# Hi-lock: (("shoulder\\|knee\\|ankle\\|hip\\|wrist\\|scaphoid\\|foot\\|spinal\\|[Oo]phthalm\\|trachea\\|fetal\\|fetus\\|arthroplasty" (0 (quote hi-green) prepend)))

From an App Store review:

please add chinese-gbk-dos coding system

please add chinese-gbk-dos coding system, or any file with Chinese characters will not assign correctly

Chinese characters work fine if the file is encoded with UTF-8, but it would still be better to be able to handle a variety of encodings.

Also *-dos files should be handled correctly already.

First of all, thanks for the great tool! :)

I've noticed an issue during opening one of my .org-files, saying Exception: end of input expected at 459:1. My code for lines 458-459 of related file is:

**** TODO [#B] some plain text
*** TODO AB:CD: some more text and =inline code=

I'm using iOS version, downloaded from AppStore just a few minutes ago.

Reddit thread

Trace from Google Play Console:

java.io.FileNotFoundException: 
  at android.database.DatabaseUtils.readExceptionWithFileNotFoundExceptionFromParcel (DatabaseUtils.java:149)
  at android.content.ContentProviderProxy.openTypedAssetFile (ContentProviderProxy.java:705)
  at android.content.ContentResolver.openTypedAssetFileDescriptor (ContentResolver.java:1694)
  at android.content.ContentResolver.openAssetFileDescriptor (ContentResolver.java:1510)
  at android.content.ContentResolver.openInputStream (ContentResolver.java:1194)
  at codeux.design.filepicker.file_picker_writable.FilePickerWritableImpl$copyContentUriAndReturnFileInfo$2.invokeSuspend (FilePickerWritableImpl.java:154)
  at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (BaseContinuationImpl.java:8)
  at kotlinx.coroutines.DispatchedTask.run (DispatchedTask.java:93)
  at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely (CoroutineScheduler.java)
  at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask (CoroutineScheduler.java:14)
  at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker (CoroutineScheduler.java:28)
  at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run (CoroutineScheduler.java)

Feature

Currently opening a new file is only possible through the system's file picker. This issue proposes a file search based on the document +TITLE: property.

Motivation

Thanks to the new update that allows accessing files in a permitted directory a file-based search should be possible to implement. This file-based search allows searching for org-files based on their +TITLE property and is a small step towards features such as Org-Roam compatibility #17

Pitch

Find and open files based on their document title.

Example

Document

#+TITLE: "Testing a REST API using Emacs and Org Mode"
[...]

Path

├── ...
├── literate_programming_against_rest_apis.org
├── ...

Details

This has been already implemented in Org Roam as org-roam-find-file using a SQLite database for caching.

Hi! I'm slowly adding some basic support for .org files in GitJournal (GitJournal/GitJournal#463), initially only as plain text, and it would be a great step forward if I could simply call Orgro to preview the current file.

Is there a way to open Orgro with the file content to be previewed? What would be the best way to achieve this?
Does Flutter have some mechanism like Android Intents, where one could invoke Orgro with a string content to be previewed? Would you add the missing bits to make this work?

Thanks!

The app currently appears to be missing a viewer widget on Android (not sure about iOS). It would be nice to have specific files viewable on the launcher.

Currently, it seems the app only allows for viewing of org files. Are there any plans to provide write functionality in the app? If so, perhaps we should figure out a roadmap of desirable editing features to provide?

(iPadOS 15.0.2, Orgro v1.21.1)

Expected behavior: When clicking on „Open File“ the files app opens and I can click on the .org file I want to open. The file then opens in orgro.

Current behavior: Upon clicking on the button „Open File“ the files app opens as expected but all .org files are grayed and don‘t react to clicks.

There are some issues providing access and following the file links on Android 10.

Could you be more specific?

Sure. The Grant Access buttons (on top and when tapping the actual link) don't seem to do anything.
Tapping the link to an image reports that there is no app which handles the file type.

Originally posted by @mistery in #35 (comment)

I have purchsed Orgro on Android. When I import an Org file, one specific level-1 Heading (out of 16 level-1 headings) becomes a Level-3 sub-heading of the preceding Level-1 Heading. The same file imports correctly on Orgzly, showing all the Level-1 Headings. Not clear why this is happening.

It would be nice to support opening relative file links like [[./other_file.org][related text]].

Issues:

• Is it even possible to resolve a URI relative to one that we have obtained permission for?
  • Maybe we can prompt for permissions, e.g. show the file picker with the target pre-selected?
• How should the file open?
  • Push a new route on top of the current?
  • Or close the current and open the new file?

More specific than #22, this request is only for displaying the remote images inline.
Local images and attachments are cumbersome due to different ways of accessing the files by different platforms and applications. Hence, some images may be stored online and referenced from within a note.
The images don't change as often as text, so this is one way of solving a big part of the problem.
The option should have a toggle switch in the preferences.
The displayed images should scale so that they fit the screen. Large images may need to be opened by tapping on them.

By remote, I mean the HTTP(S) URLs. The supported extensions should be recognised automatically.
Png, jpg, svg, gif, webp would be my preference.

Just downloaded the app and started viewing the documentation, and noticed a few places where blocks are a large gray box, that send to go on forever. See to screenshots on my Android phone

On the Google Play store screenshots, I can see a dark mode, but I was unable to find how to switch to it.
Is it really available?
Do I miss something obvious?

Thank you,
F.G.

Hi,

The PROPERTIES drawer are displayed nicely but It would be great if Orgro could display other drawers, such as LOGBOOK the same.

Thanks for great piece of software

I use both Android (tablet) and iOS (phone). I store all my notes in a git repo (not Github) and do most of my editing on my computer. I'd love to be able to pull down an view/edit Org files from mobile/tablet.

Hi,

My phone is a 8 year old motorola and it takes Ogro ~30 seconds to open a file of 212K around ~ 5000 lines. However opening the same file with Orgzly is instantaneous.

I'm aware I'm on the extreme in this situation and don't expect any resolution but I guess it's worth reporting it.

Thanks,

I use "Cycle visibility" more frequently than "Change font". However, "Cycle visibility" is hidden, and "Change font" is shown in the top app bar. It's better to allow users to change the order of buttons.

1. Open a file stored in Dropbox or Google Drive
2. Close file and note that it is listed in the Recent Files list
3. Modify the file from elsewhere (e.g. on another machine) and confirm that the changes have synced to the provider
4. Reopen the file in Orgro from the Recent Files list

With Google Drive (and Dropbox, according to reports) the contents will often not be updated. With iCloud Drive the contents do seem to update consistently.

It seems you can force-update the data if you:

1. Find the file in the picker or the iOS Files app
2. Long-press it and choose Info from the popup context menu
3. Wait for the Information section to populate
4. Then pick the file

It is unknown if this is a bug or is intentional behavior.

Partially for #17; as discussed in #44.

id: link IDs are UUIDs and do not specify filenames, so in order to resolve such links to sections in other files, we will need to somehow identify which file contains the ID.

We can get away with not doing a full org_parser parse of every potential target file by doing something much simpler:

stream file content linewise and just extract the IDs e.g. with /:ID:\s+[0-9A-Z-]+/. On iOS in particular this could mean forcing downloads of files that aren't available locally, but if the majority use case for Org Roam is lots of small files then it could be OK.

This would probably happen in the native layer, with the resulting file identifier being returned to the Dart layer.

As a first attempt I may do this on-demand (no indexing mechanism) and see how it goes. If it's unbearably slow to resolve a link (quite possible for e.g. large Org Roam databases like https://github.com/jethrokuan/braindump/tree/master/org) then an indexing mechanism will be needed.

The index complicates things significantly:

• How do we manage the task in the UI?
  • It will presumably be long-running, so the user needs to know the progress
  • We probably don't want to allow multiple indexing tasks to run concurrently, so some restrictions are needed
• How do we ensure the index is up to date?
  • Can we run it on every file open? How expensive is it to run?
• What should be in it? For each file:
  • Persistable file ID
  • File modification date (for detecting when an update is needed)
  • List of IDs found

It could be useful to make test selectable so we could search or look up using the native controls.

Hi. Thanks for creating this app!

I was wondering if it'd be possible to allow the text area to reflow the text respecting the script it's written in. Native iOS text areas do this automatically, I think.

I'll open another issue about serif fonts...

Nope, I'm just running an old version from fdroid guess. Sorry for the clutter.

I store personal and confidential information in my org documents.

As an enhancement, would you consider adding support for optionally requiring FaceID/TouchID/device PIN to unlock the app?

It will be nice if orgro supports displaying images.

Hi,

As an enhancement, it would be great if Orgro could support opening encrypted files, or encrypted headings, with the help of OpenKeyChain. Just like Emacs and org-mode.

ugrep --smart-case --bool is one of the most ergonomic and performant search solutions I have seen.

PS: https://github.com/Genivia/ugrep is licensed under BSD 3-clause, so it should be usable on iOS (where Apple's monopolistic policies disallow GPL code).

I can access the file with no problems using other apps. Using FE app, I have attached my NAS drive using SMB, and I can navigate to nas::/home/Documents/org/ where the file(s) exist, but selecting the 'japanesetest.org' throws the error.

This looks exciting. Thanks for working on this.

However, for it to be truly useful for me, I really need it to have connectivity to Dropbox in order to take advantage of being able to use it for my large Deft and org-roam directories. Any chance of being able to include that (as well, as... and I know you've probably heard this already) editing?... =p. (though was surprised to see it support Apple's native files when I purchased... =] ).

BeOrg breakthrough with users I imagine came through when he provided Dropbox connectivity since so many real emacs users use that for sync directories (possibly in addition to secure webdav).

Really excited and heartened to see more people working on cross platform apps for org-mode.