I heartily agree, after about a month I now do all my document authoring, PDF, LaTex, HTML, personal wiki notes, all of it goes in .org files. It was low barrier to productivity, and not much more effort to turn org mode into a powerful idea and through organizer as well as documentation.
Beyond that I can author in org mode and then export to tex, to pdf, to html, to markdown to whatever I want using org mode.
If you are a long time vimmer do yourself a favor make the next tech you learn be org-mode in doom-emacs. It is insanely powerful and I will never go back.
I'm sure there will be plenty of people to tell me that I'm wrong.
First, Emacs already has excellent LaTeX support. Unless org-mode brings you any major advantage over plain LaTeX (which I doubt it is when you're writing a paper, that's not exactly 400 pages of loosely-coupled ideas) the extra headaches of dealing with one more intermediary language and set of packages isn't useful. If hacking on org-mode is your hobby, then yes, it's an enjoyable experience. But if you're just using it, then it's one of those cases where knowing you can is not enough, and you should maybe stop for a second and think if you should.
Second, I don't think anyone ever intended for org-mode to be used (as a wrapper) for authoring scientific papers. It's great that you can export your notes to LaTeX because it allows you to easily integrate them with existing manuscripts, it allows you have formulae embedded in them and so on. It just so happens that it's so good, and so flexible, that you can do it -- but there's no world in which a simple (no matter how flexible!) export engine for/wrapper around a language will ever be able to deal with complex matters that even said language can barely deal with.
It's one thing to use it for authoring simple documents (like blog posts), that works great. But when it takes hours of fiddling just to get the editor-supplied template to play nice with your text and figures, the last thing you need is one more moving piece.
I'm sure if I was better at Lisp my opinion would be different. But if I was writing something and wanted to target LaTeX or pure HTML, I'm not sure I would use Org-mode as the source unless I was writing the converter myself. I think I'd just write in HTML/LaTeX directly.
That being said, I would probably still stick all of my notes, references, and TODOs for a scientific paper in Org-mode, and then use LaTeX just for the final paper. The fact that Org-mode can do text references like
* TODO Find facts about bees
Need more details at file:~/final.tex::And another thing about bees
References checklist:
- [ ] https://google.com
- [X] https://duckduckgo.com
- [ ] https://wikipedia.com
I would not write a complex technical paper in Org Mode, other than just to get my thoughts together initially to eventually copy/paste into LaTeX.
But, Org Mode is good enough for most of my writing over the last several years. It is more readable as plain text, and exports to HTML or PDF trivially (the latter via the LaTeX export hook). I like it enough that I use it as the basis of my blog, exporting each article to HTML and then massaging the HTML programmatically to generate static files styled and cross-linked the way I want. This approach gives me math formulas via MathJax, still images, tables, code snippets... basically everything I want for a somewhat tech-y blog.
But, yeah, if you're going to just write a full-on technical paper for publication, I'd go right to LaTeX.
https://github.com/dandavison/xenops
It's basically a replacement for preview-latex: it renders math/TikZ/table fragments automatically and asynchronously. If any emacs-lisp programmers who are interested in LaTeX editing would like to help out please get in touch!
I once wrote a short report that I (probably) could also have written in (any equivalent of) Word or LyX/TeXmacs, or some random WISYWIG editor. Very little finetuning of the layout required or necessary, people still liked it better than plaintext (it had some headlines and tables and stuff, but nothing too fancy). So, nice output yes but be careful if what you need is actual LaTeX document preparation.
(defun my-org-screenshot () "Take a screenshot into a time stamped unique-named file in the same directory as the org-buffer and insert a link to this file." (interactive) (setq screenshot_dir ".\\images\\") (setq tilde-buffer-filename (replace-regexp-in-string "/" "\\" (buffer-name) t t)) (setq filename (concat (make-temp-name (concat screenshot_dir tilde-buffer-filename ;; attempt to make irfanview approach work "_" (format-time-string "%Y%m%d_%H%M%S_")) ) ".png")) (insert (concat "[[file:" filename "]]")) (org-display-inline-images))
(global-set-key "\C-cs" 'my-org-screenshot)
I wa salso curios about org-roam but I'm letting it sitt for a while
At least that has been my experience a more seasoned orger can correct my ignorance if I do err.
Perhaps it would make it more familiar, but I don't think it would really simplify it.
First because I think issue handling on GitLab/GitHub kinda worsen the problem of the lack of maintainance resources, instead of fixing it
Second because we are quite strict on how to format changelog entries, and I believe email interactions help educating contributors in a nice way, while MR/PR interactions might generate more fatigue -- not so sure about this one, though.
The basic notion is that the email threads model is focused around the subject line, and PR-model is specifically designed to have discussions where the code changes take the main stage.
I'm sure if you ask Jonas Bernoulli, Steve Purcell, Oleh Krehel, Bozhidar Batsov, and many other prominent Emacs hackers, they'd probably agree, without PR-model, it would be a lot harder for them to find so many contributors for great Emacs packages they authored and maintain.
To be honest, it feels a bit ironic when the shepherds of Free Software (GNU hackers, et al.) choose to ignore the people's free will, and in 2020 it is clear - people have made their choice. They don't want to deal with email threads, patches, etc. The majority of developers prefer to be able to issue Pull-Requests instead.
But there's something else, there's now an entire generation of software developers who simply don't know how to deal with sending patches, etc., and they don't even care. And that's not a good trend. The issue of patches vs. pull-requests has become generational. And if the old software projects fail to adapt, I'm afraid they'd slowly start dying.
(a) you have no ability to edit entries (or do anything else that email is bad at),
(b) the mail interface is frankly hard to read, with everything in uniform monospace font and no formatting,
(c) I can't participate or reply on the web interface, I have to sign up for something completely different to participate.,
and (d) because of the way the site is laid out, I can't see how to get the code, etc. from the bug tracker. I would presumably go back to Google and search for org mode and then try to figure it out from there. But that's just a lot more steps to do what could be made easy.
Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job.
I don't personally think that Github makes PR formatting any harder; I would expect any contributors to use a git command line to look at what they put in the commit message. But at any rate, that's some user education you'll have to do one way or the other. With the current approach, you've got a bunch of other barriers to entry that prevent you from seeing certain users in the first place.
From what I understand, Bram's vim development workflow is very similar to other emac's dev: submitting and discussing patches via the mailing list. There was something (a bot?) setup such that PRs are forwarded to the mailing list: https://github.com/vim/vim/blob/master/CONTRIBUTING.md
This was discussed pretty extensively when vim moved from Google Code to GitHub: https://groups.google.com/g/vim_dev/c/Io5A_Zir--k/m/faPCHWYf...
In general, PR/patches-friction should not be an obstacle for contributions because it can be alleviated in part by tooling that glues the workflows more-or-less seamlessly.
EDIT: It might be worth asking how the neovim community in general may have been helped by the decision to make github their home, or maybe even ask the emacs-lsp devs on their gitter: https://gitter.im/emacs-lsp/lsp-mode ?
EDIT 2: In the vim-dev mailing list, there are threads started from GitHub pull requests that include .patch and .diff files: https://groups.google.com/g/vim_dev/c/7VpUqzoQycY/m/W_7zhTGf...
- [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.]
- [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?]
- [For the copyright registration, what country are you a citizen of?]
- [What year were you born?]
- [Please write your email address here.]
- [Please write your postal address here.]
I have several bugfixes and enhancements to various org-babel languages that I maintain for my local code, but I have no interest in jumping through copyright assignment hoops or sharing my age & mailing address to push them upstream.
[1]: https://www.theregister.com/2020/08/25/linux_kernel_email/
I don't know if there's some way to "partially" move to GitHub—it would be cool if there were some service that synced GitHub issues with a different tracker, for example, but I've never seen that. Perhaps it would become too noisy.
Of course, more contributions might not be a net gain. For each dedicated contributor, you'll also get drive-by PRs and issues that add noise which maintainers have to deal with. I do not know how that trade-off plays out in practice.
So I can't give a definite conclusion about whether GitHub is worth it, but I would be willing to bet that working on GitHub would get you more contributors.
Another concrete example is eglot: it is developed in the open on GitHub, which is great. But it is closely related to two other emacs packages: flymake and eldoc, which are developed via emacs-devel, or something, I've never really understood. So when changes need to be made in those packages it suddenly becomes very opaque, and I am not at all sure how much code review goes on. (This is not at all a criticism of João Távora who maintains all three I think! It is more structural and related to Emacs development in general.)
It dissuades me from contributing to emacs in general. There is nothing advantageous about reviewing code by mailing list when we have GitHub and GitLab. For those of us who use GitHub and GitLab in our day jobs for code review and collaboration, it is really baffling and frustrating. Furthermore, although the org-mode mailing list is, I am sure, just as pleasant as it always way, lists like emacs-devel are incredibly toxic and depressing to read; a bunch of men arguing just like they did over IRC in the 80s and 90s. And good god, don't ever go near the #emacs IRC channel if you're not someone of that gender from that generation!
I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public. For example, the magit maintainer responded rudely, aggressively, and discouragingly to recent PRs against magit. Stallman's absurd one- or two- sentence replies. This is of course not Org-mode's fault; but I believe the future of Emacs development is to embrace GitHub / GitLab like other open source projects and leave the crusty 90s-era practices behind.
I was genuinely considering learning org-mode and giving another go at using Emacs as my primary editor. Now I'm worried if it still makes sense to do that.
Clearly a lot of people still find Emacs useful but the ecosystem seems too hard to break into. I'm still curious why Emacs hasn't obtained the same level of excitement as other editors like Vim and VS Code.
I think Emacs has missed some of the excitement of, say, VSCode because until recently it hasn't had many opinionated guides to using it (like Spacemacs or Doom Emacs). I've overheard a lot of conversations like:
New user: OK, got it installed! Now what should I do?
Emacser: Anything you want!
New user: I want to write Python. What's a good way to do that?
Emacser: Here's 47 similarly named but substantially different Python modes. Choose the one you like!
New user: Which one do you like?
Emacser: I started with one I found in a GitHub gist, then modified it to do remote editing over a 3270 terminal. You should check it out!
New user: ...
There's a lot to be said for the VSCode approach of "here's the golden path to doing ${thing}. Once you've learned it, you might try the alternatives to see if some are a better fit for you." Alternatively, consider the analogy of a Linux distro that gives you a well configured KDE or Gnome environment, but that lets you switch to another DE once you've been using it for a while. Now Spacemacs and Doom Emacs are providing that experience to new users, and I've heard more excitement about Emacs in the last couple of years than in the previous decade.
I have also heard good things about Spacemacs but I haven't tried it yet. It is a bit of a learning curve at first, but after three months I am starting to surpass my productivity on vim + bash + tmux and that's not bad considering I'd spent something like 5+ years in the previous environment.
The only thing that pushed me from Spacemacs, which is a nice distro, to doom was Spacemacs instability. I needed some things from the beta channel and it lived up to its name.
I just want to make things easier for the futur Org maintainer by spending the next few months recruiting more contributors.
Unlike many software projects, ones built on Emacs are very stable in the long term, as Emacs itself takes stability and compatibility very seriously. As well, these projects have many users, many of whom are Elisp hackers, so I have no concerns about these projects' long-term health.
So please don't panic just because one maintainer is preparing to reduce his activity in the project. Neither Emacs, nor Org, nor Helm are going away.
What finally drove me to it was Org. I got super tired of proprietary to-do/data managers evolving away from my needs. The last example was the VERY popular OmniFocus, which had a major rev that introduced tons of whitespace and thereby killed the "high data concentration" view that I wanted.
OF was also pretty crap at something else I really wanted, which was the ability to have TODO tagged items in my notes. It could almost do that, but not really. And, of course, Omnifocus files are opaque.
Orgmode is exactly what I wanted. I have a huge corpus of files that are searchable with almost immediate speed (via Deft), and Org itself is awesome at pulling the TODO items out of a notes outline.
I manage a whole bunch of client relationships/implementations, so I have a file for each customer. I can easily scroll back and review the history of a deal/engagement, see what was discussed and what was decided, and also see all the todo items that I noted and did, and when they were done.
The agenda function means I can see a review of all the active TODO items across all the org files super super easily.
The tl;dr is that it's SUPER powerful, and will absolutely reward you spending a couple days figuring out how to make it work for you. There's a bunch of very generous people in /r/emacs and /r/orgmode who will help you, too, if you get stuck. I strongly suggest you give it a try.
I don't edit EVERYTHING in emacs now, but org has me pulled in enough that, unless it's an email or a real document, I'm probably in emacs.
I love Vim (as an idea) and I embraced Lisp (as an idea). I learned that Emacs could do everything that Vim does and even more and better. And just like I can't even type anymore without using vi-bindings, I can't imagine my life without Emacs. Emacs has all the facilities to (re)use and implement nice ideas. The other way around is not always easily possible.
You cannot cook shrimp pasta if you don't have any shrimp, it's going to be just regular pasta. The secret ingredient of Org, Magit and many other great Emacs packages is Lisp. And there's no Lisp environment better than Emacs.
Can someone explain to me why if org-mode is so popular it is not used in places other than emacs or why is it bound to emacs? Is there some ux quality or set of features that are bound up in the unique key-bindings of Emacs or the scripting integration for example? Could any of this goodness make it's way to more accessible (for your average user) venues such as a basic GUI note taking app?
1. Document structure. Folding, tree structures, linking, etc. are done very well in org-mode. But that's not unique to org-mode, several other solutions do that well.
2. org-mode lets you use all of the other Emacs major and minor modes in your document - restricted to sections. This is amazing, as it basically gives you an entire application layer in your text documents.
Where by entire layer, I mean having your calendar, email, programming environments, etc. all within your notes. org-mode used this way is not merely a document editor. It is the best plain-text workflow enabler the world has ever seen.
And you can't do this outside of Emacs without essentially rewriting Emacs. Emacs _is_ the strength that org-mode leverages. org-mode is a unification of the many and varied Emacs major modes into a simple plain-text environment.
And the best part is, you only need to use the particular modes you want. Your org-mode experience is tailored around your use case. You bring in the mode you want in that section and you're done. It just works.
> You bring in the mode you want in that section and you're done. It just works.
I haven't used org in a non-superficial way for a while. What are you referring to here, src blocks?
Glad to find long-time power users here btw :)
Switching to org-mode helped me keep on top of everything in a way I'd never really experienced before. Since then I've expanded my usage of org considerably - I use it for taking notes, tracking my diet+exercise, and planning out my projects (more info here: https://www.philnewton.net/blog/emacs-org/).
It's not everybody's cup of tea, but for me it fits my mental models better than anything I've ever used.
| -1 | req. | 100 | 100 | 50 |
| 3 | milk | 2.92| 4.37| 3.5|
| # | |-91.2|-86.8|-39.5|
#+TBLFM: @>$3..$5=(@<$1..@>>$1)*(@<..@>>)I'd be hard pressed to come up with a more important tool in my productivity/organization toolbelt, it's become a really important part of my notetaking process. It's not perfect by any means (exporting to other formats in particular is kind of messy), but it's an insanely powerful platform that does a ton of stuff, and is just really flexible without being too overwhelming. At the end of the day, everything is just text, so you can get in really deep with scheduling and capture templates, or you can just write out nice TODO lists.
Also check out Orgzly on Android if you're looking for a mobile client. Works pretty well with a Syncthing setup, or you can host your notes on a platform like Dropbox if you think that's easier.
How are people handling getting org files on multiple devices, with sync support etc. Dropbox?
I'm not sure what the situation with the tests accompanying Org is, but in order to build future-proof software, tests are mandatory, comprehensive documentation is also very important. There's another element which I haven't really seen with Org, a clear idea of when and where to stop. As previously mentioned, the development phase of software should always have an end, in sight. The cases where software is developed for 2+ decades is very rare. This is mainly related to requirements and to the goal of the software, and I think this is something that wasn't done for Org. It's unclear where Org ends.
It's interesting that Org could never have evolved out of some committee super-formal development environment (with tons of managers, SCRUM masters, architecture boards, etc), but at the same time it is an expertiment out of control. It's very dense and rich in ideas, but also in chaos (I guess we can't really have the former without the latter).
Still I think the parts that distinguish Org from all other dynamic document formats, and from all other markup formats is that.. it's the most advanced, it was there before asciidoc or reStructuredText. Org is a pioneer in many ways.
Thanks for bring the message out, bzg.