Org mode is really awesome. A chemist basically does his work with org (http://kitchingroup.cheme.cmu.edu) and recently another guy showing his colleague’s poster done with org and Beamer ( http://irreal.org/blog/?p=7651). I find org and mu4e really make mundane stuff easily done. On a mac and iOS system to get email, calendar, to do list, and notes done, it is usually 4 different programs, with emacs it is just org and mu4e and beorg on mobile.

I'd love to find more examples of org mode used in the sciences! Any for molecular/cell biology type work?

There are a few examples here: https://orgmode.org/worg/org-papers.html

I'm not in that field, but I think you can take a look at org-ref for bibliography, org-babel for R and Matlab. For me org and emacs serve more as a note keeper. I think if you are in a wet lab, many things have to be done with specific programs, but if you don't own a bench, many things on commandline can use org to do.

My sole use of Emacs is for Org-Mode (for extensive note-taking, task breakdown, writing reports, etc). I'm glad I invested the time three years ago.

During the upcoming holidays, I should try to explore and "stumble upon" advanced features and neat tricks that I haven't come across yet.

Remember mode could be cool for your use case. It may be integrated into Org by now (?)

Thanks for the suggestion; never heard of it before. Not sure if it's integrated into Org itself; it looks like so. but the Remember Mode seems to have Org as one of its "backends"[1]. Reading the documentation ... section 7.5 (Saving to an Org Mode file) says:

"For instructions on how to integrate Remember with Org Mode, consult Capture"

Okay, let's go and read the documentation of Capture[2]; it says:

"Capture lets you quickly store notes with little interruption of your work flow. Org's method for capturing new items is heavily inspired by John Wiegley excellent remember.el package. Up to version 6.36, Org used a special setup for remember.el, then replaced it with org-remember.el. As of version 8.0, org-remember.el has been completely replaced by org-capture.el."

[1] https://www.gnu.org/software/emacs/manual/html_mono/remember...

[2] https://www.gnu.org/software/emacs/manual/html_mono/org.html...

How much time have you invested?

I second to have choose Emacs as a main computing environment and since I often here the question "how much time ..." well...

I'd like to add a note: time can't be only measured in hours, days, etc. To learn Emacs enough to decide that's the way I'd like to interact and use my desktop it take a very little time, in around three month I start using Emacs as WM (EXWM), MUA (notmuch-emacs) in around two months with a "false start" on Mu4e, main docs solution, tramp, personal finance (ledger) etc

But the real point is: I do it when I like to do, as much as I like, in my free time. In other words I can start easily and grow as I wont and need, and this knowledge will survive for decades to came.

With commercial software you need to invest time (and money) before start, and after having reached a certain amount of knowledge you can't go further, you have to keep yourself up to date following upstream changes and you new knowledge have a very little value in the long run.

That distinction is important because too many people say "hey it took too much time to proficiently use FOSS" completely ignoring the big picture. Good time to learn FOSS is at school, when you have plenty of time and (in theory) you are willing to learn, after you get the benefit for the lifetime. Another good time is when you feel the need, in free time. You do not have to pay something in advance, you do not have "training", "diplomas" etc, you grow at your speed and desire, limitless.

That's the real matter, not how many hours.

> With commercial software you need to invest time (and money) before start, and after having reached a certain amount of knowledge you can't go further, you have to keep yourself up to date following upstream changes and you new knowledge have a very little value in the long run.

How's that different from learning to how use FOSS? Except the money investment part.

That commercial software is build normally to lock you in and lock out any possible evolution path, the learning curve is fixed: when you learnt a certain number of things "you are productive" and there is no more, no future.

On FOSS normally software offer many evolution paths, which means you have to learn few thing and you can start, using the software issue or desire arise and you learn new things in an ever grown knowledge that regularly pay off. Also standard terminology is normally used, for instance you never find FOSS project to invent terms like "BIA" (Cisco name for MAC address of a nic, "burn-in address") or "Enable mode", "write terminal" and things like that.

That is certainly true for some FOSS, but not for all. Many FOSS seems to not differ much from their non-FOSS equivalents, ex. LibreOffice, Firefox, Blender, Eclipse.

Accidentally all software you cite are born as commercial product: LibreOffice's origins are StartOffice, originally developed by StarWriter and after acquired by SUN; it became a FOSS project when SUN understand it can't profit anymore from it due to Microsoft Office popularity. Firefox was born as a commercial product (Netscape, originally an AOL product) that mimic Mosaic, but does not use it's free code. Blender was born as an internal product of NeoGeo, after distributed as a shareware by another company NaN and only after nan bankruptcy as a FOSS product. Eclipse born as a commercial IBM IDE, successors of VisualAge Micro Edition...

Of course, there are "recent" FOSS project with a design that take inspiration from commercial products, simply because that's the way authors think/know even if the code is free, but original FOSS software are another story.

maybe for LO and FF, but I don't think that you can present yourself as a proficient blender or eclipse user if you don't write your own plug-ins

In the context of emacs, you only ever need to learn terminology like

- major and minor modes,

- special, regular, mini and read-only buffers,

- frames,

- backup files,

- dired,

- mark and kill rings,

- hooks,

- the difference between C-x and M-x,

- mode line,

- registers

- and whatever else there is in emacs' configs, packages etc.

I dunno. Perhaps in emacs lingo "standard" means "no one uses these terms anymore"?

That's not a real problem, if you call it "advanced statusbar" instead if minibuffer, split instead of windows, contents instead of buffer it's only a matter of name. And most of them are pretty intuitive.

Consider a thing: commercial always say "start with us is quick", and they do their best for that. Unfortunately they omit an important fact: start it's quick, if you already came from commercial environment witch is the most common case right now, but all the rest is a pain. And we normally start once in our life, but we have the entire life to live...

"no one but few do something" for me is not a bad thing per se, consider how many dictatorship exists around the world or in witch conditions most human live around the Earth: do you prefer being in the center of Gaussian which means being a poor man fighting for some bad food just to keep up in some dictatorship or you prefer western welfare and the least bit of democracy we have?

> That's not a real problem, if you call it "advanced statusbar" instead if minibuffer, split instead of windows, contents instead of buffer it's only a matter of name. And most of them are pretty intuitive.

vs.

> Also standard terminology is normally used, for instance you never find FOSS project to invent terms like "BIA" (Cisco name for MAC address of a nic, "burn-in address") or "Enable mode", "write terminal" and things like that.

This is called hipocrisy.

There's nothing "intuitive" about emacs terminology.

> This is called hipocrisy. IMO it's simply a way to lock users in, like Cisco, like Oracle, like OpenBravo, like any other vendor try to do. Emacs simply was born many years ago, and kept going since that, why change terminology just to ease the newcomers make unhappy actual users?

> There's nothing "intuitive" about emacs terminology. And so what? Emacs is an OS not a small single-purpose apps, did you expect to being able to learn it an a day clicking around? In my personal experience, as a hardcore vimmer for more than a decade, as someone who have used different OSes (casually born on Irix thanks to a present by a family friend, evolved on FreeBSD, RH/Fedora/Debian/Gentoo, Solaris, OpenSolaris, Ubuntu/NixOS) I have seen anywhere "non intuitive" terminology, and I'm still there...

What about slices instead of partition? What about /dev/ notation in various unices? What about pfexec vs su vs sudo vs pkexec vs ...?

Chad Fowler's "professional services barrier" label https://books.google.ie/books?id=ig9QDwAAQBAJ&pg=PT48&lpg=PT... is a fair stab at explaining some of the difference. Which isn't to say that the distinction is really black and white, especially for non-programmers or people who don't have a lot of time to invest in a particular kind of tool.

I used emacs for years to write code and latex documents only knowing the commands to open and close files, copy/paste, and quit. I started with emacs in lieu of vim because I think modal editing is an insane and clunky solution to a problem that no longer exists.

The documentation isn't really very good due to the arcane terminology that often contradicts modern de facto standards in naming things (frames, buffers, windows) so that's a real barrier.

Plus the ecosystem is full of half-baked treatises on the One True Way to set up your init file that don't really explain why they made their choices.

But you can easily get by in emacs with just the basics. Then you just add commands to your repertoire when you're ready.

my emacs config is init.el having

(require 'package)

(setq package-enable-at-startup nil)

(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)

(package-initialize)

;; Bootstrap `use-package'

(unless (package-installed-p 'use-package)

(package-refresh-contents)

(package-install 'use-package))

(org-babel-load-file (expand-file-name "~/.emacs.d/myinit.org"))

then you can put your configs in an org file. using `use-package` means I can just copy/paste the file to new emacs and all my packages are auto installed etc..

#+BEGIN_SRC emacs-lisp

(use-package command-log-mode

   :ensure t)  

 #+END_SRC  

also, i highly recommend package `which-key` - it displays what commands are available along with their keypress.

Relatively little really. Probably the biggest individual customisation I have made is using Poet Theme (and its recommendations) to provide a good-looking GUI setup: https://github.com/kunalb/poet

I also have a basic (text only) init.el for when solely working in a Terminal environment.

My advice would be to perhaps start with just what is recommended to use Poet theme and then add what you need when you need it.

I've invested quite a bit of time into emacs, and while I do sometimes get frustrated at how the whole thing comes apart at the seams, I'm quite happy with it.

The way I see it, most time invested is not lost because emacs will probably be a part of my workflow for most of my life. I just got tired of getting proficient in yet another tool/editor, setting up various plugins and configs, only to have to do it all over again a few years later.

That said, I can see myself using other tools like VSCode when they're more appropriate.

Hard to say. I was a multi-year vim user. After converting to evil (vim mode for emacs), so I don't count that. I have spent at least 3 or so weekends tweaking things.

Every three months I spend a couple of hours thinking about what works and doesn't and going through my .emacs.d to make it better.

Basically, constant attention with heavy upfront costs.

Not OP. But if you are asking whether it is not possible for a person to just sit down and start typing, surely time spent to get such great results is an investment.

I've invested lots of time, but it's enjoyable. It's not work.

Emacs is an OS that lacks a decent text editor (the joke is as old as Emacs).

Well... For me it also have a decent text editor... The bad point is that it lack a bootloader+kernel+userland that let me ditch basic Linux kernel...

GuixSD is nicely integrated but Emacs Guile port is not "official" and "mature" enough to have it really as a sole OS, also GuixSD use bash by default, not Emacs at login...

For now I'm happy enough with NixOS+EXWM despite few annoyance not directly caused by Emacs :-)

Would you mind sharing your nix config?

Since I plan to re-write it in org and cleanup I do not publish it however here http://ix.io/1vf0 there is a quick redacted NixOS config of my desktop :-)

When I have time I will port both NixOS, homeManager and Emacs config in org, with proper docs. But I do not know when I will do that...

Not funny. Evil mode was released in 2013.

I tried Evil mode a few months ago and went back to Vim very quickly. It's one of the best Vim plugins out there, but it still misses a few features and it also behaves differently in a couple of situations.

It never really feels like Vim, more like a minefield of unknown shortcuts with a layer of Vim bindings on top. But I get why some people like it, if you can't stand modal editing then Emacs is a great choice.

One of the selling points of neovim was to make it more easily embedded into other programs.. doesn’t seem like anyones trying to do so from a quick googling though; maybe one day there can be true unification of the holy editors

I suspect this is quite unlikely. A main reason for emacs being good is that it has a good programming language for extensions and good primitives to support it. This is in comparison to eg vimscript (hopelessly bad) and javascript (extremely mediocre). Emacs Lisp has several advantages:

1. Language is more extensible because of macros so dealing with editor state can be hidden.

2. Language is more dynamic with advice and eval-after-load and such is extensions can play well together

3. For all it’s difficulties, having buffer-local variables and dynamic scope seems to make writing extensions easier

As far as I can tell, making Emacs cooperate with neovim would require shoehorning the editor model of one editor into that of the other, likely causing many extensions and expected behaviours to break.

There is, I think, a difference between making a new application that can use neovim for editing some bits and making an old (or, indeed, very old) application switch to using neovim for editing.

NeoVim supports Lua as well.

Could you elaborate on some of the specific features that Evil was missing? Aside from a couple of exceptions, any differences from Vim are considered bugs.

Most of the differences I noticed revolved around automatically changing indentation levels(one of the best ways to get uninstalled) and autocompletion which sometimes didn't work(file name completion) and once it refused to autocomplete a certain string without removing the underscores first.

I'm sure a lot of this can be fixed by changing some configuration options, but I don't see a reason to change the editor just for the sake of it. Emacs is awesome in some ways, but it's not my cup of tea.

There is no reasonable way to emulate always on

    :set virtualedit=all

Picture mode is not reasonable. The cursor must go where I put it and stay there, not move in any direction I did not choose.

spacemacs.

That's much more recent than I expected

There were other vi emulation modes before that. Vile was one. I believe evil is much better, though (I never used vi emulation before evil so I have no firsthand experience here).

It's about the time hipsters started to take an interest in vim so not too surprising.

I realize this is a joke, but there seem to be a lot of people who are really attached to the interpretation of Emacs as a little Lisp Machine.

Emacs is an ok lisp machine. It is much better than many common lisp distributions which are typically not very good lisp machines (I believe the proprietary systems are better in this regard).

Clinging on to Emacs as a lisp machine can mean clinging onto the more dynamic customisable extensible computation environment epitomised by the lisp machine, and in this sense I think it is more understandable

> Emacs is an ok lisp machine

GNU Emacs is an extensible text editor, but not a Lisp Machine. A Lisp machine is a computer with a Lisp OS on the metal. This means the OS itself is written in Lisp and not just some specialized application, interfacing to a foreign underlying OS. A Lisp OS has also an open GUI and not just an editor-buffer-based UI.

With GNU Emacs the extensibility ends when one calls an OS tool or an OS library - for a Lisp Machine there is no such distinction.

GNU Emacs is a mostly single-threaded editor, with a horrible user interface and heroic efforts from users to deal with thousands of modes and keystroke combinations.

None of the extensible Lisp applications are 'Lisp Machines': not Autocad, not Audacity, not iCAD, not Creo Elements, not GNU Emacs, not OpusModus, not Macsyma, ... They are Lisp applications which expose a development interface and a development environment (yes, Autocad has Lisp development tools) and users are writing complex applications on top of those.

On a real Lisp Machine, an Emacs-like text editor is just one application and one interface style.

Emacs should just embrace it and make a distro.

Call it "Emix"

As a long-term emacs user, I obviously disagree, but it is a good joke. ;-)

I used org-mode for a bit, but it got really cluttered. Now I have a KISS setup with 3 quick keyboard macros and standard Emacs. Benefit is I can instantiate this system in any Emacs in about 5 minutes.