Seconded. ag is amazing on its own, but really shines in emacs since all the results have hyperlinks to their files/line numbers.

I've been pretty happy with Orgzly on Android, but that's probably because I don't want that much from it. I don't really like typing more than a sentence or two at a time on a phone, so I never expected to do any serious editing of Org mode files on a phone. What I do want, and feel Orgzly adequately provides, is the ability to read my Org files, mark things as DONE or put check marks in checklists, and capture one sentence notes that I later fill out and refile, once I'm sitting in front of a real keyboard.

Check out orgzly: http://www.orgzly.com/

I don't think phones are good for note-taking. There's even evidence that they may harm cognitive functioning.[1] It seems like it would be more productive to carry around a small pad of paper and transfer the paper notes to Org Mode later.

[1] https://news.utexas.edu/2017/06/26/the-mere-presence-of-your...

For iOS (which I realize isn't answering the parent but just putting this out there), there's now beorg, which is pretty good.

https://itunes.apple.com/app/id1238649962

> without decent mobile support or multi-master syncing, it's hard to adopt it as my main productivity tool.

I find that for a true productivity tool, I'm fine relying on my desktop & laptop. I'm actually dialling back what I use my phone for, simply because I can't trust either of the major mobile OSes to respect me & my privacy. It would be awesome to have all of org available on a phone though; you're not wrong at all there.

I would kill for an emacs which makes sense on mobile, but I've not given enough thought to it to imagine what would make sense. Emacs without the key chords would be still powerful but also odd.

I use dropbox for multi-master syncing. Seems to work ok. Emacs even has some file locking stuff that seems to help prevent me from clobbering changes I've made on another machine

I don't have side by side comparison, but I'm adept at command line and I still use Magit even when I have command line or other IDE available.

Magit is my go to tool, I only use command line to quickly switch branches sometimes or for non-standard things.

Things I love about Magit:

- CHUNKING .. staging chunks or unstaging chunks is so easy (my favorite feature)

- General overview of information

- diffs, rebases, etc

- It's really fast when you learn the key chords

Other thing I use for Git:

- Command line (if I'm in command line and need to change a branch, might as well do it there)

- Tig (Log is fine in Magit too, just old habbits)

It’s mainly that things happen in a couple of key presses instead of a few typed words.

For example to stage things you can just tap ‘s’ while running your cursor down a list of changed lines/files. To commit, it’s just ‘c c’, and you’re in an editor, in a markdown-like mode, with hard wrapping lines at a good default.

Amending previous commits is also very easy, and there are some quality of life abstractions involving branches which I’ve found very useful.

But, ultimately, it’s all the same stuff. If you have a good system with Gitx at the moment (and not much of an interest in Emacs), I wouldn’t worry about it.

I'll second the chunking feature. Magit is very good at staging and unstaging files and PARTS of a file. I don't know any good way of doing this on the command line.

I doubt there's anything actually wrong with the HTML that Org produces that would keep you from putting it in a blog, but you can certainly configure things to your liking. At the very least you can easily modify the HTML preamble and postamble, the javascript script tags and the CSS in style tags that Org's HTML export produces. All of those are just strings stored in variables that you can customize: org-html-preamble, org-html-postamble, org-html-scripts and org-html-style-default. There's more stuff you can configure by just reassigning some variable, see the file ox-html.el.

If tweaking those is not enough for you, you can write your own HTML export. You wouldn't have to parse Org syntax: you'd receive the Org markup already parsed into a nested list structure. If you don't use many Org features, writing an Org backend that supports only those probably isn't that much work. And you'd have ox-html.el to base your own backend on.

Are you kidding!? This is Emacs! You can tell it exactly how to do everything. Just advise/redefine the relevant functions. ;) The documentation of ox and publish does not cover everything, but when in doubt, just ask Emacs what code it runs when you do the thing you want to modify.

On my site (https://two-wrongs.com/) there is very little left of the original HTML. I'll see tomorrow if I can dig up the Lisp code I wrote for it.

Custom css is supported for html export, from the docs at (https://orgmode.org/manual/CSS-support.html) --

The HTML export back-end includes a compact default style in each exported HTML file. To override the default style with another style, use these keywords in the Org file. They will replace the global defaults the HTML exporter uses.

#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="style1.css" /> #+HTML_HEAD_EXTRA: <link rel="alternate stylesheet" type="text/css" href="style2.css" />

To just turn off the default style, customize org-html-head-include-default-style variable, or use this option line in the Org file.

#+OPTIONS: html-style:nil

I've been looking for a similar solution - albeit not for HTML - but haven't found anything convincing so far. My train of thought was: It'd be great to have a a canonical XML format for org files to export to, since after that, you could essentially write XSLT transforms for almost any target format (even back to org-files to go full circle). In my case, that e.g. would be odt-files with branding for the organization I'm taking minutes for.

After a bit of googling, I also found an email[1] on the mailing list asking for more or less exactly that, but things don't seem to have gotten far.

I've been thinking about adapting the existing HTML export for such an XML format, but I really haven't had the time for it. :-/

[1]: https://lists.gnu.org/archive/html/emacs-orgmode/2009-08/msg...

Tooting my own horn, if you love living in Org mode, and are willing to try out Hugo (https://gohugo.io), I have an Org exporter package ox-hugo that exports to Markdown + required front-matter for Hugo. The package is even more magic if you choose to use a single Org file to export to multiple posts/pages.

Few examples:

1. ox-hugo documentation site from one file[1], source[2]

2. My blog[3]

3. ox-hugo test site (300+ test pages and counting)[4]

[1]: https://ox-hugo.scripter.co/ [2]: https://github.com/kaushalmodi/ox-hugo/raw/master/doc/ox-hug... [3]: https://scripter.co/ [4]: https://ox-hugo.scripter.co/test/

I've been blogging with org-publish for a while, but I switched to a Ruby script instead [1]. I'd not recommend using org-publish for this, because it's slow, and it's hard to add new posts. It's nice for static projects (say like a bunch of PDFs or some documentation maybe), but it does not lend itself to a more dynamic thing like a blog (dynamic in the sense that you want to add new pages rather frequently). Applying a custom HTML template is difficult, it means you need to either implement many org-export functions or use HTML_HEAD settings and a stylesheet to tame org's output. I say this as a happy everyday user of Org mode, both for word processing and any sort of notes, and my entire agenda and todo-lists and stuff.

The JS is for interacting with tables, if I'm not wrong.

[1] https://www.gkayaalp.com/blog/20180221_siteremake.html

There are, but I never explored them. I use Pelican, and although it doesn't support org files, it's easy to write a plugin to add your own formats. Behind the scene, I think I use pandoc to convert from org to rst, which Pelican does support.

Yes, this came up on /r/emacs recently, see[1] (you can control if you want the HTML preamble and/or postamble).

[1]: https://www.reddit.com/r/emacs/comments/809xwx/how_to_get_pl...

For the most part, just styling what it does isn't that tough. Similarly, you can tell it to spit out raw html for some fun. http://taeric.github.io/cube-permutations-1.html shows some silliness I did recently that includes styling up portions of the page.

Do you want to do something much more complicated/simple than this?

Not exactly what you're asking for but I got great results with org-page[0]. It might be worth taking a look.

[0]: https://github.com/kelvinh/org-page

Not the ideal solution, but you can always use pandoc to convert org to html, or even markdown and configure the html generation from there.

I know you can define CSS for how you want your export to look.

That won't be much of a problem anymore once Emacs 26.1 is released. Meanwhile you can use the latest release candidate - those usually are very solid. For more information see https://magit.vc/manual/magit/MacOS-Performance.html.

M-x profiler-start

M-x magit

M-x profiler-report

You can accomplish a surprising amount of optimisation after seeing what it is that takes time.

How slow is ungodly slow to you? It's pretty slow on Firefox's code base but that repo is huge. For most things it's not lightning fast but definitely not ungodly slow.

Are you using stock magit? I think a few of the GitHub integration plugins for example have performance issues, so it may not be Magit's fault but some of the other extension you're using.

Yes it is atypical. Have you tried looking through the github issues on the subject? There seem to be a number of possibilities, depending on your environment.

I'd recommend mu4e [https://www.djcbsoftware.nl/code/mu/mu4e.html] for email. I used it for a number of years; switched to gnus for a year, and then ended up back on mu4e.

IMHO Notmuch is easier and much simpler for most email workflows.

Thanks. I've tried that in the past. The problem is still that it doesn't give any feedback on progress.

I still struggle to see how people actually use this with devops on a day to day basis.

I think that some type of integration with tmux would work well - have a running tmux session, and then just queue commands from emacs to that session, instead of running directly through emacs.

FWIW, Jupyter notebooks also have a kernel to support shell commands.

I’ve started to use Jupyter notebooks, with devop recipes as different sections, for this.

You can keep the notebook in the repo if you do two (or three) things:

1. The scripts read passwords from a key store instead of the notebook source. I wrote a Python package for doing this easily in Python cells; for bash, I just use subcommands.

2. A git pre-commit hook clears the notebook output cells.

3. (Optional) A git pre-commit or pre-push hook searches for text that looks like private credentials.

> "That is literate programming, is closer to a jupyter notebook than to 'comments on scripts'."

Surely that's a matter of perspective? Imagine you have a text document containing one command and one description of that command. Is this a literate programming document or not?

Furthermore, does the mode change depending on which tool is used to open the source file? For example, if I open a Bash script in a text editor then it's a document, and if I open it in Bash then it's a script, but if I could open it in a tool that allows me to both read and execute the script at my leisure does it then become a literate programming document?

Aside from this, to use your Jupyter notebook example, is it necessary for the results of execution to be captured in-line in order to follow the literate programming methodology?

I think you can run python inline in vim. But I obviously vim doesn't really have something as full-featured as Org mode. I mean, there's vimwiki - and you could probably get a majority of the rest of the features through messing around with plugins. But at that point, you may as well just switch to spacemacs.

Personally, if I was going to give Vim a try again I'd use Oni:

https://github.com/onivim/oni