Org-mode 9.4 is out. Can you help? | Hacker News Reader

Org-mode 9.4 is out. Can you help?

bzg.fr

190 pointsbzg112 comments

Just want to throw out there I switched to emacs about 3 months ago after being a long time vimmer, one of the first things I was told was to check out org-mode as it was one of the greatest features of emacs.

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.

Can you copy and paste an image into org mode? In many of my document/notes I find that I to copy and paste images into my documents like I take a screenshot and then paste..

No, org mode is text based; however what you can do is link to an image, and then when you publish the org mode file as html, or pdf or whatever it will get interpolate and appear as though it had been pasted in.

At least that has been my experience a more seasoned orger can correct my ignorance if I do err.

Org mode supports inline images. See more here: https://stackoverflow.com/questions/27129338/inline-images-i...

If you use it on Windows and have Itfanview installed, here's is how you can do it to copy paste images from clipboard using C-c-s

(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)

Could you indent your Lisp by four spaces for formatting?

    (Like this)

On HN you only indent two spaces to turn on monospace.

Here is the lisp with formatting:

  (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))

Did you mean Irfanview?

Thanks for the tip. Mostly emacsing via X, but good to know.

There are plenty of ways to do it -

https://github.com/abo-abo/org-download

I just jumped to emacs from vim last week and this was one of the reasons, yes it is possible to display images!

I wa salso curios about org-roam but I'm letting it sitt for a while

Yes, with the org-download module (https://github.com/abo-abo/org-download). I have some additional configuration to paste a screenshot (asking for a filename) using a keybinding. Here is my config: https://github.com/zzamboni/dot-doom/blob/master/doom.org#ca...

I made the mistake of trying to author a scientific paper in org-mode. Big mistake. I should have just stuck with LaTeX, because what ended up happening is that all my problems and difficulties had to do with me navigating org-mode wrappers around LaTeX, when I could just have dealt with LaTeX directly.

I'm sure there will be plenty of people to tell me that I'm wrong.

What pain points would it have saved to write the scientific paper in org-mode? Usually there's a dozen dirty little corners where you want fine-grained control and the org-mode-to-latex converter isn't giving you that by default.

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.

>What pain points would it have saved to write the scientific paper in org-mode?

For me, latex is the pain point. I don't want to have to read through pages of inscrutable error messages about overfull mboxes and then read dozens of contradictory stack overflow answers for outdated versions that only half-address the problem I'm having.

I think you are correct. I do everything personal in org-mode, but I switch to manual if the doc ends up being shared. Heck, I even elect to use google doc if I have at least one collaborator.

This for me is the biggest pain-point about Org Mode -- most of my colleagues won't touch it, so it's off to Google Docs we go....

I think that’s probably reasonable. Fortunately, AUCTEX mode works well for latex so the main loss is org’s document structure management and maybe syntax. I don’t know if there’s a way to get that in AUCTEX

I don't think Org-mode's export features are particularly great. I'm finding that when I do want to export something, it's sometimes easier to grab a parser in a language where I'm more comfortable rather than trying to mess around with Lisp and templates.

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

means that Org-mode ends up being more useful for me as a surrounding 'notebook' around my projects rather than as the core format I'm authoring everything in.

I've written a few hundred Org mode docs, and a doctoral thesis in LaTeX.

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.

I agree with this. I often write up notes in Org mode, but, after trying for a while to have all of my 'sources' in Org, I also came to the conclusion that for actual papers, it's far better just to write them directly in LaTeX (other than initial notes).

IMHO (15+ years of Emacs and counting) you are not 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'd never author a paper directly in latex. That would suck. I'd author in Pandoc markdown, convert to latex, and then add tables and whatever using latex around it. It's pretty painful IMO to write documents in latex vs markdown.

In that case you have a perfect example of starting with org-mode instead: Then you can already add tables and images and all the stuff and have much less finetuning to do:

- create draft in org - export to LaTeX - polish for publication

Plug: I've been working on a new LaTeX-editing minor mode to use in conjunction with auctex:

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 authored my PhD in org-mode, where the planning and re-structuring provided huge benefits. But for the shorter paper I just used LaTeX.

Oh I know the pain, I did the same back in 2015. That was my first scientific paper ever. Then "never again" said to myself. Now I use pure latex. org-mode is only good for quick exports should not think it as an alternative to latex.

Hi, also big fan of org-mode authoring, but how do you import/modify/use nice latex templates such as invoice or resume? https://www.latextemplates.com/template/invoice ?

It's not an exaggeration to say that org-mode changed my life. I started using it after my first year as a freelancer; I was really struggling to get myself organized and was prepping myself to get out of software entirely.

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.

Are you me? :) I use a very similar org table to calculate my nutrition, only with separate columns for macronutrients. I don't have an update function like yours, though.

  | -1 | req. | 100 | 100 |  50 |               
  |  3 | milk | 2.92| 4.37|  3.5|
  |  # |      |-91.2|-86.8|-39.5|             
  #+TBLFM: @>$3..$5=(@<$1..@>>$1)*(@<..@>>)

Org-mode is the reason I started using Emacs in the first place.

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.

For an Android client I just run it directly in a terminal emulator (Termux). Works well enough with the software keyboard (but a bluetooth keyboard brings real glory).

This was predictable. A software package shouldn't be in continous evolution. Org didn't really follow GNU philosophy. That's what commercial software like Microsoft Office does. They keep changing it without adding any value. Org should've been the opposite, future-proof, solid and robust.

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.

It appears that the OP, @bzg, is Bastien Guerry, the current maintainer of org-mode — Bravo Zulu, Bastien! (By a happy coincidence, "Bravo Zulu" or just "BZ" is a U.S. Navy expression for "well done," defined in the publication ATP-1. [0].)

[0] https://military.wikia.org/wiki/Bravo_Zulu

I did not know for the "BZ" expression! I like it.

Glad to find long-time power users here btw :)

Does bzflag have something to do with this term?

> Does bzflag have something to do with this term?

Not so far as I know.

BZflag, the tank game, is named after "Battle Zone", the original Atari tank game.

Ah - I have fond memories of that one, played on a machine that took quarters IIRC!

I'm a UI developer, never used Org-Mode, not a VIM or Emacs user. But I am very interested in document creation, note taking, organizing workflows. Please forgive the lack of background in this question but...

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?

See orgzly for Android, and there are some web implementations too.

Org mode is great because it does 2 things extremely well:

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.

> org-mode lets you use all of the other Emacs major and minor modes in your document - restricted to sections.

> 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?

It's bound to emacs because it is written in emacs-lisp. It's a large, sophisticated codebase that dates back almost 20 years. There is no way it could ever be ported to another language in its entirety: it is very tightly bound into the (also sophisticated) string manipulation APIs available in emacs lisp.

Technically it could be ported, but that port would require porting a major subset, if not all of emacs lisp as well. This is due to the fact that elisp closures are valid and often semantically critical arguments to src blocks. Defining the features that must be implemented to achieve a certain level of org-mode support and compatibility is something that definitely needs to be tackled in the future.

I think it would be great if the development of Org has moved to Gitlab or GitHub, i.e. simplified the contribution process.

Did you make that comment to the list?

Can you elaborate a bit more on how this would simplif the contribution process?

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.

There was a long thread on the topic in the emacs-dev mailing list not too long ago that generated a heated discussion of over half-a-thousand messages (where most of it was around "the proper way of sending patches"). I'm not trying to start another flamewar.

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.

"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."

Agreed. I hope https://sr.ht can help resisting this trend. I'm sure there are plenty of happy Git(Lab/Hub) users here but again, I'm not convinced these platforms would fit Org's needs.

Interesting, I did not expect to find fennel there!

I'm a beginner in elisp (and tbh in programming in general) but would like to help.

For me pull request model is much more natural than mailing lists and patches. It doesn't matter at all if its GitHub, GitLab or (my personal preference as it's lightweight, open source and easy to use) Gitea (interestingly it's not present in comparison on https://forgeperf.org). I don't even know how to make PR on sourcehut and can't find any tutorial.

Of course I will try to learn in order to help org but the entry barrier is much higher than for Git(Lab/Hub/ea).

EDIT: I just found orgmode code on Gogs here: https://code.orgmode.org/bzg/org-mode

That's great! I'll register and try to help soon! Mabye it should be more visible and linked in docs (I'll... make a PR I suppose? :)

You can still do pull requests over email.

Rather than attaching a patch, you simply send a link to your git repository (+branch if applicable), and the maintainer can pull from it.

We don't use code.orgmode.org for Org's development.

But please clone Org's repo, make a patch - perhaps with https://magit.vc - and attach it to an email you send to emacs-orgmode@gnu.org: that's all it takes.

Then we will help with polishing your contribution :)

Alright. Now, let's say everyone is busy, and the maintainers have no time to review the patch. Who's going to remember that someone sent an email with some improvements a few months later? AFAIK There's no easy way to find all the emails with patches that weren't merged/(not) accepted/upvoted/downvoted/closed/etc. It's not easy to refer to the specific email; it's difficult to pinpoint the exact conversation around a specific change using git-blame. GitHub/Gitlab/etc. make all that a lot simpler.

Reviewers possibly use org-mode to keep track of those things. Would be trivial if Emacs is their mail reader.

For those who are really taking advantage of org-agenda et al, I'd argue GitHub issue tracking UI is far more restrictive for tracking patches.

If I were in that position I'd be duplicating issues into org-mode anyway (or using an Emacs mode to interact with/sync them). Maybe that's the missing link?

Isn't org-mode part of emacs now? You don't require the FSF copyright assignment paperwork?

It looks like your bug tracker is a bunch of pointers into a mailing list. This means:

(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.

"I can't participate or reply on the web interface, I have to sign up for something completely different to participate"

Let me correct this one: no, you don't have to sign up to anything: (1) click on a bug entry on https://updates.orgmode.org then (2) click on "try the mailto: link" link.

This is other way around: if Org goes to GitLab, GitHub-only users will have to sign up to GitLab just to report an issue, and same for GitHub.

It's not about specific platform. It's about accepting PRs instead of patches.

I hope one day both worlds will reconcile.

After all, it should be possible to have PRs sent as patches over a mailing list (and we don't need manual patches to be published as PRs.)

I guess you may have a different viewpoint on this. But from my perspective, that's a context switch, I have to now load up my mail client and be subjected to whatever email arrived since I last opened it.

I also don't have "mailto:" hooked up to my actual email client, so that's extra steps for me to get that set up. (Blame me for this if you want to, but I'm guessing that there are probably more people like me in the world than there are people who have their email client set up to handle "mailto:" simply due to the fact that work is required to set it to anything other than the system default.)

The question is, what are you filtering for? There are always tradeoffs, and I hope I've demonstrated that the email-based interface is not "free" even for fairly savvy tech users. For less savvy tech users, I'd consider the situation even more difficult.

This is my approach:

- Copy email eddress - M-x mu4e - S-C C-y C-c RET f <select patch exported with magit>

I found just sending an email with my contribution to be a much smoother experience than filing a pull-request.

Also M-x org-submit-bug-report

> I don't personally think that Github makes PR formatting any harder

GitHub deliberately made GitHub-flavored Markdown incompatible with the way that Markdown dictated line breaks should be handled, although this affects more than just pull requests. In general, the way that people "write" Markdown meant to be published for GitHub is unreadable as plain text, even though it's supposed to be roughly as nice to read raw Markdown as it is to read the rendered form.

Many projects' commit logs are also a mess as a result of the way that GitHub pushed their pull-requests-for-everything model on the world. There is no end to the number of projects where every other log entry is a crufty merge commit, and the messages in those projects are generally useless, anyway. Folks shouldn't have to trawl through a disconnected web service to glean the info that should have been included in the commit message but was stuffed into the pull request instead.

> 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 have no horse in any Emacs race, but I agree that proper bugtrackers trump mailing lists. It's just a shame that so many people have consolidated around GitHub (and workalikes, like GitLab and Gogs/Gitea), which is poorly implemented. GitHub implements less-than-optimal workflows for its own reasons, and those reasons generally mirror other Valley-based "social" endeavors, where what's most important is growth, user engagement, and the perception of value at the expense of actual productivity and the adoption of addictive dark patterns to drive it all.

Second to the actual mechanics of GitHub is "the GitHub community", which routinely proves to be as much of a liability as an asset.

The fact that Emacs is a free software project and GitHub is not and GitHub is only slightly less of a walled garden than Facebook and that its privacy controls (what little it provides, if you want to even try to argue that it provides any) are worse than what Facebook and Twitter provide...

... are all reasons that make for a very bad suggestion to move to GitHub.

Other than the issues others have raised about mailing list vs. PRs from Git{Hub,Lab}, here is the information you need to send to the FSF in order to contribute >15LOC:

- [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.

Yeah, that's pretty stupid. Writing free and open-source code is not a privilege. It's a community service. Imagine if you decided to pick up some trash in your local park, and cops would stop you from doing that and ask you first to submit an official form, mail it to the city hall, wait for a few days for it to be reviewed and approved...

If you have never contributed to a properly managed GPL codebase, you might be surprised the kinds of things you will be asked to do. More it the point, it most certainly isn't a right that you can contribute however you want to whatever project you want. Projects have constraints. Some people can _never_ contribute to Emacs because of the other code bases they work on (e.g. Chez Scheme). If you happen to be one of the folks who can, then in a sense, it is a privilege that reflects your freedom from other constraints.

"Some people can _never_ contribute"... the emphasis is around "some". Going back to my hypothetical example of doing community service, sure some people should not be allowed to do that. Let's say there's a person with a criminal record for throwing garbage at people, or someone who is too old or disabled for that kind of work. But it is still quite enormously stupid to create tremendous bureaucratic obstacles for everyone, for the sake of protecting a few individuals or against the potential damage they may cause.

"Few" is a red herring; all it takes is one, and in Emacs's case it's more than hypothetical. They were forced to deal with the threat of the project being stalled due to Gosling/Unipress's stake in some code that was reused in the early days. After that, Stallman said never again.

And in general people people in the current era of open source seem to be sloppier/more reckless than before. Ever looked behind the scenes of Wikipedia (or heck, just perused YouTube)? You know how much plagiarism and copyright infringement is involved? Enough to worry about it. (And in the case of media uploaded to Wikipedia, people have to specifically declare that the work is theirs to license or otherwise is free content, but even with those barriers, there are people still willing to do things that jeopardize the project.) Even if only half a dozen people were ever deterred (and the numbers are certainly higher than that), then that alone would be worth it.

They don’t stop you. They just don’t take your proposal for a better sign at the entrance. Because they already had the experience of artists forbidding them to change the sign for copyright reasons (no, a yellow line around it so people with bad sight recognize it would violate my artistic vision).

Which is the better analogy than picking up trash, by the way.

With all due respect, I suggest you contrast the effort it takes to overcome these issues versus what it took to start the GNU operating system.

I can't speak for others, but I'm driven away from contributing to projects that use mailing lists because there's a high barrier to entry, and here's a source of other people having the same issue[1] to corroborate my anecdote a little.

[1]: https://www.theregister.com/2020/08/25/linux_kernel_email/

as discussed in previous threads, the person promoting this claim within the linux foundation is also a microsoft employee, and microsoft owns github.

so while it might represent some trend, it is also worthwhile to possibly consider editorial/selection bias as a factor for promoting the claim that this is significantly prohibitive

Yes, MSFT acquiring GitHub was like if the Pope, supreme pontiff of the Catholic Church has announced that they are taking control over CERN and promised it would remain an independent research organization.

What choice would all the scientists have in that case? They can't just say: "I'm leaving physics until someone else builds another LHC".

Until we have a better, more superior, free, open-source, public service that can do things better than GitHub, I'm afraid we'd have to play along.

But the point is not about GitHub vs. something else. It is about that Pull-Requests are preferred over mailing lists for open-source projects.

We do. Gitlab or Gitea are FOSS (the first one partially, the other fully I think).

And https://sr.ht.

Hehe :)

But you forget about Catholic Church dedication to Overall Truth that cannot contradict reality. Or you do not belive in it. I do. So, probably no point in discussing this, right ? ;)

In contrast to corporations dedication to them selves... Which just only on surface looks like cysnism on our part, sadly.

So, obviously MS takover over Github will end as soon as it will be convenient for MS.

But realy we have bigger problem on our hands: common ppl greed or just reluctance to pay (quite not much) for hosting of their own projects. Or paying anything for their privacy. This also is why FB already replaced home pages. And Discord (almoust overnight) TS.

We realy need to ad private git repos and own vpn's. For agents raiding servers locations should be enough.

I'm no defender of mailing lists as a substitute for real bugtrackers (I'm fairly strongly against it, actually), but GitHub is also apt to drive people away more than its fans admit.

https://news.ycombinator.com/item?id=24378401

There's also the matter of its privacy controls being extremely lacking. It's another site that takes the position that you don't get a choice on everything being "social" now, so they'll index your activity on a central timeline whether you ask for it or not and broadcast it to anyone else who does ask for it, leaving you with no recourse except to opt-out entirely.

I agree that Github is not the solution the open source community is looking for, and feel the pain of the lacking privacy controls. Still, I feel that development on Github is much more accessible than that on a mailing list, and there's probably a solution which would be more accessible but still encourage people who aren't part of the mailing list culture to contribute.

For example, mrsh has its development on sr.ht[1], but accepts pull requests on Github or the mailing list for the project[2]. This seems like (almost) the best of both worlds to me, where people who want to use a mailing list can, and people who want to use a GUI can, though there is overhead for the maintainers to fuse together the results at the end. An alternative like Gitea or GitLab might be better for your mentioned privacy concerns while still lowering the barrier to entry that a mailing list workflow presents.

Design is not my passion, so I'm drastically underqualified to comment on whether any of these websites is an effective implementation of their ideas.

[1]: https://git.sr.ht/~emersion/mrsh

[2]: https://git.sr.ht/~emersion/mrsh#contributing

Hi bzg, I'm an ex-org-mode contributor (we've worked together in the past!) and I do strongly agree that hosting development on GitHub or GitLab encourages people and reduces friction and is what all (yes) open source projects should do. I still write emacs-lisp packages for MELPA, but I absolutely hate the way that development of packages that have been folded into emacs is hidden behind opaque mailing-list based procedures, and apparently with little code review.

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.

Hi! Thanks for your feedback. I think the Org mailing list has a pretty good record of both useful and polite conversations.

I don't know if the tone of conversations is different on mailing lists vs. web UIs like issues, PRs or code reviews.

As I said in another reply, I guess we can somehow reconcile both worlds by allowing PRs to be sent as patches to a mailing list - I guess https://sr.ht could support something like this (if it does not already).

The thing with the whole "entry barrier" point of people who want Org-mode development to happen on Git(Lab|Hub) is that they miss the point: I don't want more contributions, I want more engaged contributors, more committed support of any kind.

I find emails to be more engaging than emojis on a web interface - and I use both on a daily basis, so perhaps I don't deserve my #okboomer yet :)

> The thing with the whole "entry barrier" point of people who want Org-mode development to happen on Git(Lab|Hub) is that they miss the point: I don't want more contributions, I want more engaged contributors, more committed support of any kind.

If you want more engaged contributors you need more occasional contributors. Some of them will grow into core contributors or co-maintainers. Putting more obstacles is not the way to filter the out less engaged and keep the committed one but way to discourage the potential valuable contributors. That is why being on github where practically all of the OSS is happening is important(even being is gitlab won't have the optimal effect).

> For example, the magit maintainer responded rudely, aggressively, and discouragingly to recent PRs against magit. Stallman's absurd one- or two- sentence replies.

I must reject that unfounded criticism. I looked at all PRs since May and the only one that I rejected without much of a justification is https://github.com/magit/magit/pull/4191. I have a hard time imagining how you justify going from that to your harsh choice of words.

Luckily feedback is overwhelmingly positive, but because I have a thin skin, harsh criticism still hurts me and at least temporarily makes me lose motivation.

> I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public.

I don't think it is common, but it does happen.

Hi tarsius, I should have said "a PR" singular. I'm sorry but I did find your reply to me in the tiny PR I submitted to be dismissive and unfriendly. I love magit and think your work is fantastic and I don't have any reason to justify extending from that anecdote to any generalization about your maintenance style. Sorry to subject you to an anonymous and undocumented public criticism but the fact is that it was an anecdote that was in my brain about my recent experiences with emacs development.

Off topic - but thank you so much for org mode!

Thanks! Also, this release is the work of... 94 contributors, I should have mentioned this in my post.

I wish Bram Moolenar could chime in on how hosting vim on GitHub has accelerated or promoted development for the editor.

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...

In my experience, moving to GitHub probably is a downgrade from a more sophisticated process in terms of functionality—but it somehow lowers the barrier to entry enough for new people to contribute noticeably more. I'm sure there's some interesting psychology there but I don't know enough to theorize; all I can do is relay my observations.

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.

I hope more project maintainers would call for help if it's needed. I am using org mode everyday, but I don't know org needs more contributors. That being said, I am definitely willing to help occasionally.

Thanks for bring the message out, bzg.

I’ve recently started to get back into emacs and org, via doom emacs. Will see how it goes.

How are people handling getting org files on multiple devices, with sync support etc. Dropbox?

I'm using synchronization via Nextcloud. It's nice, because of webdav, but Dropbox is as nice as this, because Orgzly supports both of them

I just wanted to come here to say that I started learning emacs in the beginning of the pandemic. I'm going to start my first year of masters and I'm going full on emacs. Literally one of my big wants in life is to help free software.. I still have a lot of learning to do to get to a point where I can actually contribute, but I hope one day I can indeed help

Where there is a will, there is a way. Don't hesitate to join Org's mailing list and lurk there for a while, you'll learn enough to contribute soon.

org mode for vim would be great

Magit for vim would be great

I'm not a vimmer but I was under the impression that both of them were ported

I don't know about vimagit, but vim's org-mode support is very barebones.

Give doom-emacs a try though. You really can have the best of both worlds nowadays.

Both Doom Emacs and Spacemacs (maybe others) default to vim keybindings. I don't use it, but from what I have read, the emulation is almost perfect, and you get all the Emacs features (including Org) as part of the deal.

Vim has Org-mode, but it is very "shallow", compared to Emacs one. What makes Org-mode (and Emacs in general) so great is Lisp. I believe it is Lisp that allowed some crazy text manipulations and other tricks that would be significantly more difficult to build and maintain in another environment, using a different (non-lispy) language.

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.

There is a Rust parser being worked on for Org that looks promising. It would definitely help adoption to have another complete implementation aside from the elisp source. https://github.com/org-rs/org-rs

evil mode in emacs and you can have both and more.

The Emacs news the past few days has been disheartening.

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 confirm it still makes sense.

I just want to make things easier for the futur Org maintainer by spending the next few months recruiting more contributors.

If you have been using Vim go ahead and try doom emacs. I tried breaking into emacs before and dismissed it two times because it was too weird. But when I tried doom which is designed to use Vim keybindings and be easy for vim users to take up I found it super easy and have been loving how powerful it is.

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.

I was an originalist on Emacs and totally agree. I tried Spacemacs and then doom and got to throw away 80% of the customizations I'd acquired over the years.

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.

What news did you see that was disheartening? The only story I was was that helm is being put to pasture, but that's very separate from Emacs itself.

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.

This is why I recommend spacemacs: just install the python layer, read its readme file, and get going. Emacs is like clay, but that’s only useful once you’re comfortable with it. Until then better to get an opinionated experience out of the box, and tweak it from there.

I love emacs but lately I’ve been feeling this approach is very much at odds with today’s expectation of per-project convention-flexibility within a dialect, a la prettier.

Truthfully, I feel kind of the same way. There are parts of my .emacs.d/init.el that go back 25 years, so I'm not saying this from the position of "I tried it last week and it wasn't like my other editors so I don't like it."

One of the things I love about VSCode, and that made me seriously evaluate it in the first place, is how easy it is to configure per-project settings like "use this virtualenv when editing these files". In VSCode, that looks like having one window per project and this works great. When I'm in the middle of working on one thing, I can quickly open a second window, hack on something, close that window, and get back to what I was doing. Since Emacs has one flat memory space, that's not nearly so easy.

I love Emacs and would go back to using it in a heartbeat if it were half so easy to set up and maintain a working Python development environment with all the bells and whistles, but so far I haven't found that to be the case.

Direnv and lsp-mode

Vim is a whole different thing. The popularity of vim is mostly the popularity of the vim way of editing text, regardless of environment. Emacs, on the other hand, is popular as an environment. Vim, or something with "vim" in its name, will remain popular as long as keyboards remain popular. Emacs can only live as long as the intersection of the set of people who are enthusiastic about natively-extensible editing/development environments and the set of people who are enthusiastic about lisp. It's not going to live on as a set of keybinds, that's for sure.

Please don't be disheartened. Like everything in life, software projects have natural cycles. People's free time waxes and wanes, and inspiration ebbs and flows.

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.

I have been emacs adjacent most of my career (I'm 50), but never really took to it until about 6 or 8 years ago. I was never a full-time Linux dev, for one thing. For another, I've spent my career about half in code or whatnot, and the other half in PowerPoint or Word communicating technical things to nontechnical people, and so lacked the long-term immersion I thought was really needed to GET emacs.

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.

Reply on news.ycombinator.com