The emacs ecosystem has really changed how I work.
I manage all of my email now in `mu4e`. I manage all of my notes, writing, TODOs, time tracking, invoicing in `org-mode`. For interacting with git, `magit` is simply amazing.
The most important thing is how everything works together. There is the obvious window, frame and buffer management, the kill ring, the searching across all open buffers. Less obvious is that while looking at email I can hit a few keys to create a TODO, schedule it for a particular date that will show up in my agenda, and will link back to that same email (which I can now move out of my inbox). Or, in my programming notes file, I can link to a specific commit for a project I'd like to come back to later.
And, the best part, which I've only barely scratched the surface of: everything is programmable. I can write an emacs lisp function to automate almost any part of my workflow.
I use notmuch instead of mu4e, and have been quite happy with it for the last 7 years or so. The org integration is good, though I don't actually use it all that much. What is indispensable for me, though, is being able to start a longer message in a text file, save it, open a message window, (C-x i) the message file, pull in some code or text from another buffer -- basically to treat my longer emails the way I treat any other piece of text that I'm working on.
Similarly, if I'm writing, any mail (or attachment) from the last decade is just a few key strokes and a search query away, without ever really taking my eyes off my current buffer.
I know there are other ways to accomplish the same thing, but that close link between my mail and the rest of my writing is the main benefit, for me, of having my mail in emacs.
That's true. Beyond links to email, I also include links to a specific line in a file, links to a commit, links to a remote file (e.g., an apache config file), maybe some snippets of code, links to other TODOs, all in one TODO. So it's really having all of those together which is important for me.
If I wasn't using org, I don't think I would find it that useful. I'm not really a power user of mu4e. I don't have any complicated email workflows. I like that the search is very fast (for me, anyway -- I only have 100k emails), and, obviously, that my email is stored locally. I like that I can compose in Emacs. I also use two computers and I like that I can easily share configuration. My config, which doesn't do anything too fancy, is here: https://github.com/mjhoy/dotfiles/blob/master/emacs.d/lisp/i...
How good are OS X task management tools? Can they build/export custom reports and stuff?
There is only one big thing I find is missing to Org, and that's its lack of options
for collaboration. After all any humans collaborating toward common goals would do best
to have a common plan and a common way to track each others progress.
I think you more mean, "I'm not an 'Emacs is my Operating System' person".
There are many people who use Emacs as their OS, its never been appealing to me, because I like the richness of other tools.
There is a question though, are OSes doing enough to make the integrated experience like Emacs something that's done system wide? I think Apple comes close to providing the set of things you want, but it still feels tacked onto the top, rather than more deeply integrated.
I'm sold on Magit. If I had more interfaces that worked like Magit and were as well thought out, I'd use them, even if I had pretty OSX programs to use in their place.
Richness of other tools are OK if you use one OS. But if you switch between several of them, then Emacs tools more handy...
I'm using Windows & Linux at work, and Mac OS X at home, and Emacs provides uniform interface for most of my tasks, except web browsing and multimedia...
They essentially act as regexes that when match allow for an external application to be called with that text sent as a parameter. This allows for dates to be clickable and create and event in a calendar for example.
They also do a good job of taking phone numbers from emails and when an unknown call comes in suggesting that it might be the person who included that in an email.
These features generally work well in their apps, but I think there's less support for third parties to create custom options (though I haven't actually tried so not sure).
I use Emacs' rmail with mairix as a search tool. I can link to emails via rmail like this:
[[rmail:<mbox-path>#<message-id>][link text]]
No need to type that out, M-x org-store-link does that for me in any rmail buffer.
I split my mboxes regularly, so I need to link them via mairix instead of rmail. I haven't set it up yet, but that is so trivial I guess it's already done.
I deeply share your feelings and recommend anyone to give
Emacs and Org mode a try. The learning curve can be long, but
if you start programming Emacs on your first day it will love
you back faster.
If Org mode interests you this may be good advice:
- http://doc.norang.ca/org-mode.html
For the lazy, I have an emacs.d directory packaged with,
Norang's Bernt Hanson Org mode configuration, if you are
eager to try Org mode for the first time, try it out:
- clone https://github.com/ncouture/emacs.d
- replace ~/.emacs.d with the repo's root dir
- launch emacs
- read Bernt Hanson's Org configuration workflow
documentation (http://doc.norang.ca/org-mode.html)
If you start using Emacs and want some advice:
There are many well-rounded pre-packaged Emacs
configurations available out there, they may be nice but
they will fool you.
Try them to get a feeling on how Emacs behaves with
other people, but don't stick around too long.
Build your own environment.
The best way to use Emacs is to make it work the way you want.
http://doc.norang.ca/org-mode.html is awesome for inspiration but it's a ton of information. I think your point about pre-packaged Emacs configs also applies to org-mode configs.
For building a productivity system, I think it's much easier to build it in small pieces, week by week.
It's true it's easier to build your system in small pieces as you discover your needs, but it helps a ton to have a better idea of what can be accomplished through customization.
In my case, I didn't write any Elisp between 2004-2010 and probably used Org mode as a bullet list during that time. Until I had enough interest to read its documentation and explored how others are using it.
Only then was I able to come up with a half-decent solution that was still quite good, but really so far off of what can be accomplished with a better understanding of the parts at play in this mode, as demonstrated by Bernt Hanson's setup (http://doc.norang.ca/org-mode.html).
To this day I'm not even considering trying to rethink the way he is using Org mode because his setup works out perfectly for me, and I have to GTD like everybody else.
All I'm saying is it may not be obvious at first glance and without studying documentation but a very powerful set of tools are available in there and anyone with half a brain can use them, and that it's best to adopt complex-type configurations once you've wrapped your head around them.
Take the org-mode advice with a pinch of salt. It is an incredibly rich and powerful package, but it's possible to get completely enveloped in org-mode, costing time that could be better spent improving ones skills elsewhere.
What I am saying is: emacs can simply be an amazing text editor / programming environment. It doesn't need to be complicated. You don't need to invest time learning kitchen sink frameworks. (But as a bonus, magit is the best interface to git that there is!)
How do HTML emails look in Emacs? How often do you have to open email in browser to be able to properly look at an email? What email service do you use?
Simple HTML emails look fine, more complex ones don't. I think now you can use Webkit to render them, but I haven't set that up yet. It isn't much of an issue for me, though.
Thanks, I did not know about mu4e. Will have to check it out. Back in the day (before there was google, much less gmail) I loved MH-E. It's been a while since I've done email in Emacs.
Among the highlights of this release is Xwidgets, which allows embedding GTK+ widgets inside Emacs buffers.
One such widget is WebKitGTK+, a full-featured port of WebKit for use in GTK+ apps. As a consequence of this you can now browse the internet and maybe watch some YouTube inside Emacs [0].
Only yesterday I discovered I could play an adventure game in emacs. Then I discovered a bunch of layers and modes that were awesome. I haven't begun to scratch the surface, but if I buy a new Nexus 6P can I just flash Emacs on it?
A great way to discover things in emacs is the unmemorable command `finder-list-keywords` which gives you a menu of all the features in emacs by category
+ Substantially reduces the stability of Emacs due to GTK
memory leaks and bugs (terrible!).
This is also the reason that many Emacs users compile Emacs without GTK toolkit support on Linux.
+ Introduces serious security issues via the webkit part, and no, host/browser process isolation isn't really doing anything to mitigate this.
With all that in mind, I'm wondering why they bothered including it
in the first place. It will never amount (at least I hope so)
to anything that can be reliably depended upon.
When you say "move M-x customize to gtk widgets", which text based would you replace with GTK widgets? Customize certainly doesn't initially seem as friendly as a traditional preferences dialog, but I would be hesitant to lose the "it's all text" navigability and consistency.
Having a friendlier, good looking "Preferences" based on gtk would help newcomers. We could keep customize too but a new panel with simple familiar look would help a lot of people to get into emacs.
Emacs is not only on GTK. I doubt any indispensable core components will depend on xwidgets unless it can embed each toolkit emacs can use. Further, customize is used on the terminal emulator and on the framebuffer too, having it require X is not feasible.
I wonder if those widgets require GTK support in Emacs. I compile a plain X support for my emacs only, because with GTK it doesn't stay up for months without crashing. I had an emacs server with 180 day uptime the other day. Maybe on my work machine that is Windows anyway, I can try this out. :>
I would like to use Emacs on terminal, but few of keybindings don't work well based on terminal to terminal. For example, last three months I got a Mac for work, and on iTerm "C-/" didn't work for Undo, or some keybindings starting with "Meta". I guess that could be solved by configuring terminal properly with key sequences, but I just ended up using GTK (but well the GTK version crashed whenever I closed one of the multiple frame open). On linux, so far it has worked flawlessly for me.
I'm by no means an Emacs expert or even power user, but I've found Aquamacs to be pretty good for OS X. It's stable and seems to strike a good balance between integrating with native UI functionality and the Emacs way of doing things.
You don't have to use the terminal, and I assume OP isn't, either. Emacs still supports Athena and Motif widgets, among others, if you don't mind the looks.
I'm still on the GTK2 port, largely because I got sick of troubleshooting every GTK application after every GTK release.
If you're on OS X, it's probably worth checking out Aquamacs, too.
Let's start a thread with "little cheries" you found in emacs! Focus on things that you found after years of usage and you regret not noticing before.
Given Emacs scope age it's sometimes easy to miss some very cool stuff. What's more, lots of things on Internet are outdated.
I will start:
- elscreen - you can configure it to get tmux-lookalike inside emacs. My config: https://gist.github.com/kozikow/58b46c45a2c24406dc7cde3f18610433
- hydra - create mini-menus in the mini buffer. Quick and reduces amount of shortcuts you need to remember. See previous point for example.
- apropos/helm-apropos - search across all variables/functions/commands at once.
- imenu/helm-semantic-or-imenu : get overview of all definitions in current file, including classes or functions. Works in majority of languages without special setup.
Magit gets a lot of deserved love on the internet, but I think abo-abo (the author of hydra, which you listed) is quietly leading a kind of revolution in emacs usage. His trifecta of packages lispy (edit at the speed of thought in lisps), swiper/ivy (a simple and powerful interface to every facet of your editor), and hydra are the main reasons I use emacs over vim.
I am a long time Helm user. I tried Swiper/Ivy when they were first announced and appreciated the speed and simplicity, but found the features somewhat lacking compared to Helm. There has been a bit of buzz about these abo-abo's ecosystem recently and I discovered a configuration option in Spacemacs to replace Helm with Ivy, so I think I plan to give it another shot.
Yeah the spacemacs-ivy implementation is a good place to start. One decision they've made I disagree with is the abomination of a hydra they've put in (what you get when you press C-o in a ivy minibuffer prompt). If you're interested in a more streamlined one, take a look here: https://github.com/abo-abo/hydra/wiki/hydra-ivy-replacement
lispy - I use smartparens, it have mostly similar feature set. Smartparens advantage over paredit (and it seems lispy) is that it focuses on giving good support for editing parantheses groups in any language. E.g. you can use it to edit C++ expressions. See my post: https://kozikow.com/2016/06/18/smartparens-emacs-package-is-...
swiper/ivy - I am already hardly locked in into helm. Even if some competing packages are more powerful (e.g. I used icicles at some point) or faster (e.g. ivy) due to big community helm have lots of community-contributed, helm-optimised packages. Type M-x install-package helm- vs ivy-.
lispy/smartparens: FWIW, I use both. If you think they have a similar feature set, you haven't looked at lispy closely enough. It is more about making lisp editing operations frictionless, than it is just pair management.
Check out the simple overview[1], and maybe some demos[2].
swiper/helm: this is more of a personal choice, I agree. Having given both a fair shake, I find ivy more easily extensible, and I prefer the simpler look. As for the community support, there has yet to be something for only helm that I've missed in the various counsel functions.
For me God Mode [1] has been amazing. It's modal editing (like evil or vim), but using emacs key bindings. Your make memory adapts to not hitting C- very quickly, and your pinkies will be very grateful
I'm still a novice emacs user, and a kind-of-longtime vim user, heres my "journey"
2010~2011: learn vim because I wanted to slack off studying for exams
2012: addicted to vim keybindings at this point, tell people 'I can't use other editors without "proper" vim keybindings'
2012: also discover tmux, because i wanted the ability to use vim keybindings and copy things in/out of shell
2012-2016: dabble with emacs sproadically, put off every time due to my vim keybinding addiction. tried evil mode during this time, and to my limited knowledge of emacs, things like C-u not working (scroll up half a page in vim) tick me off and in different modes the vim keybindings would suddenly disappear which was annoying
2016.04: discover spacemacs, try again, things work quite magically. in addition modes like org-mode are working as I expect (no random de-binding of evil-mode), discover new modes like magit and projectile-helm which keep me in (spac)emacs. also supports screen splitting with (:vsp, :sp) which is great.
one thing i really like about emacs is i still use the shell (awk/sed/ag/etc) for a lot of tasks, and since i can use the shell inside an emacs buffer, copying-pasting out of them are incredibly easy, replacing my tmux usage.
next step for me is to get more proficient in emacs (i hope i can read emails, do simple browsing, etc) and then hopefully setup emacs from scratch for an exercise instead of relying on spacemacs to do everything for me
I was once a vim user for a year and switched to emacs to look at its advantage from vim. Keybindings gave me so much pain to adjust and took my brain for a month to completely absorb the keybindings. And even did 'alias vim=$(which emacs)' to force my self to use emacs. I did not try evil-mode thinking that won't resolve my vim addiction. Now I still happily use emacs for 2 years everyday and never get back to vim except for some circumstance that I am forced to use vim on other computers.
> one thing i really like about emacs is i still use the shell (awk/sed/ag/etc) for a lot of tasks, and since i can use the shell inside an emacs buffer, copying-pasting out of them are incredibly easy, replacing my tmux usage.
I mainly use vim and what I normally do to use shell within vim is to open another window and run something like:
:r !some-shell-command
If I want to filter text within the buffer to the shell command, I can visually highlight it and run.
:'<,'> !some-other-command
It's easy enough to undo the result and retry. I can edit the shell command opening the command line window with q: (which allows me to browse through my ex command history and use standard vim keybindings to edit, copy, and paste parts of the commands from the history that I need to run them again.
I know you can do something similar in emacs using the M-! keybinding, but I'm sure that's not an orthodox way of doing things in that environment.
Sure it is, via C-u M-! . I'm not sure what you mean by "orthodox", but that's part of the standard configuration, so I have to consider that whatever Emacs orthodoxy there is must include it.
I used to use Xcode for all my work. Then I had to write Clojure for a couple years, and only used Emacs. When I got back to writing native code, I went back to Xcode and ironically felt like I had slipped into the distant past. So I switched to CLion, the latest bells-and-whistles IDE for C++. But all my custom Emacs code was too powerful an adversary for even CLion and I am back to using Emacs full-time for C and C++.
One caveat: I now use vim-mode in Emacs ("evil") which really has taken my Emacs experience to a new level.
I have been trying to replace Xcode with Emacs, but the biggest problem I don't know how to solve, has been Cocoa/ObjC/clang autocomplete. If I could have that work like Xcode, I could probably switch tomorrow.
I too tried to get autocomplete going in Emacs, and that is the biggest challenge. However, I quickly realized that autocomplete is overrated. I am no less productive without it. In fact, the "snippet" module for Emacs has allowed me to be a lot more productive by generating keystrokes that complete common language idioms for me quickly. In C++, for example, using push_back is very common, and an autocomplete could help with this simple function call, but my snippet goes further and does so more quickly with fewer keystrokes.
Autocomplete even on a major IDE on a fast machine can sometimes still take an extra second to pop up. I can type faster than that, and I can certain snippet a lot faster than that.
Other things like all the different ways to write for loops (the types of iteration) I have snippetized so I can quickly generate the loop I need, which goes much further than autocomplete would.
Emacs being able to load shared/dynamic libraries is huge; it means we'll be able to load so files from a user's home directory, or the standard lib paths, and use foreign functions to extend Emacs. And with XWidgets...
Well, now you could write an OpenGL game that uses an OpenAL audio layer and displays in an Emacs frame, all in elisp. Because, why not?
Interesting, I wrote such an emacs FFI about 15 years ago, but RMS was fundamentally opposed to it. Gtk-emacs was then based on a smaller scale FFI, but a more generic exposed FFI was still devilish.
I wanted to use a proper AutoLISP environment then.
Since the dynlib support probably uses GPL3 headers and runtime symbols, I doubt the result can be licensed anything but GPL3, so I'm not sure what RMS would complain about. This is also the reason why LLVM's ld.gold support is a plugin IIRC, because it has to include a binutils header (/usr/include/plugin-api.h, which is weirdly generic name for such a thing to exist in /usr/include).
I don't remember any discussion of that 15 years ago, but there's a difference between some sort of general FFI and loadable modules of this sort that rms rejected on Moglen's legal advice. (Disappointingly, as the design was intended to make the copyright situation clear in a legal case.)
I don't know why the 2002 implementation was reimplemented (without credit and apparently without understanding it properly).
Actually, it turns out that what's there now is something totally different than what was trumpeted a while back, i.e. not like the original implementation.
"Why not?" might involve not understanding what that sort of thing is likely to involve. That's not the sort of thing the original version of the feature was intended for, that this appeared to have copied when I last knew, and it didn't make extending Emacs any easier.
Emacs VC mode has a bug where all listed files in the vc-dir buffer are shown with their basenames for at least Git and CVS repositories, and for CVS it renders the mode unusable. I made a patch but I guess they're waiting my paperwork (copyright assignment) to arrive so it couldn't make it for this release. Here is the patch: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24082 for whoever uses vc-git and vc-cvs. It's in the last message there.
Having been using emacs on and off, both on Windows and Linux, and having found it being useful on some occasions, I somehow can't help thinking of it as more of a historical artifact than a toolset I would want to use on a daily basis. Being a very powerful personal computing environment and kinda fun to use, to me emacs still falls short in the ways that, for instance, UNIX command line interface with its simple single-purpose utilities never did. I am not even talking about the need to remember a gazillion of context-dependent key bindings, because with the command-line utilities you also have to remember the correct switches. I guess, this may be the case of needing to make a choice; but, if I am ever to be forced to actually make one, I'd probably settle rather for something like a full-blown desktop environment, or, should I find myself in front of a text terminal, Midnight Commander (whose built-in text editor now even offers syntax highlighting, for those who like it).
>Being a very powerful personal computing environment and kinda fun to use, to me emacs still falls short in the ways that, for instance, UNIX command line interface with its simple single-purpose utilities never did.
Amusingly, I'm the opposite. Emacs to me is more consistent than the UNIX command line interface, and I feel Emacs satisfies the Unix philosophy better than the command line itself does.
When people write "applications" on top of Emacs, they frequently come with APIs that let people utilize individual features. Part of the reason org-mode is so successful is its ability to leverage features from many other applications built on top of Emacs (mail, links, calendar, image viewing, etc).
Except for the few core Unix tools, most console applications in Unix do not provide as much flexibility through the command line interface. Nor do they come with APIs that let others build upon them.
To someone not well versed with Emacs, what I'm saying may sound crazy, as for many people, the extent Unix tools do provide these switches/APIs is very satisfactory. But it's not even close compared to Emacs.
This is why when I started my job and we work purely on Windows machines, I had no problem. I installed Emacs for Windows, and had access to much that I used to in Linux.
I think that's pretty crummy you're getting downvoted for this kind of remark.
I myself tend to agree with you, as a former Emacs user of maybe 10, 15 years. For the things I used to use Emacs for (C, make files, only crude version control integration, etc) I'm sure it'd still do fine. What I found, though, is that my workflow and habits changed, and Emacs couldn't keep up. Or rather, there are good-looking, easy-to-use tools that support my workflow out of the box, and having to spend a day futzing with my editor just to get the same workflow functionality lost its luster a long time ago. Visual Studio Code, for example, it does great intellisense and Git integration without having to do a thing. And I don't really mind having to use the mouse more, because, frankly speaking, I type a lot less than I think these days; I just spend less time on the mechanical act of typing lines of code than I used to, so keeping my hands on the keyboard is less important than it used to be for me.
So for me, Emacs is, as you said, a historical artifact. The tools I use today simply work better for how I work, and even though Emacs could be molded in just about any direction, I no longer feel like it's worth the trade-off. Tools like VSC are good enough, right now.
Hey, that's great, I'm glad that works for you. I'd rather pick the best tool for the job, and learn it, than try to make was was for me a mediocre tool less mediocre.
If I were, for example, editing Java at any great amount, I'd probably look to one of those popular Java editors (I've heard good things about, I think it's called, IntelliJ?). I'd wager money it's more finely tuned for working in Java than Emacs will ever be, just because there's people who want to keep making money to write it.
And so on.
Like I said, if I were still just writing code like I used to, in an earlier stage of my career, I'd probably be satisfied with Emacs. I moved on, though, and do different things. When faced with a choice of learning new, good tools and trying to hold onto my old mediocre tools, well, I'll pick the learnin'. I think I've ended up more productive, anyway.
...And I think the phrase "mediocre" is where we disagree. Java is perhaps the worst example, but there are languages whose emacs modes are simply unbeatable. The lisps, in particular, but there are others. And if the tools aren't good enough, they can be improved.
Give a man an IDE, and he'll have the tools that IDE provides. Give a man Emacs, and he'll have whatever tools he wishes.
OTOH, you may well have ended up more productive for the kind of work you do. Your tools, your choice. I am willing to respect your decision.
Showing respect for the subjective deserves, well, respect. But it is the insight into the objective that is interesting, and I think that it should be recognized as a law of Nature that if something (or someone, for that matter) is trying to be good at everything, it (or they) is bound to be not very good at anything in particular. I am not seeing, for instance, how emacs can come even close to what IntelliJ has to offer to Java developers - short of having a faithful IntelliJ clone written in elisp, of course.
Ouch. I did my best... I shall try harder next time.
My point was that while Emacs certainly isn't as capable as IntelliJ is at the moment, It's possible to build those features upon IntelliJ. An attempt to build Emacs's featureset on IntelliJ, OTOH, would crash and burn.
Emacs doesn't try to be good at everything - not in the conventional sense, because Emacs is a platform. There's a lot of software built atop it, but they're all really good at one thing: Paredit isn't Org, which isn't Geiser, which isn't Flycheck, which isn't etags.
FWIW, I've thought this whole exchange was both useful and respectful, even though we obviously disagree. :)
IntelliJ is a good example, because you're right, you could extend Emacs to have a looks-and-works-exactly-like-IntelliJ mode. But now you've got two jobs, writing your Java and developing and polishing up your editor in elisp.
Or, for my current favorite editor, Visual Studio Code, immediately upon launching it you get intellisense via Omnisharp, really decent git integration, all the integration you'd need with dotnet core, and a ton of convenient stuff like search/replace across the whole project, refactoring that works well for C# project, etc.
Could this all be reproduced in elisp? Absolutely, I have no doubt. Has anyone put together a package to do so? Nope, though of course there are disparate packages to solve/simplify/address these things. Will anyone create one package? Nah. Will anyone bring it up to the level of polish that VSC provides out of the box? Definitely not.
Much as I like Emacs, and I really did, when I started trying out new modern editors I felt like I'd been living in a cave.
Actually, just writing this all out has made me realize that the biggest dealbreaker for me is the lack of polish. Seeing what a modern dev experience is like, I couldn't go back.
Yeah, I don't mind the lack of polish as much as you do. And I primarily work in scheme and lisp, where there's not much out there that can beat emacs (apparently, there are a few that people swear by. If you have a couple grand on hand, you can try them). The write/eval/test loop is so short and clean. And there's integrated documentation and tab completion.
...I think you're forgetting something about Emacs: It's not just an environment (I for one don't browse my mail in Emacs: I can't get the emacs mail clients to work), it's also a text editor with unbeatable extensibility. To this day, there is not a text editor I know of that is both as extensible, and has had that feature utilized as throughly. In many editors, extensibility is actually an afterthought (cough cough vim cough cough). There is integration with almost every language and tool that exists, and a few that don't anymore.
That is what makes it an amazing programming environment.
I use a pretty vanilla Emacs. The only customizations I do are:
- removing clutter (zapping toolbars, splash screens and the ilk)
- making very small tweaks to keyboard bindings so that it works more like Epsilon
I don't think that any of the Emacs improvements made over the last decade or more have done anything to my quality of life in Emacs. Rather, each release is more "what do I have to turn off this time?"
Fortunately, getting to bare-bones Emacs is not hard; with commercial editors it's often much harder to undo the damage of gratuitous "marketing checkbox" features. [I'm looking at you, Visual Studio 2013...]
every release there is more and more 'sexiness' that breaks useful functionality. i can't even comprehend what someone did to gud.
it used to be that you opened up a tgz and it would nicely display a dired mode of the contents. not for a long time.
and c indenting used to just work- now it seems to be confused by looking for patterns that exist by convention, not as any part of the language specification...so indenting just doesn't work a lot of the time
and for some reason someone with truly awful taste gets to choose the color schemes for highlighting (font-lock). i used to be able to just turn it off...but that becomes increasingly difficult
for a 30 years emacs user, it just keeps getting worse all the time
Font-lock is pretty easy to turn off. But then, the first thing I did when I installed Emacs was change the colorscheme to solarized dark, something I would reccomend to anybody.
As for the rest... I have no idea. There are a variety of C indent styles, and most are fairly standard (K&R, GNU, Linux, etc.), so I'm puzzled as to why it doesn't work, especially considering that CC mode has to also support C++ and Java, and so can't get too specific. If it really does suck that badly though, I'd hunt around for an alternate package.
Why would you use a vanilla emacs? Paredit, js2, magit, there are so many excellent extensions that can improve your workflow. If you're using lisp/scheme, SLIME/Geiser is indispensible.
I mostly work in C-like languages (and Python). Vanilla Emacs is just about all I need. I don't treat it as many people seem to use it, namely "enter Emacs once, then use it as an environment for hours."
Also, I learned Emacs in 1979, and it's pretty much wired into my muscle memory. Getting things back to an I-don't-have-to-think-about-it state is important, and whiz-bang features just get in the way most of the time.
There are nice tools like "which-key" which massively reduce the work of remembering shortcuts. They are, incidentally, only shortcuts. The menus work as well.
Don't let the age of emacs fool you into thinking it is somehow less relevant. Simple and good ideas are usually old. Compare the complexity of writing a "plugin" in Visual Studio or Eclipse. Similarly the command-line is here to stay.
There are packages such as "which-key" that can help by providing popup choices.
At risk of coming off as flippant or mean, I think you completely missed the point. It is a productive and stable editor environment which runs in various ways across all major computer platforms. It has a veritable mountain of established extension code, modes for performing tasks outside of software development, and portable configuration. The keybindings are considerably more consistent than the alternatives, and if you don't remember them you can always use the in-built searchable help system, or try to tab complete it in the M-x prompt.
These things are not 'historical', they are the things which have been so permanent that after thirty years they are still useful.
It's surprising to see so much popularity in mu4e in this threads when no one mention Gnus, I am too much 'hardwired' in gnus and don't think i have the 'courage' to try something else but someone would know how does it compare ?
Any chance you were successful at building it from source in the Ubuntu subsystem? I got some weird errors related to maybe shared memory or something and gave up.
No, i just did sudo apt-get install emacs24-nox. I haven't had great luck with build tools. I broke the whole thing two or three times trying to install ghci.
Depends, if you need OS interaction you'll need a posix-like subsystem indeed[1]. But first I write mostly lisp (ml, js and python) and I just can't live without paredit and second emacs extensibility is a drug to me now. Everytime I have to use anything else I feel crippled.
[1] I installed msys2 which is less crufty than cygwin.
Msys2 by design restricts the available packages to those useful for compiling software for Windows. The emacs package is in their separate mingw repository, which means the produced binary is a Windows program and does not understand the posix environment at all (i.e. no /proc/, /dev/ etc).
Cygwin is an OS that runs on top of windows - all cygwin programs are windows programs but not all windows programs are cygwin programs. The emacs package for cygwin can fopen() /proc/ and /dev/, use the linux socket API, and in general follow the linux makefile more closely.
I'd say you are correct in thinking you need a few UNIX tools to make Emacs on Windows comfortable. But maybe it's fewer than you think. I just had to get grep, find, diff and now use Emacs on both Linux and Windows and feels almost the same.
In fact, that's part of what I love about Emacs: for the most part I don't have to worry about learning how to do stuff on Windows, I just do it in Emacs.
Do you know the difference between emacs-w64-25.1-Og.7z and emacs-w64-25.1-O2.7z. I'm guessing maybe one is a debug version and the other was build with -O2.
gcc has a -Og option that performs all optimizations that don't interfere with debugging, so I'd guess that emacs..-Og is built using gcc's -Og option and emacs..-O2 is built using gcc with the -O2 option.
XWidget support is really good. Finally have C++/Opengl docs showing in the browser inline in emacs and now that the browser is inline, theres no reason to leave emacs anymore.
Somewhat related: I am starting a new job soon and I want to get Emacs setup "right" this time. I've been using Aquamacs for the last several years, but I'm wondering if there is a better way to use Emacs on the Mac these days?
As part of this, I want to get my .emacs under version control and shared between computers so I have the same settings everywhere. Is there a good way to do that with Emacs packages installed through MELPA/ELPA?
I like brew installing `emacs-mac`[0] which installs a port run by a developer in Japan. My favorite feature of it (among other amazing osx specific changes) is the sub-pixel scrolling support in emacs.
When you setup your `init.el` you can call `(package-install x)` and if the package is already installed it'll do nothing but just make sure it's there.
If you wanted the whole thing figured out ahead of time I recommend using Spacemacs[1]
I ported over a few years of custom keybindings and other config to Spacemacs. It was not too difficult, basically you can just tell Spacemacs to load whatever.el at startup.
Eventually I switched to evil-mode and I rarely use most of my old keybindings, but I still keep them around!
A bunch of (mjhoy/require-package 'package-name) are run on init, and if the package isn't present it's installed. This has worked pretty well for me for keeping my mac and my linux emacs in sync.
Look into use-package for a lot more control over how packages are loaded, as mentioned in another comment.
I've been using Emacs for 20 years now, and for the last few years I've trusted most of my setup to Prelude (https://github.com/bbatsov/prelude). It does a LOT of the tedious setup work most emacs pros would do for themselves. After that, I just make a few modifications to the personal.el file they provide and commit my entire ~/.emacs.d to github. I can't recommend Prelude enough, especially with Helm integrations built into so many parts.
I'll second the recommendation of prelude. It does one thing I hate (guru-mode, but it documents how to disable it), and it is flakey about a very few things, but in the main it is golden.
I've been using spacemacs at work, and while I absolutely love its layers, I really miss prelude. Something which combined the stability and sanity of prelude with the layers of spacemacs would be just about heaven on earth.
I use emacs with mac for close to 1 year now, after having used it on linux and windows. It hasn't given me any issues at all except for one minor issue which i chose to ignore. The point is, you don't need to be scared to use emacs on mac
With the emacs-mac-port by Mitsuharu Yamamoto (available on railwaycat's homebrew tap) you can set this in Emacs with (setq mac-command-modifier 'meta).
Interesting stuff going on in this thread. I use Emacs for everything except for Mail, since i never liked wanderlust, should try some other mail reader. But i just realised there is some great functionality from this thread i never knew existed like 'which-key', org-mode(wanted to use this from long) etc.
Is Emacs a monolith?. I haven't used this editor but from what I read people like it because they do everything there. Is this true?. If so, it doesn't sound like a good idea to me. Anyone has more insight of the goods and bads about Emacs.
Some people do everything there. They tend to be very vocal. Others just edit text with it. They tend not to be. Most are somewhere in between. We usually try not to be too annoying.
From the perspective of usage, while Emacs has a great deal of functionality, you need not use any of it that you don't want to. Indeed, Emacs is so shy and retiring about all it can do that you really need not even know about anything beyond text editing, unless you decide you want to.
The main drawback from my perspective has been interoperability. Org mode is brilliant, but when everybody else uses Evernote or OneNote, Org can't be the only thing you use unless you want to be that guy.
And using Emacs at all makes you likely enough to be seen as "that guy" anyway that it's worth not living up to the stereotype. I wish I were joking when I say that, in adult life, I've been the object of far more unfriendly regard as a result of my choice of text editor than as a result of my homosexuality, which I've never really been at particular pains to hide. It is easier, in the modern tech industry, to be gay, than to be an Emacs user. That's not Emacs' fault or that of its users, but it is real, and perceptions matter; if you're averse to the occasional funny look, this may be worth taking into account in your consideration of whether to try the editor.
I've been using emacs for over 10 years. I use it for the things it is good at, and other tools for what they are good at. In practical terms I use emacs for complex or repetitive editing tasks, org-mode for planning and lists, budget my finances using a my own emacs code, edit and work with Clojure and Common Lisp, writing blogs.
Don't worry about to having to trash all of your tools. I only edit in emacs, I do everything else in a browser, thunderbird, terminal, etc, but I know that if I want I could do in it all the things other people described. I'm not sure if it's worth it so I don't. Furthermore it takes time to learn.
Does it matter? If your connection gets MITM'd and someone changes the .sig files, they'll no longer validate against GNU's code-signing public key (which you may already have, or if not, the link to download it is https (https://ftp.gnu.org/gnu/gnu-keyring.gpg). (Unless of course that person has GNU's private key, but in that case you've lost before you started)
(Incidentally, if you just change the url from http to https (or use the EFF's https-everywhere addon) it works fine, the server does support it)
I think you should read what GP said again. To repeat: there's no point in downloading a PGP signature over SSL -- if you have the signing key locally (which you can get over HTTPS). Because you use crypto to verify the signature and if someone MITMs you then the keys won't match. The reason why most people use HTTP for distribution (including many GNU/Linux distributions) is because mirror sites generally don't have HTTPS, and so you would have to require everyone to connect to your main server (which increases bandwidth and latency costs).
I manage all of my email now in `mu4e`. I manage all of my notes, writing, TODOs, time tracking, invoicing in `org-mode`. For interacting with git, `magit` is simply amazing.
The most important thing is how everything works together. There is the obvious window, frame and buffer management, the kill ring, the searching across all open buffers. Less obvious is that while looking at email I can hit a few keys to create a TODO, schedule it for a particular date that will show up in my agenda, and will link back to that same email (which I can now move out of my inbox). Or, in my programming notes file, I can link to a specific commit for a project I'd like to come back to later.
And, the best part, which I've only barely scratched the surface of: everything is programmable. I can write an emacs lisp function to automate almost any part of my workflow.