Some added tips: ditaa is cool but you can also integrate mermaid  well and display inline images. There's a well-done revealjs  exporter. And you can also use results blocks as input to other code blocks!
PDF export is excellent and integrates well with some scripts I wrote to publish them to my remarkable. Great for writing and then reviewing specs on the go.
The drawback is that sharing the document sources with a team is hard since so few people on a team are likely going to be emacs users. Only work around I have for that is to run emacs in batch mode to generate/export docs... or just export to markdown and maintain in markdown if the team uses a different tool or dislikes the org syntax.
I dived into emacs in janurary 2021 fully using doom emacs. I started doing scrum and meeting notes in org, then find myself slowly switching existing notes over to it.
i keep all my emacs configs from ~/.doom.d in git and can easily bounce from machine to machine. Setup is pretty easy and i've found to have the same emacs experience where I go.
I'm not really a note taker, and I haven't picked up org yet. I actually uninstalled it before I realized that all the Doom docs are written in it and without org-mode you can't follow links XD
- DOOM Emacs is fast. Fast to start `emacs --daemon`, fast UX with the default config.
- I've experienced DOOM Emacs to be more cohesive than Spacemacs
I still keep my Spacemacs config around, but I haven't touched it in ... almost a year now.
Additionally, I've found adding my own customizations is much easier in Doom than Spacemacs. While the Spacemacs "layers" approach is nice for setup, it can become very brittle when you start hacking on it yourself. Some of that could also be due to my own lack of skill with elisp, though.
Org-mode can generate latex output but the whole point is to be a more human-readable markup format than latex. Org-mode can also convert your equations to images and display them inline.
Vim has Org mode too https://github.com/jceb/vim-orgmode
Those mobile editors usually do not have macro functionality. But as soon as you have editor with macros it is possible within some 30 minutes to make few macros to add tags, change TODO states, add SCHEDULED or DEADLINE stamps or similar basic features.
Org is not collaborative, database is collaborative, redundant, it offers way easier development then trying to handle database things by using text.
By the way, people speak "Org mode is plain text", that is was back in time, today Org mode is everything else but plain text.
Couple questions first, if you don't mind:
- What's the sync integration surface like? My ~/org lives in Dropbox, so I'm hoping that's an option.
- Any plans for Siri and notifications integration? Sounds like that might be outside your use cases, so a "no" here is totally fair, but I'm still curious.
Side question, do you have any especially good resources around Swift and/or iOS UI/UX design that you might want to recommend? Asking because it looks very much like I'm about to pivot into app dev via React Native, and I'm looking to make the most of the opportunity, especially as it comes to iOS.
Thanks in advance, and here's hoping your habits app becomes everything you want it to be!
Sure! Ping flathabitsatxenodium.com for a TestFlight invite.
> - What's the sync integration surface like?
Relies on other apps to sync. If iOS Files app can get access to it, the habits app will too (including conflict resolution). Dropbox seems to work. I could use more testing in this space if you’re keen.
> - Any plans for Siri and notifications integration?
Notifications are supported. Hadn’t considered Siri. Will give it more thought.
> Asking because it looks very much like I'm about to pivot into app dev via React Native
The app is native SwiftUI.
You likely know all these... WWDC videos are great. Generally, hackingwithswift.com is great too. Also dimsumthinking.com has high quality material.
Didn't know Leo; will have a look at it. My preferred IDE is Qt Creator 3.x.
Maybe you can check the Linux version with ldd and file, i.e. whether it misses a specific system library version or maybe your system is 64 bit and not all required i386 parts are present.
Emacs org-mode examples and cookbook - https://news.ycombinator.com/item?id=13828732 - March 2017 (161 comments)
I wish I used babel more. Last I used was to give live examples for some external API interactions we needed to document.
also, even though calc rpn stack is cute, having it in SRC blocks is quite dandy
One thing I found tricky was switching computers or getting a new computer can be very disruptive to the emacs/orgmode workflow because of the amount of customizations that build over years of using a specific orgmode workflow. Apps, on the other hand, are very portable between devices (phone, table, laptop).
Are there easy solutions to make emacs and orgmode set ups more portable between machines?
(Speaking of preserved customizations, by default those are written into ~/.emacs.d/init.el. As part of setting up for a version-controlled ~/.emacs.d/, I'd strongly recommend setting 'custom-file to e.g. ~/.emacs.d/custom.el, so that those are stored separately from your init logic proper - it's not a huge issue either way, but customizations are a fertile field for merge conflicts due to the way they're written and stored, and I find this makes those conflicts significantly more comfortable to resolve.)
You could in theory also add init logic to check for the presence of needed external binaries and, if necessary, install them via Homebrew, apt, or some Windows equivalent - I've thought about doing this since I already do have some platform-specific logic in my init, but it hasn't been enough overhead to bother since I rarely need to spin up a new workstation machine.
(Also, of course, ensure that you store any secrets like passwords or other credentials in a separate file, not checked into version control.)
To ensure you reliably have a specific version of Org, you can add the orgmode.org ELPA  to your 'package-archives and install a given version from there, rather than relying on whatever comes with a given Emacs build. I do this myself and recommend it to others; Org changes a good deal between versions in my experience, so version pinning helps avoid unexpected behavior that has otherwise been fairly common.
In the same spirit, it can be worth building Emacs from source on a new machine. I also do this, again in order to ensure the behaviors of a specific version to which I've become accustomed; I generally upgrade only when a major new feature or bug fix makes it strongly worthwhile, and then on all my machines at once. (It's a manual process, but not a difficult one. I guess I could automate it, but for something I do a few times a decade, that hasn't seemed worth it so far.)
:ensure t ;; install package if it doesn't exist
(global-set-key (kbd "C-c w") 'wordnut-search))
:if (eq system-type 'gnu/linux)
:if (eq system-type 'windows-nt)
It even has nice use-package integration, so if you're already using that you likely won't have to change all your config.
That's one solution.
I've got mine under Git. It's a bit more "work" in that when I upgrade packages (which I don't do all the time) I need to commit what's been deleted/added but I can at any time go back to any past working setup.
Then I just use Git across user accounts / machines to synch my Emacs setup.
Others are using Nix.
> Each time I update all packages something new breaks...
Don't know what's the "proper" way to do it but I upgrade packages manually and never all at once. That is: I never start from an empty Emacs. There are some tradeoffs I guess but I never have to track down which package is problematic and reverting is basically checking out the last commit.
I'm not saying it's the best way to do it but it just works.
I did this for a little while, but now I just use org notes on my work computer, and the ios notes app for personal things. Org need not consume everything.
But yeah, otherwise, it's a problem. I've grown very dependent on org and emacs, but access anywhere but my two laptops is kind of painful and kludgy.
I can use BeOrg, but BeOrg seems to have been built to support an orgmode use pattern that is very different from mine.
I can also ssh into my Ubuntu vm from my iPad, and obviously THAT experience is fine, but it's also more of a production than I'd really like if I just want to briefly interact with the org files.
I do keep my ~/org in Dropbox and have a phone app I can use to make quick edits, and which I have used for longer writing on trains and such. But it's definitely not a first-class UI, and I don't try to use it as such.
(On the other hand, I'm getting ready to redo my blog in Jekyll rather than Wordpress, not least to improve the authoring workflow by being able to bring it into Emacs...)
I use an Exchange calendar for work, and I don't have appointments as part of my agenda in Org. I carry a notebook with me when I'm out and about for jotting things down. Like you, I can get to my corpus of org files via Dropbox from my phone and whatever editor I want to use there, but that's more of an "in a pinch" kind of use case than anything I'd want to do on the regular.
If I need to write something real on the go, I just do it in Notes on the iPad, and then migrate it into org if that's where it needs to go when I'm back at my computer.
I still blog, too, but I use a dedicated tool called MarsEdit on my Mac to do it. I haven't seen a reason to move that into Emacs, though I'm sure it's technically possible.
#+BEGIN_SRC python :var fname="delseepy.png" :var delsee=delsee :results file
import matplotlib.pyplot as plt
x, y, z = zip(\*delsee)
fig = plt.figure()
axes = fig.add_subplot(1,1,1)
axes.plot(y, z, marker='o')
If you try to do too much at once, of course, you are prone to give up as you started on a too high gradient.
Note, many emacs users aren't men at all.
(org-babel-do-load-languages 'org-babel-load-languages '((python . t)))
(setq org-babel-python-command "~/mpl-venv/bin/python")
There have been a few different fixes around the "last line" return value over the years but I can't really remember something like your example not working for me personally.
After installing matplotlib using pip3 and changing =org-babel-python-command= to python3 I was able to execute this example without a problem.
The value of =org-babel-python-wrapper-method= for me is:
open('%s', 'w').write( str(main()) )"
It makes me very happy that GitHub supports formatting your README in org-mode.
> Multics Emacs is an early implementation of the Emacs text editor. It was written in Maclisp by Bernard Greenberg at Honeywell's Cambridge Information Systems Lab in 1978, as a successor to the original 1976 TECO implementation of Emacs and a precursor of later GNU Emacs.
> EINE and ZWEI are two discontinued Emacs-like text editors developed by Daniel Weinreb and Mike McMahon for Lisp machines in the 1970s and 1980s.
> Unlike the original TECO-based Emacs, but like Multics Emacs, EINE was written in Lisp. It used Lisp Machine Lisp.
The only one you might be able to run natively now is Hemlock:
> Hemlock is a free Emacs text editor for most POSIX-compliant Unix systems. It follows the tradition of the Lisp Machine editor ZWEI and the ITS/TOPS-20 implementation of Emacs, but differs from XEmacs or GNU Emacs, the most popular Emacs variants, in that it is written in Common Lisp rather than Emacs Lisp and C—although it borrows features from the later editors.
It requires some light setup to get working, since it's not part of the base functionality of Org. First, add these lines to your config (more details on StackExchange):
I suppose radio target links function a bit like inline tags, in a way, in that wrapping a string in <<<angle brackets>>> and C-c'ing it turns every use of that string in the file into a C-o'able link to the original radio target. Definitely not as featureful as proper :tags: but also has it's uses...
I feel this functionality is overlooked, and it is in my opinion one of the most powerful features implemented in org, as it allows you to add "meta" groupings to your org document without any effect on the content.
Without the :ignore: tag, there is a strict semantic relation between org-mode document headings, as physically indicated by the * at the beginning of a line, and the corresponding hierarchical level of the heading's content.
With the :ignore: tag, however, you separate content from form. Headings with :ignore: work just as headings for your file.org document: you can search for headings, link to them, add IDs and properties and whatever else you can do with headings. But when you export your document, the heading no longer exists and thus has no impact on the hierarchical level of its content.
Why is this interesting? Well, because if content is separated from form, we can build things where the same content assume multiple forms depending on whatever context we define.
I used this in combination with other org-mode tags, "#+exclude_tags" and "#+include" directives to build my Ph.D. thesis with org mode and have my thesis chapters be exportable both as thesis chapters as well as standalone publications. Shameless plug: https://github.com/dangom/org-thesis
It should be straightforward to extend the idea to presentations and other formats as well.