The simplicity to accomplish this result is incredible. Similar things can be accomplished in #vim too.
Modern editors have to expose configuration flags for such features. Which are indeed easier to use if present, but less configurable and less composable.
Hey #PKM people, as it seems fashionable here to humblebrag by posting screenshots of graphs: What exactly are the benefits of a graph view? Aren't bi-directional links just simpler and thus more effective?
As this is yet another Emacs org-mode update, and several people comments on those, I created Emacs org-mode category on my blog with its own dedicated RSS feed: https://taonaw.com/categories/emacs-org-mode/feed.xml
Doing both requires much effort: double modifications, double backups, ...
Don't know what to do.
Just for (technical) reference, rhe page is written in simple #OrgMode markup and automagically exported to HTML.
Ideas?
I'm trying to use #orgmode as a replacement for #jupyter. I'm wondering if others use Org that way, and what their solutions are for getting inline plots/images. Ideally I'd like to be able to get regular stdout output and plot output from the same code block as you can in jupyter, and then have the image show up inline at a reasonable size without having to manually mess with filenames, image sizes or adjust headers every time I want to do that.
@0x4d6165 notmuch. The coolest "trick", but also curse at the same time, in my opinion is to store all mail locally. Combined with local #orgmode files this can become a reliable autarkic knowledge base. Following a reference to an email from inside an org-mode file will always work immediately, no network request needed. Curse, because it requires custom setup to load mails into the system, and to sync metadata (notmuch's tags) between machines.
I love #orgmode, but there is an idiosyncrasy in org-capture's that seems atrocious to me. Whenever I go to capture a note, the capture buffer deletes all windows that are open except one, and splits it so only that window and the org-capture window are visible. As far as I can tell this is the behavior regardless of what your settings for display-buffer are.
This seems to be because instead of respecting display-buffer settings it uses delete-other-windows to ignore them instead. I can advise it to ignore delete-other-windows, which is better, but it still undoes any changes I make to my window layout while the org-capture buffer is open. Secondly, it also doesn't restore #EXWM windows properly. I cannot fathom why the maintainers would ignore a user's display-buffer preferences.
This is bad enough that I'm thinking about abandoning org-roam, (and probably any other org-capture based workflows). I carefully curate my window layout so that I have the information needed available to me. Org-capture decides that it knows better, and leaves me with a highly inefficient workflow for accessing the information I need to make my note. I just don't understand the rationale here.
If anyone knows a workaround to this insanity, please let me know.
Wow, I can't believe I'm only just learning about the org-pretty-entities variable in #Emacs#orgmode. Setting it to t automatically transforms a lot of LaTeX fragments into unicode symbols in the buffer.
I've been using the $ delimiter around very small fragments (e.g. $\sigma^2$) and then using org-latex-preview to show it in the buffer. Much slower and clunkier obviously, I wish I had known about this a year or two ago! 🤦♂️
I’m looking for alternatives to #emacs#orgmode for #iPadOS . I used to ssh’d to a remote machine with Emacs, but it isn’t that good even with Mosh. Suggestions? Halp! 🆘
At the end of the day, I want to use the org-roam note-taking plugin. I know about #Logseq but I wonder if there’s something else to look for 👀
I know that probably has been there for a while, but have never activated it! :ablobattention:
Do you also use #orgRoam ?
This is a core node with an index, not sure if I should use it or link nodes differently.. but comes handy and can always disable it with filters :abloblamp: