#orgro — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #orgro, aggregated by home.social.
-
@marlinz008 I thought about such an experiment as well with one very particular use-case: mobile capture.
I was using #Orgzly Revived which has its issues with larger Orgdown files and this overcomplicated sync cascade causing Syncthing conflicts all the time.
I was using it for read-only access to my Orgdown files + mobile capture in one inbox file.
Then I started with #Orgro in parallel just for the capture process so that I don't rely on Orgzly's ultra slow sync process to finish on each capture.
Since Orgro has very weird behavior with shared content (basically I wrote Elisp functions to fix the format for all different kinds of capture content types), I thought about vibe-coding my first Android app just for the capture process in a text file in the format I want.
Not high on my prio list. Let's see how that goes. #ClaudeCode is removing features or adding very annoying stuff so I might as well end up with no proper #AI to do this.
-
@marlinz008 I thought about such an experiment as well with one very particular use-case: mobile capture.
I was using #Orgzly Revived which has its issues with larger Orgdown files and this overcomplicated sync cascade causing Syncthing conflicts all the time.
I was using it for read-only access to my Orgdown files + mobile capture in one inbox file.
Then I started with #Orgro in parallel just for the capture process so that I don't rely on Orgzly's ultra slow sync process to finish on each capture.
Since Orgro has very weird behavior with shared content (basically I wrote Elisp functions to fix the format for all different kinds of capture content types), I thought about vibe-coding my first Android app just for the capture process in a text file in the format I want.
Not high on my prio list. Let's see how that goes. #ClaudeCode is removing features or adding very annoying stuff so I might as well end up with no proper #AI to do this.
-
@marlinz008 I thought about such an experiment as well with one very particular use-case: mobile capture.
I was using #Orgzly Revived which has its issues with larger Orgdown files and this overcomplicated sync cascade causing Syncthing conflicts all the time.
I was using it for read-only access to my Orgdown files + mobile capture in one inbox file.
Then I started with #Orgro in parallel just for the capture process so that I don't rely on Orgzly's ultra slow sync process to finish on each capture.
Since Orgro has very weird behavior with shared content (basically I wrote Elisp functions to fix the format for all different kinds of capture content types), I thought about vibe-coding my first Android app just for the capture process in a text file in the format I want.
Not high on my prio list. Let's see how that goes. #ClaudeCode is removing features or adding very annoying stuff so I might as well end up with no proper #AI to do this.
-
@marlinz008 I thought about such an experiment as well with one very particular use-case: mobile capture.
I was using #Orgzly Revived which has its issues with larger Orgdown files and this overcomplicated sync cascade causing Syncthing conflicts all the time.
I was using it for read-only access to my Orgdown files + mobile capture in one inbox file.
Then I started with #Orgro in parallel just for the capture process so that I don't rely on Orgzly's ultra slow sync process to finish on each capture.
Since Orgro has very weird behavior with shared content (basically I wrote Elisp functions to fix the format for all different kinds of capture content types), I thought about vibe-coding my first Android app just for the capture process in a text file in the format I want.
Not high on my prio list. Let's see how that goes. #ClaudeCode is removing features or adding very annoying stuff so I might as well end up with no proper #AI to do this.
-
@marlinz008 I thought about such an experiment as well with one very particular use-case: mobile capture.
I was using #Orgzly Revived which has its issues with larger Orgdown files and this overcomplicated sync cascade causing Syncthing conflicts all the time.
I was using it for read-only access to my Orgdown files + mobile capture in one inbox file.
Then I started with #Orgro in parallel just for the capture process so that I don't rely on Orgzly's ultra slow sync process to finish on each capture.
Since Orgro has very weird behavior with shared content (basically I wrote Elisp functions to fix the format for all different kinds of capture content types), I thought about vibe-coding my first Android app just for the capture process in a text file in the format I want.
Not high on my prio list. Let's see how that goes. #ClaudeCode is removing features or adding very annoying stuff so I might as well end up with no proper #AI to do this.
-
I've been intrigued by #OrgSocial so I thought I'd set up an official social.org file for #Orgro:
orgro.org is hosted on GitHub Pages and unfortunately they serve .org files as Content-Type: application/vnd.lotus-organizer of all things 😵💫 Browsers seem to treat this as a binary file and just download it directly. It seems like there's no way to customize how it's served.
Org Social's nice preview works, though:
https://preview.org-social.org/?post=https%3A%2F%2Forgro.org%2Fsocial.org%232026-03-09T23%3A22%3A30%2B0900 -
Coming soon to #Orgro (https://orgro.org): transclusion à la the Org-transclusion package
Thanks to @[email protected] for inspiring me to work on this via his fork.
-
Coming soon to #Orgro for #iOS:
Thanks to bug fixes in #Flutter 3.41, if you set the #+LANGUAGE: appropriately in your Org document, you can get the correct CJK glyphs for your specific locale.
(Previously this only worked on Android. I wish I could find the bug ticket for iOS.)
See pictured some of my #CJK test files, and a graphical diff of the TW and HK variants.
-
Coming soon to #Orgro for #iOS:
Thanks to bug fixes in #Flutter 3.41, if you set the #+LANGUAGE: appropriately in your Org document, you can get the correct CJK glyphs for your specific locale.
(Previously this only worked on Android. I wish I could find the bug ticket for iOS.)
See pictured some of my #CJK test files, and a graphical diff of the TW and HK variants.
-
@amake I’m seeing this… version 2.0.7 .::. and thanks for developing this useful app 👍🏽
-
Calling all #iOS #Orgro users!
From v2.0 Orgro is now free for 7 days and then must be unlocked via in-app purchase. HOWEVER existing customers should be automatically unlocked immediately! See the screenshot for what it should look like!
I received a review complaining that the user was an existing customer but had not been automatically unlocked. I haven’t gotten enough info to debug, so I’m asking YOU: are you having this problem? If so, please get in touch!
-
Orgro (https://orgro.org) for iOS is now try-before-you-buy:
Download the app for free, and try for 7 days; buy a one-time unlock to keep using afterwards.
More details here: https://orgro.org/unlock/
-
RE: https://mastodon.social/@amake/115740695319359799
I've been working on moving #Orgro to a try-before-you-buy model where the app is free but requires an in-app paid unlock after a while.
I'm shocked to find out that Google Play offers no way to figure out if someone purchased the app when it was a paid app. Apple, on the other hand, has an API for this.
All reasonable workarounds I can find require users to authenticate with some backend service so you can record their purchase off-device. But Orgro has no backend (and hopefully never will).
-
I'm trying to set up in-app purchases for #Orgro on #iOS. Currently I'm unable to list available IAPs due to:
errorCode = 4040004;
errorMessage = "App not found. Please try again.";I understand this is because my debug build uses a different bundle ID than my production app (so I can have them installed side-by-side).
What do people do about this? Test with prod builds? I see a suggestion to make dummy App Store Connect entries; is that a common practice?
https://stackoverflow.com/a/58422010/448068 -
Should I make Orgro (https://orgro.org) free, but require an in-app purchase to remove some significant restriction?
(All existing customers would be grandfathered in. Purchases would *not* be portable from iOS to Android or vice versa.)
-
In Orgro (https://orgro.org) 1.68 I added support for capturing shared websites or text via the OS standard share UI.
On iOS I was able to add a bit of a bonus: When sharing from Safari, the current selection will be included as the body of the capture (in addition to the URL and page title).
Incidentally this feature is powered by support for `org-protocol://capture` URLs. I've never seen one "in the wild", but if you find one Orgro will handle it!
-
I used the new Unicode script matchers in Orgro (https://orgro.org) to improve text reflow for Japanese and Chinese text.
Previously all text would reflow like the Latin text above—with a space where line breaks were. Now I remove the space when appropriate based on the script of the abutting non-whitespace characters.
-
Orgro (https://orgro.org) lets you slide sections to reveal a TODO toggle. However one thing has always bugged me: With a very tall section it's not clear where to put the icon and label.
So here's what I came up with: Floating!
I'm not sure this is a great solution, but I think it's better than before, where the icon and label would simply be off screen if you slid the section at an unfortunate scroll offset.
-
I don't use coding agents for side projects BECAUSE I'M TRYING TO ENJOY WORKING ON THEM. THE CODING IS THE FUN PART.
And Grok? Seriously? "Hey, the Nazi AI is still free"
Fuck off.
-
Orgro (https://orgro.org) continues to be a labor of love for me. In the last few months I've released some major new features:
- Notifications for Org Agenda items
- List editing features similar to those found in Markdown editors
- Quick actions (long press the app icon) for creating new documents or opening the top pinned file
- A ton of minor Org features that I would never have known about if not for users requesting them
-
Any recommendations for an Android app to read (only) and search through ten mid-size to large #orgdown files I currently sync via Syncthing?
#Orgzly revived does kill captured data (in my setup situation) and #Orgro can't even open my larger files.
Edit: logseq Android is not good with large files + search results. Unfortunately, this doesn't work either.
Edit: Emacs without physical keyboard and being on the go is not an option to me.
-
Any recommendations for an Android app to read (only) and search through ten mid-size to large #orgdown files I currently sync via Syncthing?
#Orgzly revived does kill captured data (in my setup situation) and #Orgro can't even open my larger files.
Edit: logseq Android is not good with large files + search results. Unfortunately, this doesn't work either.
Edit: Emacs without physical keyboard and being on the go is not an option to me.
-
Any recommendations for an Android app to read (only) and search through ten mid-size to large #orgdown files I currently sync via Syncthing?
#Orgzly revived does kill captured data (in my setup situation) and #Orgro can't even open my larger files.
Edit: logseq Android is not good with large files + search results. Unfortunately, this doesn't work either.
Edit: Emacs without physical keyboard and being on the go is not an option to me.
-
Any recommendations for an Android app to read (only) and search through ten mid-size to large #orgdown files I currently sync via Syncthing?
#Orgzly revived does kill captured data (in my setup situation) and #Orgro can't even open my larger files.
Edit: logseq Android is not good with large files + search results. Unfortunately, this doesn't work either.
Edit: Emacs without physical keyboard and being on the go is not an option to me.
-
Any recommendations for an Android app to read (only) and search through ten mid-size to large #orgdown files I currently sync via Syncthing?
#Orgzly revived does kill captured data (in my setup situation) and #Orgro can't even open my larger files.
Edit: logseq Android is not good with large files + search results. Unfortunately, this doesn't work either.
Edit: Emacs without physical keyboard and being on the go is not an option to me.
-
@peaoPerdido i would check out the #orgro app. this is more or less directly working with the sync files. by the way every editor works with org-format … in text-mode … *joke*
Check the setup "Auto-Sync" -> "app suspended" -> turn on
-
If you have #Orgro, the text is fetched and parsed as Org Mode markup. I don't think there are any vulnerabilities there.
For the web, instead of redirecting I could fetch the content and display it as plain text on my site.
But if we're talking https://orgro.org/web?url=https://malicious.example.com and we don't even want to mistakenly send a request to malicious.example.com (divulging IP? other info?) then I guess I have to shelve this entire feature.
-
Along the way I had the idea that you could open any Org Mode file in #Orgro by opening https://orgro.com/web?url=https://example.com/link/to/my/file.org.
I suppose if you don't have Orgro then it should redirect you to the specified URL.
Then I realized: isn't that just one big open redirect vuln?
https://cwe.mitre.org/data/definitions/601.htmlIs there any way to square this circle?
-
I had been thinking it would be cool if you could open https://orgro.com/manual and get it to open the manual in the Orgro app. If you don't have #Orgro then you get what it links to right now, which is the GitHub rendering.
To that end I've been on a wild series of yak shaves to implement deep linking in Orgro.
-
I used to do a lot of localization work, and my lack of knowledge around right-to-left scripts and bidi text always bothered me.
Recently I did a deep dive and implemented proper text direction detection in Orgro:
https://github.com/amake/orgro/issues/19
From the next release bidi texts will be layed out properly!