Can I just say that I appreciate this trend of the last few years where opensource projects and organizations start collecting real data on who their users are and how they interact with them?
I see it a lot in the Clojure community as well, as with various other communities (such as Emacs). Not only does it provide the people behind the projects better guidance, it also gives me a better idea how my own usage and opinions relate to the wider community.
Having said that, one thing I found remarkable from the results of this survey is the proficiency in ELISP. A sizable fraction of the respondents feel proficient enough to write their own packages, a trait which I have yet to find someone in real life for (and I know more than a dozen emacs users). I can’t help but think there must be quite some selection bias going on in the respondents of this survey. :)
+1 to this. I have literally never published a package for emacs, but my init.el could theoretically be one, if I thought anybody else would care or find it useful.
I think writing in lisp is a sort of an acquired taste.
Its sort of like learning to drink coffee black.
Sorry if this is a heretical thing to say, but I think if there was a python-based emacs that people might be adding more extensive capabilities. I know I would.
> start collecting real data on who their users are
This is a survey of r/emacs. There isn't a strong reason to believe this is reflective of Emacs' actual user base. Who are these people who feel a need to participate in a community based on their text editor? That religion stuff was normally meant as a joke.
> Who are these people who feel a need to participate in a community based on their text editor?
Eh, guilty as charged. Why do people participate in a community based on anything? Because they are passionate about it.
There are detailed communities for every single thing you can think of. People collect matchboxes. There are people who make detailed paintings using Microsoft Excel. Why should Emacs be an exception?
And if a survey takes into account people who are passionate about their editor, that's good. Who should it take into account, the people who aren't? That's how you get operating systems that spy upon you all the time and optimize for some silly metric.
> That religion stuff was normally meant as a joke.
Just because someone makes a joke about it does not mean there cannot be an actual community of grown-ups who treat each other with respect around it. And the Emacs community I have seen so far is very respectful and welcoming, even for things like evil-mode that unify emacs and vi editing paradigms.
I encourage everyone who uses emacs or is interested in it to check out r/emacs and associated communities.
> Who are these people who feel a need to participate in a community based on their text editor?
as a non-religious, fairly pragmatic emacs user I did because getting into emacs was difficult and they've got a lot of good resources. It's quite a huge and idiosyncratic piece of software I wouldn't be surprised if people like I did just use it as a general helpful resource.
In the first place all communitys around a specific software are about solving technical probles and discussing usage of this software.
Second: emacs is not an editor, it's a platform with text as it's primary interface. It's similar to webbrowsers. So by it's nature there are many usage cases and technical problems to discuss with emacs. Thus, the community us quite vibrant for it's small size.
Third: Religion will always be where people gather long enough.
Emacs is a very, very deep rabbit-hole. I'm not sure that it would make sense to not find and get together with other Emacs users to compare notes, exchange tips, and swap stories with.
When you stop to consider that back in the 80s and 90s, many pieces of software -- frickin' WordStar -- had their own user groups, even without benefit of the internet to connect them all, what else would you expect?
While your comment on biases is correct, “sloppy” is a bit harsh; I would think of this as a best-effort attempt to reach out to the community through known popular channels.
I’m sure there are tons of Emacs users who go about their work without a fuss who aren’t aware of doom-Emacs and don’t care about Emacs communities, so it’s hard to make a survey representative of “all” Emacs users. C’est la vie.
Why do you consider the survey design "sloppy"? E.g., doom-emacs is a well-known emacs distribution; there nothing weird if 18% of survey respondents use it.
Whether the survey respondents are a representative sample of the general emacs population is a different question, and one which is very hard to answer given that we have no other data about people's preferences in emacs. Hopefully, the survey will become more popular with time, so we'll see results approaching the "true" values.
That's exactly what I mean by "sloppy" - it's not clear what question this thing answers, because the question wasn't carefully written down ahead of time, so there is no way to really generalize anything here.
Because different response methods are pooled together in results without any reweighting, it's not clear how much bias has been introduced vs a hypothetical global emacs population measure.
What conclusions do you think you can draw from this? I don't know how to draw any that aren't hedged heavily. 18% for doom seems much higher than I expected - is that because I underestimate it, or because of how the survey was conducted? There's no way to tell, here.
Good survey design _does_ exist; it's an extremely intensely studied practice. It's not surprising that a casual internet survey doesn't follow anything resembling modern surveying techniques, but it does make results unclear.
Org mode is one of the reasons to use Emacs.... it is an amazing outliner and note taker. It’s quite plausible to me. I use Org mode every day of my life for over a decade.I don’t visit /r/Emacs though :)
Frankly, I'm not sure how the survey design could have been improved. You can interpret the results as is. The data collector is not trying to generalize to the population of all Emacs users.
That surprised me a bit too but then if I change the question a bit it might be a bit more plausible. How many users has searched for an emacs related question in the last one year and clicked on a search hit for a reddit thread in r/emacs? Considering that, 80% might not be that strange.
Very impressed by the proportion of people who primarily use daemon/emacsclient. (I don't, but I always sort of think I should)
Surprised, and if I'm honest a little distressed, to see about a third of respondents use vi keybindings.
Absolutely amazed that so many people report using org-mode daily. Either the whole survey is primarily a survey of org-mode users, rather than Emacs users in general, perhaps because of the HN posting (I get the impression HN loves org-mode) - or nobody else uses Emacs.
Even more amazed about the questions on "completion frameworks" and packages for error checking (what?) in both of which the winning answer is something I've never heard of. I shall have to see what they're all about.
Finally - oh blimey, everyone reads /r/emacs. Perhaps that explains it all.
I'm inferring that you, like me, are a longtime emacs user with some inertia.
I used to not use daemon/emacsclient until it got annoying to have multiple emacs windows popping up, then I switched. Nothing to be impressed about it; even lazy ones like me eventually get there.
I'm also surprised about the vi keybindings, but not at all distressed. If there are a lot of people out there who are accustomed to vi keybindings but found reasons to want to use emacs, that's a good thing.
I don't use org-mode daily, but I do edit my todo list daily. If it ever gets deeply nested I'll switch it over to org mode. And I suspect that's what all the people using org-mode daily are doing -- todo/idea lists.
I should start reading /r/emacs every few years to catch up on new things.
I've used Emacs for over 20 years and I have been meaning to switch to vi keybindings for a while (but haven't yet :). I just find myself executing long commands with only 4 of my fingers engaged, because one of them is holding a modifier key, and it's somewhat uncomfortable. Not injury-causing uncomfortable, but enough to make me think "hey, I think the other team got this right." I would not mind switching between command and insert modes; I can keep the state in my head instead of in my finger.
The barrier to switching, for me, is that the vi-like modes are set up by default to have vi-like keybindings, and I just don't care to go in and change them all to Emacs-alike keys, and I worry how flexible other software with "vi mode" will be about that. I am past the point where I'm going to use hjkl to move the cursor around, I use npfb. I can easily change the details in Emacs/Viper, but then how am I going to use anything else, like the shell? That is my main worry.
I'm a light weight emacs user (mostly for org mode). I'm forever grateful to the dev I worked with who introduced and encouraged me to learn the vi bindings.
Exactly - with inertia, or maybe oblivious. I think it's just a little discombobulating to read about a program I spend so much time using myself being used in ways quite far away from what I know about.
That's a good thing I'm sure; it makes sense that a super-configurable extensible application should be super-configured and extended. But it's a little odd to imagine, perhaps, saying "oh this is Emacs? great" and then finding that you don't actually know how to work it.
I started using daemon/emacsclient several years ago and never looked back. Especially since I use named servers per project or language or whatever. Like, I have an erc emacs daemon that just handles IRC stuffs. I have one for (this month) aoc (Advent of Code). I have a ledger one for tracking my money. And then one for any other active projects. And if I want to kill the displayed instances (say I'm done with project X for this week), I can without "losing my place", all the buffers stay open (which is fine for the way I interact with files, just make sure to save).
I made a couple shell functions/aliases to help me out. emacsd $servername and e for emacsclient -t. So spinning them up is trivial, and accessing them is just e -s $servername. With no name, it's just the default instance (used for random editing that's not part of a project or something I care to keep cleanly separated).
For years I specifically used a separate emacs daemon for ERC because I don't really know how to perfectly cleanly update a given package in a running emacs in-place, and I wanted to keep my IRC uptime (and I'm not using a bouncer for some reason). So I would just leave ERC running in a daemon for the machine's entire uptime without ever updating any of its packages.
This is giving me nostalgia for when I used to use bitlbee + libpurple and have all my chat+irc in a single client (ERC). Good times.
Org is quite unique. I use it daily, and I would feel a bit less anxious if the language was standardized as this would facilitate alternative implementations outside Emacs. Right now, the implementation is the standard and that is a bit messy.
I don't know about any other language that combines a plain text outliner, keywords, tags, timestamps, hyperlinks and tables. These are exceptionally good primitives to implement a myriad of workflows. And I've left out some incredible features I do not use, like literate programming.
Applications like Things or OmniFocus are nice, but they can't adapt to alternative workflows. OmniOutliner was pretty great, though, and motivated some Org features during the GTD craze of late 2000s.
I think what makes Org special—just like Emacs—is that it's a small system that can grow. You can customize it however you like, and it's easy to add functionality on top of (or into) the core system. In practice, would standardization hinder this property? It seems like the cost of evolving org-mode would become much higher if there were a formal standard and a number of actively used implementations—we'd have to worry about backwards compatibility, inconsistencies between systems... etc.
As it happens, I absolutely would love better support for org-mode workflows in other systems, especially on mobile. (I use Orgzly on Android which is fine but also limited and inflexible.) I could also see a native org-mode implementation making core operations much faster, although the EmacsGCC work is making a real improvement on that front already.
But I worry that supporting that would sacrifice the very properties that let org-mode evolve into what it is and to continue evolving even now.
I was one of the ones that reported using org-mode daily. I had to think a bit about that at first. I don't use it any hard core fashion as an organizer or for task management or anything. But it has supplanted Markdown and RST as my go-to for lightweight markup. Whenever I would have previously started a .txt, .rst, or .md buffer to jot some quick notes down, I now find myself creating a new .org buffer instead. So on reflection I would have to say that I use it nearly daily, even if in a basic and ad-hoc way.
Using Emacs and using org-mode daily is like using an IDE and using code navigation daily, or like using Gimp or Photoshop and using quick mask mode daily, or using MS Word and using the style system daily, etc.
It's one of the best parts, it's built-in, using it is one of the reasons you chose that software at all.
Is this an earnest question? No, I didn't understand, when I was reading the article, what an error checking framework was for. What sort of errors? Errors in what?
Of course I've since looked up flycheck - it's for syntax checking code as you type it.
I thought "error checking" was one of the most important & popular inventions of the 21 century in developer experience and so there is no way someone in 2020 does not automatically associate that term with what it stands for in other editors.
Maybe this is a good opportunity to ask some related questions. I'm a Vim (now Neovim) user for most of my life but I'm finally interested in trying org-mode.
1. What's the best way to get Emacs on Mac? I heard that [1] is not a good solution, but I don't know why that is. So far I've used the d12frosted emacs-plus brew tap.
2. Further, does anyone have any resources for learning org-mode using Evil mode? I have Doom installed and it seems to use Evil by default.
I've never heard that about [1], and would be interested in hearing people's reasons as well. I've used it for many years now and have had few problems. The only other version I've used is Mitsuharu Yamamoto's emacs-mac (https://bitbucket.org/mituharu/emacs-mac/src/master/). For my use case (except for tasks requiring a web browser, I spend almost all my time in Emacs, but I don't use many gui features) the two are essentially equivalent.
I tried emacsformacosx and Yamamoto's port when I first started using Emacs on Mac OS, but since version 25 I've found the standard distribution compiled with --with-ns serves my purposes just fine. (I always build my own since I've found neither X toolkits nor distro packagers to reliably produce a stable Emacs, but if you're thinking about Yamamoto's port, building your own is already on the table. Besides, it's not any harder than building any other software, it just takes a while.)
I use emacsforosx and am perfectly happy with it. Seriously man, don’t worry about it just go for it. If you find out that you really need something that doesn’t have then you can always compile yourself. It’ll be trivial to transfer your set up, so don’t succumb to analysis paralysis.
I've had the most success with emacs-plus [1]. It's the most optimized for mac specifically with some good flags that you can make a custom build if there are features you do or don't want.
The best emacs for Macs might be Aquamacs (https://aquamacs.org/) as it has been adapted to work with standard Mac keyboard shortcuts among other things. I use it on a daily basis, not the least for keeping notes and clips in org-mode (of course ;-)
Another vim user here. I haven't decided to switch, but I've been thinking about it for a while. Like many others, I wouldn't be switching from vim, which is just my text editor, but from from an assortment of CLI tools that make up my "IDE" (perhaps just "DE" would be more accurate).
In theory, I don't like the idea of my text editor being my OS; I prefer the unix philosophy for tools, which interoperate via standards and are widely portable.
But, having recently attempted to write a bunch of posix-compliant shell scripts... I think practically emacs might just be a better OS. Particularly in the sense of everything being more uniform.
For 1, I generally recommend whatever Doom is recommending[0], which is currently the tap you mentioned.
For 2, evil is indeed available by default in Doom and works normally with org-mode. For the most part, everything works just like in vim, including splitting panes (windows in emacs), switching tabs if you've enabled them, and so on. So, writing notes in org-mode should essentially be just like writing nodes in any other editor with vim keybindings. You've also got by default nice stuff corresponding to some of the popular vim plugins, including vim-surround and commenting (via `g c <motion>` or selecting a range and then `g c`). There was also this post I saw recently exploring `evil-snipe`, `evil-easymotion`, and a few other plugins available by default that was quite helpful[1]. There are also a number of useful org-mode specific functions available when you're editing an org file behind the "local leader" `spc m`, like ticking off checkboxes (`spc m x`), storing links (`spc m n`) inserting links (`spc m l`), toggling todos, setting priority, scheduling dates, and so on. `TAB` cycles folding of headlines, `shift+TAB` cycles headlines throughout the document.
In general, one of the nicest things about emacs is the ability to introspect everything at runtime. `spc h v` allows you to search for, check (and change) the value of any variable, and you can often do some exploration in the fuzzy finder to figure out what settings are available for whatever editor feature you're using. `spc h k` lets you type a keybinding and gives you the documentation for whatever function it's mapped to. `spc :` or `M-x` opens up a fuzzy finder for all the functions available in the editor. You can search through these to find stuff you might like to do, and see inline which keybinding the function is bound to, if any. `spc h a` searches all functions, variables, etc., in a similar way. `spc h i` opens up an info browser, which is like man pages on steroids. Many emacs plugins have documentation here, as well as many system utilities. Last but not least, the help for Doom itself is quite nice, which you can get to via `spc h d m` (help for doom modules), `spc h d h` (general doom help), and so on.
For org-mode, you can learn a lot of what's available by typing `spc :` and then just reading through all the functions that start with `org-`.
emacsformacosx Its a fine solution, for the most part. I did have to fiddle around with terminal aliases so that I can control whether i get emacs in my terminal or in its own app window.
I've been using Emacs for about 3 months now and enjoying it. I'm only just scratching the surface though and not really dived too deep, I find it quite overwhelming tbh, it feels like the text editing part is really just the tip of the iceberg when it comes to Emacs.
Org-mode is pretty cool and I love the note capturing feature, I've bound Cmd+N to this feature so I can take notes quickly.
One thing that I've not fully figured out yet is how to share notes between my work life and personal life. Sometimes I make notes at work about some cool programming trick or something useful to know, but that stays on my work machine. I don't want work related information to be accessible from my personal machines but I want access to those 'general' notes. Obviously I could set up separate files that sync, but I really like the quick-capture workflow and introducing a "should I save this here or there" type of action would slow that down...
If you use separate files for each, I would set up a new capture template, one for work that goes to a work file, one for personal that goes to a personal file. Then it's Cmd+N p (personal notes that save to personal.org) and Cmd+N w or something like that.
Doing it as a separate keymap makes it easier to change the keybindings if you later decide to leave C-n at its default binding of next-line - something I actually recommend, since being able to perform cursor movement with keybindings that don't require moving your hands away from the default position has actually proven a lot faster in my experience than using the arrow keys. Navigation via isearch (C-s forward, C-r backward) is faster still, and something I'd really recommend making some time to try out as a newish Emacs user.
This seems unnecessary when all you need to do is define a key for org capture (I'm assuming here that Cmd-N is mapped to org-capture), which effectively drops you into its own keymap interface. Then the keys for each template are easily defined within template. Or is there something I'm missing here?
EDIT: Also, the user's reference to Cmd+N leads me to believe they are still using C-n for navigation but has a Mac, which has an additional key called "Command".
Ah, that's fair. Generally a buffer on a relevant Org file is never not visible to me, so I don't really need org-capture and went with a keymap based on the direct-to-template invocation described in the linked documentation.
I also use a Mac for work, but tend to forget about all the complex gymkhana I go through with keyboard prefs and Karabiner-Elements to get its keyboard to behave like those of the Linux and Windows machines I use. Since that includes remapping Caps to Command outside Emacs, and Command to Control inside it, that all probably makes my keybinding advice a little useless, or at least worth more consideration of how things would be in a closer-to-stock configuration.
Not quite related, but Century Link's internet filtering on their residential fiber service flags this page as dangerous. I had to click through a cert warning then a Scary Warning Page to reach the actual site. Said filtering is Powered by McAfee(TM), so I'm not sure if it's McAfee or CenturyLink that hates Emacs.
Whatever the stock configuration on their stock combo modem/router/AP device is. So, probably, yes, some kind of "enhanced" DNS. I know, I know, friends don't let friends use stock firmware or stock ISP gear. But when faced with the infinity of emergencies that has been 2020 when not having infinity time to work on things, low latency even during times of heavy throughput has pushed re-doing the network in this house way down the priority list.
What cert are you getting? I (not on Centurylink) see a Let'sEncrypt cert with sha256 BB:37:8D:DE:4E:AB:42:55:30:BE:08:10:A0:11:7A:CD:CB:99:51:91:4B:44:30:3F:E5:F4:76:B0:41:E0:AE:59.
Hmm. I have CenturyLink as well. Maybe the cert was serving its purpose and notifying me that the connection's been tampered with? I'll check again when I'm on my desktop (instead of mobile).
I haven't used Emacs to program for a while now, but I always use it for org-mode. I don't think org-mode is the best for me in terms of keeping organized notes, I find that I like Joplin's[1] interface more for that. Although I've thought about emulating the interface of Joplin by using folders and treemacs[2].
Org-mode really shines for logging. I use it at work to keep a daily log organized by sprint. Org-mode really gets out of your way and makes logging easy. It is deep and has a ton of features, but the base feature set is really simple and easy to get started with.
I am a daily emacs user for about 2 years. I am surprised to see eshell is the most popular shell package. It always seemed like an underdog. Maybe I'll try it out. Happy to see Ivy come on top too, I should give it another shot.
I want to see which vimlike packages are most popular. I use a modal editing plugin called Boon which is very simple and effective.
I've been following tree-sitter for about a year. ubolonton has recently shipped some great docs for emacs-tree-sitter. I am expecting some innovation to happen in the next year. Paredit for typescript, code transformation commands. We live in exciting times!
What stood out to me is that 71% of the respondents disabled tool-bar, 62% disabled menu-bar, 55% disabled splash screen, and 53% disabled the scroll-bar. This shows that the default user interface is perhaps better suited to the novice, not to an experienced user.
Shameless plug: I recently wrote a ~/.emacs guide to help beginners to Common Lisp set up Emacs in a DIY fashion rather than just installing the often recommended Portacle: https://github.com/susam/emacs4cl . Indeed the first few things this guide indulges in is to set up the user interface as follows before getting into setting up the environment for Common Lisp:
I also wanted to know which themes are popular, so I took the cleaned up CSV from this post and picked the top 30 themes from it with a script. Here are the results:
The column values from left to right are rank, number of votes, votes as percentage of total responses, theme name.
The answers in the CSV are in unstructured format and I have not normalized the data a lot to arrive at the list above, so there is some inaccuracy in the results above but despite the inaccuracy it gives a pretty good idea of the relative popularity of themes.
It is kind of surprising how many people have used Emacs for less than a few years. Org mode is a bit of a surprise, but it is very sticky and there is literally nothing like it out there.
I'm surprised the most used programming language is Python. The last time I tried the packages available for doing Python development did not really feel that polished.
I see it a lot in the Clojure community as well, as with various other communities (such as Emacs). Not only does it provide the people behind the projects better guidance, it also gives me a better idea how my own usage and opinions relate to the wider community.
Having said that, one thing I found remarkable from the results of this survey is the proficiency in ELISP. A sizable fraction of the respondents feel proficient enough to write their own packages, a trait which I have yet to find someone in real life for (and I know more than a dozen emacs users). I can’t help but think there must be quite some selection bias going on in the respondents of this survey. :)