I have yet to encounter anything that can match the sheer flexibility of Emacs.
For example I am currently using Org mode to write some documentation complete with hyper-links, tables, foot notes and the option to export the results as LaTeX, HTML, Open-Office, and so on with just a few keypresses.
It's not just an editor, or an IDE, or even a windowing system - it is a cross-platform computing environment that can be fashioned to exactly suit whatever purpose you require.
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'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.
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."
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.
> 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.
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.
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.
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 :-)
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...
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.
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 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).
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
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.
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.
You should check out tramp-mode too. Its a killer feature that lets you edit files remotely (AWS, Azure, even docker containers!) as if they are local. All the stuff work, so you can do diffs between a local file and an a AWS file and it all appears to be local. If you are editing a remote file and do a git action (through magit) it knows to work on the remote file. You can open up remote shells also. You just go:
CTRL-X CTRL-F then => /ssh:username@example.com:~/somefile.txt
and you get a local buffer with the contents of the remote file (via scp). All your editing is the same as if it is local. When you save it does a scp back to the remote machine. You can even edit in docker containers:
/docker:root@03f5f926f1ca:/etc/environment
as if they are local. Merges/diffs all just work its really great.
You can also spawn a shell, provided your particular shell is available, in another window too. I can stay entirely within Emacs if I realise, say, I need to do something en masse that's really easy with a shell one liner.
Though if I'm exploring a server problem, it's useful to know how to use vim. If Emacs IS installed, it's probably with default settings and it's easy to forget that it'll scatter auto saves everywhere by default. Especially (and usually only) when I'm behind a machine that doesn't have by Emacs set up.
> A common selling point for VIM is "its installed everywhere you just ssh in and it's available".
I've never understood this argument unless you're coming at it from a sysadmin perspective. Sure if its available everywhere that helps when I'm sshing in to random systems to sysadmin stuff.
But I don't do my development by logging in to random new systems all the time. I do my development in an environment that I have set up to be productive with.
That’s a very specific development story, though, common to e.g. web development.
If you’re, for example, a developer working on an embedded platform which (even temporarily) has no ssh, and probably no emacs as well, tramp-mode won’t work.
I’m a hard emacser, but it’s true that vi is usually much more ubiquitously available, so it’s good to know how to use it.
SSH isn't the only protocol supported by Tramp (from what I hear, it's actually a late addition). Essentially, if you can get somehow get a shell on a remote machine, you can make Tramp work with it.
It might be possible to get tramp working over a serial line (while still being able to use the same shell, though?), or over telnet, but practically I'd probably just type "vi" to quickly edit a file.
Again, I'm saying that as someone who uses tramp-mode all the time, otherwise.
> If you’re, for example, a developer working on an embedded platform which (even temporarily) has no ssh, and probably no emacs as well, tramp-mode won’t work.
Maybe I'm wrong but I really don't think embedded developers do a lot of work directly on platforms that low level/limited.
You do your development on your main machine, automate deployment to your target, and debug using a gdb server or openocd.
Honestly mg or nano is more ubiquitous than vi. Any system that has vi installed will likely have nano as well.
As an OS developer myself, I can tell you that logging into platforms to quickly tweak something using vi happens all the time. It's not about "directly developing" on the platforms, it's about debugging and trying things out.
nano is a very young editor, comparably, invented in 1999, and GPL on top of that. I'm not sure it even come out of the box with any of the BSDs (OpenBSD at least does not seem to have it).
vi was first written by Bill Joy himself in 1976, and I'm pretty sure it proliferated in many different forms over many, many different platforms.
This really hits at a core of what I call developer vs. sysadmin perspective. A developer usually works in a persistent environment they fully control. A sysadmin does a lot of work on multiple, often short-lived servers. So the former prefers customizing things the way they like; the latter learns and sticks to defaults.
At one of the Lisp projects I worked on, this split was clearly visible. One of my co-workers had the dev perspective, the other had the sysadmin view. Both used Emacs and Slime, but one had it fully customized, and other had it bare-bones, and spent most of his time in raw terminal anyway.
(I, of course, am hard down on developer view. My Emacs config has no peers :)).
Totally. C-x C-q on a dired buffer, and you can edit most of what's essentially an ls output as if it was a text file. C-c C-c to commit changes. I find myself using it very frequently for file management.
On my last project, I decided to do all remote server ops through Tramp, just to see how convenient it was. Turns out, very.
Besides launching a shell, one trick that you can do is piping Tramp invocation, including across different protocols - essentially creating tunnels. One special case I use frequently is for sudo operations.
C-x C-f, then /ssh:username@example.com|sudo:example.com:/etc/someconfig
Suddenly, you're editing as if you launched a session with sudo on the end machine.
Coupled with dired and M-x shell, it becomes a very convenient way of working.
(And in case Tramp causes you trouble, or you just need to close remote buffers and connections, remember about M-x tramp-cleanup-* set of commands.)
EDIT:
And lest I forget - GDB integration works over Tramp too.
I also recommend helm-tramp for added tramp greatness for example if you regularly access many different hosts/VMs.
Question: I often find tramp to be significantly laggy and much slower when compared to simply sshing into the remote host. It is almost as if tramp is opening up a new ssh connection for every command. What do people here do about tramp lagginess? I've researched this problem but I have not found a good solution.
I used it on Windows to edit files on a RHEL machine.
It worked okay, only issue i had is that periodic autosave makes the whole emacs freeze due to network round-trip. Disabling/toggling autosave or lenthening the autosave timeout solved solves the issue.
BTW, tramp is really awesome. One of those pearls within GNU Emacs.
tramp supports a great amount of protocols, but only ssh is on active support.
I worked in a greater company for a while and used it to access remote files shared via windows file sharing (smb). It worked a long time but then server update came, next smbclient update came and at last tramp update came... hindering me in my workflow for a couple of month.
Another subtle but important use of emacs : it is a good playground for (a flavor of) Lisp. Together with the source code galore in site-lisp/, it is a really good environment to learn how a full-blown system can be put together in Lisp. [Hooks, macros, advice - all the goodies to shoot yourself in the foot in that wonderful Lisp way!]
Also relevant is the great article by Stallman on the exact C-vs-Lisp division of labor in emacs. This design philosophy of "bare metal" programming in a fast language + an interpreter for flexibility is also the philosophy behind GNU guile:
“Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it.”
This reminds me of a story I heard that early on at Amazon supposedly the company used applications built onto Emacs instead of building in-house web applications for internal use. I had a chance to talk with an early employee but unfortunately forgot to ask about it.
Search for "Then you know Mailman", and you'll find the bit I'm thinking of.
It doesn't say they built multiple systems around Emacs, but it does say Mailman was built in Emacs Lisp, and that they had people writing Emacs extensions to further Mailman's functionality.
(And that their non-technical customer service folks loved Mailman.)
> [Hooks, macros, advice - all the goodies to shoot yourself in the foot in that wonderful Lisp way!]
You use a very common technique to make the joke, a "turn" so to speak. This makes the joke recursive because it involves Lisp. It's fitting, I just had to laugh!
This is an absolutely insane series of tutorials that will explode your mind and make you feel godlike. If you want to learn why people love emacs so much, watch this.
I used to run http://emacsmovies.org/ and the first video of that was similar to the original article here. Terminology and basic keystrokes. The Emacs refcard whose source comes with Emacs is also quite useful and I usually provide printed copies to all my students.
I have a vendor that actually tries to submit videos as "documentation" for the projects that they work on. I keep telling them that videos are good for tutorials and presentations, but they are not documentation.
I catch it in the SOWs, but I missed it on the first few. They refused to provide written documentation saying it wasn't in scope, which was their right since it wasn't. I have never watched and critiqued videos for completeness before or since, but they would have been better off just providing the written docs, since they spent so much time adding and editing video content. They still try to sneak it in the SOW as if they learned nothing, and now it's just our little game we play.
I started using emacs as an undergrad in the late 80s, as it was the only way I knew of at the time to have multiple windows open on a standard DEC VT-220 terminal. ( I did not know about screen; it was quite new at the time ). I switched to using my UNIX account daily from VMS mainly to get access to this feature that I saw my friends and upperclassmen using.
After I got access to an X11 based workstation in the early 90s, I was so used to emacs that I never looked around for alternatives. I can edit simple files in vi, but I don't use it for anything complex.
The closest I ever got to using another IDE was in the early 2000s when I was tasked with writing drivers on MacOSX. I looked at using Xcode and quickly returned to emacs (mostly so that I could continue to use my X11 focus-follows-mouse environment, and not be forced to sit at a mac).
To this day, I swap my caps-lock and control keys, because that original DEC keyboard had ctrl as the left-most key on the home row. As did the sparcstation keyboards..
Thanks. I remember having to use a third party util to do that on earlier Mac OS X machines, but with the newer Macs you can just switch config by standard system prefs.
At some point I realised maintaining my own Emacs setup was just too much work. I've used a few Emacs setups (Prelude and Spacemacs are the ones I used for the longest) and now I use Doom: https://github.com/hlissner/doom-emacs It's very fast and has a lot of built-in in niceties, and I find it easier to understand than Spacemacs.
If you use Doom make sure to use the develop branch.
Oh man, your link led me to shackle[1] to make transient buffers behave and I have wanted that for... well for as long as I've been using Emacs really, and that's quite a long time now. I don't get how anybody is fine with Emacs' default "let's pop this buffer anywhere, possibly hiding a useful window".
Emacs's default behavior in this respect is theoretically customizable, but the mechanism for doing so (display-buffer-alist) is (to me) incomprehensible. It seems like what Shackle does is provide a clean interface for specifying rules that get translated into display-buffer-alist rules.
Yeah I've tried a few time to customize this behavior over the years and while I did manage to improve it somewhat it's still far from how I'd like it to be.
doom-emacs looks very nice, but development stopped on January? There is an "development" branch, which is ~4000 commits ahead from master. The documentation suggests fetching the master branch, so whats the deal here?
Use the develop branch. It hasn't been merged into master because of long running reworking, but I don't follow Doom closely enough to know all the details.
What part of your setup was taking a lot of time to maintain ?
I find that once I configured something I rarely need to change it. There are some packages that tend to break existing configurations when updated, but that is not something that I do regularly.
There are new packages coming out that are really useful but I'm not going to find out about them on my own. For instance, I didn't know about helm until I started using Spacemacs.
There is a strange editing mode that I stumbled on by myself, which I can do in Emacs.
Suppose I am editing a huge file, and need to make change in some other part without necessarily forgetting where I am. I just open a new buffer for the same file, edit the desired area, and close the new buffer. I have the old position restored automatically in the old buffer. Of course, this can be done to arbitrary number of levels.
This is because Emacs separates the concept of buffer and the file it visits. This is a basic concept, but its use in the above manner is not something I have explicitly seen mentioned.
Do other editors (vi, eclipse, sublime) have similar features?
Every programmer's editor and IDE I've used in the past 22 years has had this feature, all the way back to Delphi in 1996. I don't think Turbo Pascal's text UI had the feature but wouldn't be surprised if it did.
Support varies in whether e.g. lines introduced above the view cause scrolling, or if the views are sticky to relative position, but the basics of multiple editing cursors in multiple views for a single buffer have been pretty pervasive.
Emacs can do far more nice things, for instance meaningful text navigation so you can move not only between lines and columns but also between functions/method/class definitions, scope/context/namespaces, paragraphs, ...
You can edit multiple files at once (for instance if you change a string, like a variable name, in multiple files), you can edit with multiple cursors, record&execute text macro on the fly and with a prefix to transform code/data in a snap...
You can edit file/dirs like text in dired, receive a patch via mail and have it highlighted, applied and committed in a snap... List is long to a point that anything you think if useful probably already exists in Emacs, otherwise you can create it in very few lines of elisp at runtime.
How much time do you need to spend setting up all those possibilities? And figuring out all the little incompatibilities be tween all the plugins and modes, and lisp extensions?
Most of what you mentioned already exists in most IDEs.
In term of "spending" my answer is ZERO, simply because I do not spent time, I discover things casually or when I feel the need of something and it's nearly always there, ready to go in my config (org-mode based) with a quick cut&paste.
Sometime yes, I found a thing that require more investigation or something happen and need action but with modern Emacs is far simpler than undebuggable monsters like Eclipse or Netbeans dotdirs.
BTW there is no difference in terms: plugins, extensions etc; core Emacs is an elisp virtual machine and anything are simply sexps, from my own config to the most famous major mode like org.
About modern IDE: in Emacs I do anything from mail (notmuch-emacs) to personal finance (ledger) to slides (org-mode with skeletor/yasnippet and reveal.js/beamer) to other documents, to deploy documents, live in org via babel, to window manager (EXWM) etc. No IDE or other app exists that can do anything with the level of simplicity, effectiveness and integration of Emacs. Even in terms of mere editing modern IDE are not integrate with anything but barely themselves so you need tons of different apps to do a single thing, in Emacs everything is there.
In terms of time: I was a hardcore vimmer for decades, at a certain point in time I feel the need of something different and I decide to try Emacs. Initially as an editor, after as MUA, after as agenda, after as a file manager, after as a ... discovering new things regularly and ease my life like never before.
The long-time Emacs user has heard this same argument repeatedly for decades, with regard to historic IDEs that no longer exist. How much time do you spend switching to new IDEs every couple of years.
Well, in the past I have used Eclipse, Netbeans, SunStudio (essentially netbeans), IntelliJIdea, Oracle JDeveloper and others: all of them are enormously bugged, perhaps Netbans/Sunstudio was the least bugged. All of them suffer from an ever grown dotdirs that sooner or later brake and you need to restart from scratch...
In Emacs I have had brackeage, and an emacs bankruptcy. But in all case I have recovered anything when I have time simply investigating, when happen if I'm in hurry a quick revert and anything works again.
Exactly. If all those IDEs in the IDE graveyard were so good, why are they dead, while your Emacs is still here?
Too tied to a platform or language, perhaps, and very specific processes related to these? No vision for extensibility or future maintenance?
Sometimes IDEs are very tied to specific target platforms: like IDEs from microcontroller and DSP vendors and such. E.g. if you're programming PICs, you use Microchip's IDE. It provides the image downloading to the target and breakpoint debugging.
Modern GUIs have no extensibility, they are designed from the widget library to the entire software as commercial product, FOSS included because the idea of "modern" GUIs is commercial at design stage.
Emacs, like LispM, Xerox ancient worsktation etc instead was born in a world where software is free, only hardware is commercial. So they are designed from start to be flexible, user-centric, non product-centric.
It's worth remembering an ancient joke of MIT AI lab: An engineer ask few secretaries if they know how to program; they respond no. It ask if they were sure; they respond "of course". As a matter fact they use Emacs and program the mode they need, only no one tell them that's programming, they simply learn how to bend a flexible environment to their needs. Another thing worth mentioned is the classic "In the beginning was the command line" paper, short and nice.
Unfortunately people born in commercial world that do not know IT history can't really imaging that world and it's power. They are incapable of think outside actual business model so they do not understand that other models and software exists...
Hem... We are people, so we are sometimes lovers, sometimes cookers, sometimes fighters, businessman, ... but we are still the very same body. So why our tools need to be divided and confined to a purpose if we are able to craft a single efficient and integrated one?
That's the trouble. It's more flexible than most ides, but you have to configure it, which isn't easy if you lack the imagination or the technical know-how (elisp).
It's not just the technical know-how of knowing elisp. It's also the often arcane ways of configuring emacs and the arcane and often undocumented ways of configuring the packages and plugins and modes that you bring into the system.
The amount of hacks one needs to maintain a reasonably working emacs is mind-boggling, and has nothing to do with imagination. I know, I used to maintain one: https://gist.github.com/dmitriid/4078311
With req-package and org-mode init you do not need any specific hack and anything that does not work remain "isolated".
Many try el-get, borg, ... but personally I found simple setup effective enough and in years my config is now ~4000 lines of org+elisp + few personal packages...
> I found simple setup effective
> my config is now ~4000 lines
We have critical production services which are a magnitude of lines fewer than your "simple config".
There's a reason I linked my own init.el: I'm not talking about something I have no idea about. It's quite short and quite extensively documented. And even there you see: somethign is set as global vars, something is buffer local args, something is inited through hooks, something is inited through hooks and then thorough a global var (doesn't work the other way around), something requires a lambda for a config, something requires a list of values, something is inited through a macro, some are just elisp macros you have to write yourself. And so on and so on.
Once you start extending emacs to be your personal programming environment (especially a multi-language environment), you'll run into exactly what I'm talking about: it's not a simple system. There are the often arcane ways of configuring emacs itself, and then there are often arcane ways to configure the modes and packages. And often these are undocumented, or specific ways to configure them are passed down in oral tradition from one init.el to another.
Even in this post you see multiple people recommending not just differenet packages, but different combinations of packages (each has to be configured separately).
And when something goes wrong? Good luck figuring it out.
That's why I use org-mode for my config so I can set :tangle no anytime, with {use,req}-pacakge I can handle the complexity without feeling it.
Actually I live (in IT terms) in Emacs, from the WM (EXWM(-x)) to MUA (notmuch-emacs) to personal finance (ledger-mode) to document system (skeletor+org+LaTeX+yasnippet) to programming environment (personal use of guile (geiser), hy, python (jedi etc), nim and various shells/DSL language), I administer systems inside Emacs with NixOS and tramp+eshell, I forget the concept of filemanger with dired (and tons of related addons), I super reduce CLI usage thanks to various Emacs packages, I have chat, rss, news all inside all well integrated... Yep, the start give me some frustration, I have a config bankrupt but after that things goes far smother than any other environment I have ever tried.
And yes, the config is big, but I do not made it before starting using Emacs, it evolve regularly in the time as I need so it's length and complexity have essentially no weigh. When something goes wrong (essentially after an update) I simply rollback and keep working until I have time to investigate. No real interruption, nothing like Windows update during presentation we all have seen.
Sometimes I have encountered "strange" bugs, the last few days ago that doom-modeline break notmuch-mua-new-mail: I quickly rollback and do my stuff; in a moment of free time I try to figure out what happen and yes I encounter some difficulties (my knowledge of elisp it's not well enough) so I simply ignore the problem. Yesterday I update again and the problem was gone. Long-story short in many case a problem is not only mine and tons of people working on Emacs find and debug it :-)
My complaint: emacs requires a lot of configuration that is often arcane or poorly documented.
You: but it's so simple! I only use notmuch-emacs, and ledger-mode, and skeletor+org+LaTeX+yasnippet, and geiser, and jedi, and tramp+eshell, and dired with tons of related addons, and..., and..., and..., and...
Something tells me you just reinforce the point I'm making. I personally have a life outside of looking for and configuring dozens of emacs packages in a hundred different ways.
I never quite got that. What is the advantage of doing everything on your PC with Emacs plugins, instead of using dedicated programs for specific tasks? I get that the text editor for all these tasks is behaving the same way when going the Emacs way - is that the only advantage though?
This is exactly what keeps happening to my emacs. I have tried emacs in 3 or 4 periods for work and home use. Every time, I add useful things to my config until something breaks, I try fix it and maybe fail or partially fix it.
I eventually give up. Latesty try was with spacemacs, which I quite liked. It gots so broken it refused to start up and I never even really bothered fixing it. I tried VS Code and that is where I am at.
Now my VS Code is getting slow, and Iv'e already had some problems extensions!
I have experienced far in the past a similar situation, I've tried both Emacs and XEmacs at that time and give up sticking to vim. After, time ago pushed by curiosity and few demos I casually see I tried Emacs again but with a far slower start, only as a side curiosity and a step at a time I grow my config keep using (n)vim until I decide it's time to jump. After that I still experience some problems but I keep evolution speed slow to avoid frustration, in few months Emacs became my environment.
Maybe you have tried Emacs as an editor expecting to been able to use it quickly as other "editors" you already encounter and that cause the fail. Emacs is an OS, not an editor, an ancient one that have some idiosyncrasy because of that vestige. And we know that learning an OS is not as simple as learning a single-purpose application.
In vim, I use vsplit to open the same file, make my edit, and close it. tbh, it's faster to mark my spot with m[az], make my edit, and return to my spot `[az] ([az] means any lower case letter).
What you describe can also be done with one buffer and multiple windows that show the same buffer, and I do this all the time. The position of the cursor is associated with a window when multiple windows present the same buffer.
The fact that Ctrl-O and Ctrl-I exist is just a tiny example of why the modern editors just can't compete with vim and the plethora tiny productivity features it has.
Hardcore vimmer here, but I don't think you're right. I know at least VSCode has this functionality and probably other editors as well. I don't use vim because of it's features but more because modal editing and the keybindings are cemented into my muscle memory. There's also the extremely lightweight nature that let's me have several projects open in vim at once with little resource impact. Were I to start over today, I might pick VSCode and be just as happy.
I respectfully disagree. I think VSCode's ergonomics pale in comparison to Vim. I just mentioned Ctrl-O, but there's a hundred little other features that I use constantly that VSCode doesn't have, and even if it does, it executes them much slower than Vim does. If Vim's plugin system was improved, it would blow VSCode out of the water.
Then you may find the "narrow-to-region" command useful too. It allows you to select a region of text, and make everything else in the buffer invisible and unmodifiable.
I find it useful when trying to grok a specific function without getting distracted, or more usefully, doing a search-and-replace without fear of doing a replace in an unintended part of the buffer.
You can do the same thing in vim by opening the same buffer in another split. Very useful for editing in multiple places without having to keep jumping around.
I think buffers/splits are considered a better option than tabs for this use case? I believe tabs are more for layouts of open buffers in splits rather than like browser tabs.
About four months ago I moved from VS Code to Spacemacs and it has been an extremely rewarding experience. Anyone who is afraid of Emacs or Vim should give it a try. I've heard good things about Doom and Prelude as well.
I used the "learning by doing" approach by forcing myself to use Vim to write C and Python at work.
I had two main reasons for learning Vim: (1) Vim is everywhere, so it must be worth it to learn the basics at least; and (2) modal editing felt easier on my wrists than the standard mouse + shortcuts approach I ended up using in other IDEs.
Here is my advice:
1. Start with only a theme in your .vimrc, so no plugins or non-standard key bindings.
2. Use Vimtutor (or any other tutorial) to learn the basics: normal vs. insert mode, movement, manipulation, yank/paste (+ clipboard), splits, buffers, and searching.
3. As you write code, you will find yourself wanting to know how to do X. This is where Google and a simple "cheatsheet" file come in. Once you find out how to do X via Google, add an entry to your cheatsheet file (example in HTML form: [1]).
4. In many cases, you will find that a plugin will solve one of your issues. Install that plugin and add it to your .vimrc. I recommend vim-plug[2] for managing and installing plugins.
5. There are many useful plugins out there. Two I would strongly recommend: CtrlP[3] and NERDTree[4].
Once you have a good grasp of Vim, I would recommend exploring Emacs + Evil-mode if you want a more complete IDE experience.
I personally don't know much about VS Code. All my keys for openings/searching of files are very centered around emacs.
In short:
macros: I can turn a column of text values into a single line of a json array with a few strokes. Also more complicated formatting that has some pattern like:
var some-column = 1;
var some-columntwo = 2;
Into formatted SQL queries or inserts, or more json with little effort. Not an issue with 2 columns, but with a hundred....
Interaction with the shell: I can do the above with curl or reading from a file so I don't have to leave the editor and download and open the file separately.
Did you have previous experience with emacs? I'm a long-time emacs user, but have been assuming it's better to introduce new people to VS Code since it's more mainstream.
I started using Emacs a few months ago and I love it.
I think I'd struggle day to day now without Org Mode. I love how easily I can switch from something in Org Mode to something like a Clojure REPL, then to a Powershell window and to a text editor.
If I can just get it doing C# editing / compiling I'd be very happy.
I started working in a .NET shop a few months ago and have finally sorta-kinda gotten my Emacs configured the way I want to in terms of C#. If there are any specifics you need help with, shoot me an email or something!
Have you ever managed to get intellisense working for c#? I try every few months with junk like Roslyn but it never seems to work. It just silently fails to do anything at all.
That was tricky to get working well, and for a while I hobbled along with gtags... but I do have it working now. And it wasn't that complicated, I was just missing an embarrassing piece of the puzzle.
I really feel VSCode is lining up to be the new goto IDE across multiple languages.
Slightly less (directly) extensible than Emacs but still feels it can do pretty much everything that needs doing, plus way nicer & friendlier default UI.
VSCode has very much opposing philosophy to Emacs. It's a Microsoft product and it shows, they don't have standard concept of buffers/windows, so trying to do customization is ugly.
For example, you can't easily implement a shell which moves around the windows and can also sit on a side, because windows and sidebars are totally different concepts in the code.
VSCode depresses the hell out of me, it's almost a summary of the bad things of open source.
Open source but most people will download it with spyware
Open source but not really built as a nice platform to be meaningfully extended
Open source and controlled by a single company
Open source and used cynically as a wedge to pull developers into your orbit
Open source and not at all written from an extensible mindset, just enough extensibility to trap people in
Open source and will dominate other offerings because it has a big name behind it, so damages atom/emacs/etc
Open source and pretty much an inferior copy of an existing thing (Atom)
Developers who are proud of using VSCode baffle me, have a word with yourselves.
1. Kind of fair, it's better in some ways and worse in others. I would emphasise extensibility (this is after all an emacs thread) so I'd call it worse. You don't seem to dispute that it's a copy (in terms of engine/approach)
2. Same as 1, having read the issues and some of the source I stand by the statement.
3. Ask yourself why else Microsoft would build something
4. Fork it is naive to the point of being dishonest. You cannot outfork something with 10 professional developers, unless you're Stallman doing it full time.
You only disputed some of my points, "most people will download it with spyware", "it will damage existing more truly extensible efforts" seems to be a pretty key ones you haven't disputed. If only those two were true it would be enough for me to dislike it.
Design choices are not always bad. And Open Source != not being opinionated.
Regarding the spyware thing, agreed, but at the end of the day, the makers choose how they distribute the thing. It's just like Chrome and many other products.
I, for one, am thankful that they're making available a high quality tool for free.
Not an user of VSCode, but what you wrote applies to a lot of corporate-backed open source products. Try to replace VSCode with Chrome in your post, it will probably even more apt.
Lots of editors out there are nicer and friendlier than Emacs. Most of them eventually fall out of fashion.
I was using Emacs when Textmate was the hot new thing. The Sublime came around. Then came the first Electron-powered editors like Atom and Brackets. Then came VSCode. While people kept chasing these new editors, I've been using Emacs for more than 10 years. I'll be still using Emacs when the hotter, newer thing eventually comes around.
VSCode is the first editor I've seen that has made me think maybe I'll move away from Emacs at some point.
I think a fully tooled-up Emacs setup in the hands of an experienced user is still faster and more powerful but I do wonder if Emacs will be able to develop fast enough to keep up with the cutting edge.
As an Emacs user I'm mostly "afraid" of VSCode getting so popular that people will make cool tools targeting VSCode only. Like, it'll become the Chrome of text editors.
Editor trends seem to fairly volatile. Textmate was the new shiny favorite until it wasn't. Sublime was the new shiny favorite till it wasn't. Atom was the new shiny favorite... etc.
Those had all legit flaws which prevents wider usage, like being limited to one platform, being commercial or slow or dead... They all lakc in concept, because they are editors first, and not much of an IDE. VS Code is the first who actually avoids all the flaws. It's flexible, yet still quite fast, relative tame on RAM, yet full of IDE-features, running on all platforms and cost you just some privacy if you don't know about the data-collecting.
Additionally, it sparked the LSP a movement which is benefitial for all editors/IDEs, and we will see how much more will come from this. So even if VS Code itself will lost traction, it's heritage might prevail. But overall the specs so far look very healthy for a project in that realm, and chances are good that it will stay for a while.
Emacs hasn't been really mainstream in quite a while and it's still actively maintained and improved upon. I'm not too worried. A small-ish skilled community is enough to keep the project going.
What's VSCode's market share anyway? Is it really that big? I've never used it personally and I had no idea it was so popular.
> A small-ish skilled community is enough to keep the project going.
The trends of the last few years are worrisome, though, particularly as regards the pool of developers who can work on Emacs core (the part written in C). Right now there's only one dev who's in a position to do non-trivial work on the display engine, and he also took on primary maintainer responsibilities a couple of years ago. When he burns out, the project is going to stall, hard.
Stefan Monnier, who was maintainer for most of the past decade, perceived this trend very clearly and was vocal in trying to recruit new talent. He didn't get much cooperation from other core devs.
It feels like Emacs Developers are actively tries to shoo away modernization and people who do not want to put in hours trying to actively learn just Emacs.
At one point I tried using Emacs for everything but it didn't work out for me. Now I still use it but only for tasks management and coding.
Unless you want to spend hours of your time customizing it and then a lot of other person also does the same customization. This just ends up wasting a lot of time overall.
For me Emacs lacks the following and I think others will have the same feeling:
Obscure Terminology
Documentation is all geeky with terms like frames, META, kill ring etc. This creates unnecessary friction for a new user. Basics of ELISP can be learned rather quickly but trying to apply it while grokking the tersely written documentation is just discouraging.
Sensible Defaults
Simple things CTRL-C, CTRL-V does not work out of the box.
Mobile Interface
It is an error not to provide a facility to interface with mobile devices natively. I get full Emacs can be invoked via termux on any Android device. However, it is just unusable and irritating. Orgazly and likes also not very useful.
Well the problem is that people caring about Emacs have learned a long time ago what a kill-ring, the point, the cursor and meta mean in the context of Emacs. In its defence, a lot of that predates modern user interface conventions. Changing this lingo would probably make it more approachable for newcomers but it would confuse experienced users. On top of that you can be sure that not all elisp out there will be updated quickly (if ever) and you end up with two different words for the same things in different docs which is not exactly a win for anybody.
Beyond that Emacs's docs are unparalleled in the editor world as far as I know, you can explore pretty much any functionality by calling "describe-key", "describe-mode" etc... Even decades later very few (if any) editor can rival the flexibility and self-documenting nature of Emacs.
Regarding key bindings I agree that it's definitely a pain point for newcommers, it's just too different from the modern standard (while not necessarily being better. C-_ for undo? I got used to it but it's hard to defend). Unfortunately making a complete new set of bindings that would play nice with 3rd party packages is probably very difficult.
> Well the problem is that people caring about Emacs have learned a long time ago what a kill-ring, the point, the cursor and meta mean in the context of Emacs.
Those people are not going to live forever so if Emacs wants to have fresh blood inducted then a gradual modernization would not hurt. I think even Richard Stallman agrees[1] to some of it.
> Beyond that Emacs's docs are unparalleled in the editor world as far as I know, ....
I agree Emacs have documentation for almost everything but I disagree on the quality of documentation. For example when I pull out a documentation Most of the documentation describes what the argument should be which is anyways clear by looking at the argument list. It would be much better to include an example instead of describing the arguments verbatim.
It's just my impression, but for the new generation of developers "born" into a js-first world it's pretty much the primary choice. And again I don't have numbers but it does seem like the new generation is MUUCH larger and much more active on mainstream social media.
Hacker news must seem like what slashdot seems to me.
I can see a situation where 0 users switch to VSCode and in a few years it still has, say, 80% of market share, just by getting all the new ones.
> And again I don't have numbers but it does seem like the new generation is MUUCH larger and much more active on mainstream social media. Hacker news must seem like what slashdot seems to me.
Part of it can be attributed to growth. If the population of programmers grows by 100% every 5 years (an estimate I remember reading somewhere), then at any given time, half of the workforce has at most 5 years of experience. This explains why our industry seems to be so full of "js-first" developers - because in fact, it is.
Yeah Visual Studio Code drains battery, CPU and memory. Emacs is extremely resource-efficient, it's probably around thousand times more optimized than Visual Studio Code
> it's probably around thousand times more optimized than Visual Studio Code
I am not saying that VS Code is everyone's answer and choice but VS Code is resource friendly enough. Who cares about the resource difference between EMACS and VS Code in real world practicality? I know people love to bash anything electron but it really isn't anything to worry about when programing with anything that is 6 years old or newer.
VS Code is immediate and responsive on my Dell at work (10 years old) (I refuse to give it up even though I have several more computers but everyone needs a spare computer) what do we need besides that in terms of resource-efficient now a days? I know that it use to be a big deal and I propose that its a non-factor these days.
> Who cares about the resource difference between EMACS and VS Code in real world practicality?
I literally use different apps on battery vs wall power:
wall: Firefox, Slack, VSCode
battery: Safari, mail, Emacs
The difference is clear as night & day. Mac OS X has a tab in Activity Monitor where you can observe energy impact of different apps, and it consistently reports Electron apps as... psychotic. An order of magnitude (10x) more intensive than their native counterparts.
But what real world difference besides some battery improvements. They are both fast in terms of responsiveness and I find VS Code to be much easier to customize and get up and running.
I find Sublime is really great for battery. I can work 10-12 hours some days with a dim screen and with wifi turned off using Sublime. I imagine emacs is even better,
I gave emacs another try earlier this year. First vanilla, but then I missed vim keybindings so I installed evil. Then I switched to spacemacs. Eventually I decided I was barely using any emacs-specific features and just went back to vim. Vim feels so much snappier. I do miss some of the more ide features (jump to definition, execute selected code) but it wasn't worth the overhead, imho.
I am in kind of ranty mood, so forgive me if I take this opportunity to do a brain dump on you. Just to be clear, while I have my preference, I very much respect the fact other people will have different preferences. If vim makes you happy, by all means, use it!
I came full-circle, starting out with emacs, then discovering vim, then returning to emacs after a few years. Both are great editors. I love vi's command language, it is so concise and powerful. At work, I have been using Visual Studio a lot, recently, and installed the VsVim add-on, after looking for something emacs-like without success.
Vi rules because it is simply awesome at editing text; it is very Unix-y that way: Do one thing, but do it really well. I still use vi regularly to quickly edit a config file or something like that.
Emacs rules because it is awesome at integration. With emacs, I can write some Python code[1], start a Python REPL, load some of my code into the REPL and play around with it. Just as a simple example. I can start an SQL session for various RDBMS inside emacs buffers. The list goes on for as long as one can come up with new things to do inside emacs. The big payoff is that that all the muscle memory, all the keyboard shortcuts, all the hooks and customization work consistently across all those things.
This is also, why IMHO it takes a relatively long time for emacs to pay off, but once you reach that point, the payoff is phenomenal!
In Visual Studio, I am glad that I have VsVim: Intellisense is awesome, and VS is a great IDE, but the actual part of editing text, which is still a significant part of programming, kind of sucks. VsVim made that a lot better.
[1] Just an example, I have not actually written any Python code in years. But I think this more or less works for most languages that offer REPLs.
I completely agree, but I have the os do that. Except on my iPad where I am grateful for blink to have that capability.
On windows I had a special mode for caps lock via autohotkeys. Press and release meant esc. Press followed by another key and release was ctrl-key. I really liked that, but I couldn’t do it on Mac or iPad so I just settled on ctrl.
I did the exact same thing. That's the same reason I do most dev work in vim as opposed to an IDE too--input lag jerks me out of flow state faster than anything else. Plus, vim emulation modes like evil and vscode vim don't duplicate all vim behavior, and if you've been using vim a while it doesn't take long at all to find the rough edges. Sure, vim isn't perfect, Lord knows vimscript is a dumpster fire, but for me at least, it is the best tool for the job 95% of the time.
I was just reading the New Yorker article about the partnership between Jeffrey Dean and Sanjay Ghemawat at Google [0]. I noticed this about Ghemawat's setup: "There were four windows open: on the left, a Web browser and a terminal, for running analysis tools; on the right, two documents in the text editor Emacs, one a combination to-do list and notebook, the other filled with colorful code." (Emphasis added.)
I'm guessing the "combination to-do list and notebook" might have been org-mode?
OK, question from a fellow Emacs user: If a student asked you which text editor / IDE they should learn _ab initio_, would you recommend Emacs without reservation?
I'm not sure I would. I'll certainly never stop using it, because I've got 15+ years in it now and the key bindings and my config are as automatic as breathing. But I wonder if the investment is worth the cost for a new user, who could just use another excellent editor that's maybe a bit less full-featured but with a drastically shallower learning curve?
CS student? Yes, without reservations. And any other student probably as well.
Emacs is not a program just for coding. It can be used for anything that can be expressed in a text oriented way: writing a book, a thesis, an email, etc. And most editing commands work in exactly the same way in those contexts.
> if the investment is worth the cost
As you said: 15+ years. And that's not really any sort of exception in the emacs world. Of all the software in existence, I'd say emacs is one of the most likely not to stop development in my lifetime, or the lifetime of anyone alive today (and I'm not even talking about being able to maintain it yourself if push comes to shove).
So for anyone serious about writing anything at all, emacs is never a bad recommendation.
I have heard people say Emacs is an OS, just needs a decent editor.
To me it is a textual interface, or a text based toolkit very much similar to Gtk/Cocoa/Qt. It provides you with an environment on which you can build upon with Lisp.
Correct me if I'm wrong, but the first two minutes is him trying to find an instance of like, a variable or something, and he individually goes into a bunch of files one by one and does a text search, then eventually pulls up a third-party file search tool outside of emacs to do it.
On Jetbrains IDEs I would just hit "shift-shift" and get a project-wide search dialog that searches across all of my files and even tells me what kind each instance of the text string is - variable, class, etc - as I'm typing.
In any case, "M-x helm-projectile-find-file" is the Emacs equivalent of IntelliJ's shift-shift. It's nicely bound to "SPC p f" if you use Spacemacs. You can also search tags (variables, symbols, classes, etc) with "SPC p g". Plus, going for a 3rd party search tool is personal preference, Emacs can also do that.
I'm a heavy user of both Spacemacs and IntelliJ, and while the quick search interface of IntelliJ is awesome, Emacs also has this functionality. I assume Jonathan's problem in that video is due to poor language tooling, plus his personal workflow preferences.
I find Jon enraging, especially when he whines about Emacs: a number of the things he complains about are either fixed in newer versions of Emacs (he's still on Emacs 23) or packages offer a vastly improved user experience.
Impresive as a developer but not as an emacs power user.
One thing that makes me very nervous is seeing someone moving the pointer char by char. Do yourself a favor, learn how to jump around!
I used to be a heavy emacs user, but I've mostly abandoned it because I'm lazy.
It takes a fair amount of effort to keep up with new environments. If I change jobs (which isn't infrequent), I'll need to reconfigure a lot of the setup to work how I like. Packages upgrade and break.
For me, I just found the amount of effort it required to keep the environment set up nicer than, say intellij, just wasn't worth it.
Nowadays, I mostly use VS Code for a text editor, and intellij for larger codebases. I still drop down into emacs if I need to do serious text manipulation or weird git stuff, but that's about it for me.
One point any beginner's guide should mention is that the basic Emacs navigation and kill-ring keys are also used in common utilities. The info command is derived from emacs, but they're also used in Bash and less, and support is fairly common in text editors and IDEs. As a beginner, you'll get used to them much faster if you use them in more places than just your editor.
And Mac users should know that Mac OS X has had basic support for Emacs style editing in native controls, inheriting it from NextStep.
Even though this is a beginner's guide, I feel it should introduce the reader to the Emacs way of navigating using the C-`b f p n` keys at least, let alone their M-[] alternatives. These would significantly improve the users ability to move around the buffer without having to keep shifting hand position to the arrow keys.
I've been using Sublime since I started and have no complaints. That being said I always hear about emacs referred to as the OG. I know there's positives and negatives to both, but is there any pressing reason to switch from one to the other?
With emacs/vim (etc) you can edit text from within a terminal, which becomes quite helpful when you SSH in somewhere. Also, with a terminal multiplexor like tmux or screen you can also easily jump from shell to shell, which has personally improved my productivity substantially from when I was using GUI based text editors like Sublime or Notepadd++.
> With emacs/vim (etc) you can edit text from within a terminal, which becomes quite helpful when you SSH in somewhere.
A very underappreciated functionality. Over the past few months, a good 30% of my work was done this way - by SSHing from my el cheapo Windows 2-in-1 to my much more powerful Linux desktop, and using Emacs in terminal mode. With terminal set to xterm-256, it looks almost as if it was GUI Emacs, and has almost all the same functionalities available. I'm a remote worker now, but this workflow adds an extra order of magnitude more flexibility to my work day, as I can leave my environment running when I go on an errand, and pick the work up in a long queue, or on a bus.
It's one small thing, but the power of Emacs is really in how all those small little things compose together into a powerful environment you can use from almost everywhere, and on almost everything.
I've been using vim for a couple years now. I mostly use it for programming in C/C++/Python. Is it worth it to learn emacs or should I just stick with vim?
Yes. you can use org-mode to create a living 'literate code' document of database connections and queries. You can then execute the queries directly from this document.
Yes, it is. You will benefit greatly from the tight integration between shells, remote file editing, database support (albeit fairly simple, compared to dedicated tools) and obviously an excellent editing environment in general.
Absolutely. While I've been trying to do more coding in emacs, I primarily use it for various interactive shell stuff, file management, project management, time tracking, todos, calendar, journalling/loggin, and the occasional remote file editing (Through the TRAMP package).
I have used notmuch for years now and see no reason to stop. Be warned, however, that it does require you to set up some tooling outside of emacs as well.
I've heard developers say this before, they want tab bars or good fuzzy search. The puzzling thing is, I feel almost exactly the opposite. I've used many other development environments (over the last 50 years), some for years at a time and others on off for many years: Intellij, Xcode, Adobe products, Textmate, Vim, etc.
These other IDEs and editors certainly have their own strengths and are in some ways better than Emacs for some tasks, but for navigating between tasks, projects, and recently used files Emacs is the best tool I've ever used.
To visit a file, whether for the very first time or to just get back to the previous one you were using, the find-file command is Ctrl-X Ctrl-F. This does exactly what I want about 90% of the time. I type a few letters and because of completion I get to what I want in an instant. This command is one of the first ones that beginners need to learn to open a file for editing. It's trivial to rebind the visit-file command to any key you like (Spacemacs uses Space-F-F). You might be thinking, "Oh yeah, but sometimes I want to open a file read-only", well there's a command for that too its find-file-read-only, bound to Ctrl-X Ctrl-R. Or maybe you're thinking, "What will I do when I want to insert the contents of a file at the cursor?" maybe Emacs won't work for me since I do that a lot. The good news is: there's a command for that. You might be thinking "Thats swell, but sometimes I need to see the file contents in hex!", well there are commands for that too.
On my system there are almost 500 available Emacs functions containing the word file. I was able to find that out with the built-in documentation that gives me access to descriptions of all these functions and key bindings in just a couple of keystrokes (C-h starts the best built in help system I've ever used, period. You can even jump into the code that implements all of these functions.) I recommend sticking with the simple find-file command for a week or two before delving into the many fascinating options available for the Emacs hacker.
If you want to actually see the files that you have already been editing, Ctrl-X Ctrl-B lists the buffers in use. This is a bit like looking through tabs, but Emacs manages hundreds of simultaneous buffers at once and some users like using the buffer list to see all of the current work across many tasks that have been going on over a period of weeks. You can navigate rapidly though the buffer list and pick a buffer to be displayed in your current window pane or other panes or windows. Jumping between buffers, windows, panes within windows is all done with a couple of keystrokes so its fast and easy. If you know the name of the file/buffer already you can use Ctrl-X B, the switch-buffer command to open it directly without browsing the buffer list.
Maybe it's not a current file you want and maybe you don't remember the name but you do know where it is located. The amazing dired interface displays directories and makes it easy to list, rename, or edit (or copy or change permissions, etc.) the files within a directory or it's parent directories or children. Again the interface is right from the keyboard so it is very fast and easy. Dired opens automatically when you do find-file on a directory name. Sensible name completion and shell like navigation make it easy to get places in the file system or remote file systems though the magic of Emacs ability to treat file systems on remote machines like local files if the user has ssh access. Dired is great, there is nothing like it and its various extensions provided by the Emacs built in package system.
These simple to use commands and a couple of commands for splitting windows into panes and jumping between them will get you a long ways and in no time you will discover that you don't miss tabs anymore. I really appreciate the extra screen real estate I have because I don't need tabs or tool-bars in Emacs. I can easily see three or four files at once since the navigation buffers for dired and buffer lists open only when needed.
I know, you're maybe wondering if a form of Emacs Stockholm Syndrome has me under it's spell: windows, panes, buffers, files--it just sounds confusing. Yes, tabs are a simpler idea. Emacs has been around so long that its nomenclature is a bit archaic. What a normal developer would call a window is a "frame" in emacs. I usually like to have a single large frame while I'm using emacs, but you can open up a multiple Emacs Frames, say on different displays, and hop between them with a keystroke or two. Sometimes that's helpful.
Inside a Emacs Frame you can have multiple re-sizable horizontal and/or vertical splits that give you a number of separate panes for editing in. I usually have two or three while I'm working. They work great and are easy to use with a few of the built in commands. The biggest problem is that Emacs documentation calls them "windows". So in Emacs terminology a Frame contains Windows (in modern terminology we would say the Emacs windows can be divided into panes or regions).
A Buffer is just an editing session (usually, although documentation and system information is also held in buffers). The buffer has a cursor and some other features and is usually associated with some underlying file, but the buffer can be written to a different file (kind of like Save-As) and now it becomes associated with the new file name. Multiple buffers can be opened against the same file providing different views of the the file and they can have different cursor positions and different editing modes. Is a buffer also an Emacs Window or Emacs Frame? Buffers exist independently of the user interface to the buffer. When you open a file in a new buffer or switch to an existing buffer for a file, the buffer is presented for editing in one of the Emacs Windows in one of the Frames. The default is the current Frame in use. This makes switching to a buffer like clicking on a tab. But the architecture is more flexible.
The commands I've mentioned work in default Emacs right out the box. More experienced users like some of the fancy searching and auto-completion packages like helm or ivy. There are also speedbars for those that like to mouse-click on a project directory outlines and sophisticated project management tools like projectile with fuzzy searching across the files withing the project. These add on packages are so easy to add that the real problem is having too many features available.
I should mention that there are many fancy fuzzy search tools, but I really don't use them myself, I get by with the basic functions provided by Emacs for grep'ing and searching. And if you still want tab bars there's a package for that, tabbar mode.
Related to project management and along with org-mode one of the most recommended Emacs packages, magit, a really great interface to git that is very well integrated with Emacs.
- Tabs are not present in Emacs, but C-x C-b will list all open buffers
+ Fuzzy file search : you can take a look at the popular Ido-mode
+ eshell is pretty powerful, if you think about it, you have all the emacs search functionality etc. available in a shell inside the editor itself.
I am not trying to popularise emacs, but "inflexible" is not something that you associate with emacs. If anything, it is the bewildering array of choices that is one drawback. Plus, you should really try:
+ org mode : what is the standout feature now a days. You can even do literate programming in the org mode, so can be viewed as an alternative to Jupyter, for example.
The real gripe for me about emacs is that it is single threaded. So a long grep launched off will freeze the entire editor.
> The real gripe for me about emacs is that it is single threaded. So a long grep launched off will freeze the entire editor.
Are you running grep with `shell-command` (M-!)? Using M-x grep, `async-shell-command` (M-&), and invoking grep directly in shell, eshell, term and ansi-term all leave emacs as responsive as normal for me. shell-command is the only one that seems to hang.
I'll also add ivy[1] and helm[2] as alternatives to Ido which are very popular completion systems with integrations that span the package ecosystem.
> - Tabs are not present in Emacs, but C-x C-b will list all open buffers
I want a passive, not an active interface. I want to be able to visually scan the tabs. I want to be able to click them when I'm not in the mood for keyboarding. I want the tabs and the tab bar to not be ugly as sin :) Etc, etc. Heck, if Vim has them built-in (and Vim also has the same concept of buffers as Emacs), surely Emacs could (should?) have them.
> Fuzzy file search : you can take a look at the popular Ido-mode
I know there's modes for that, but open up a folder in VS Code. It's seamless, I don't need to configure it, it just works, they bundle ripgrep for me, etc. The UI/UX are also slick.
> The real gripe for me about emacs is that it is single threaded. So a long grep launched off will freeze the entire editor.
Yeah, Vim is kind of like that, even though it's recently gotten async.
You do not need to see what "tabs" are open at all times. You only need it when you want to switch. It's also incredibly limiting. At this moment I have 127 buffers open in emacs. How would you deal with that?
But your eyes don't. You do not need it to be there at all times. But you'll refuse to try anything else and see that I'm right.
Emacs can do whatever you want but almost every single user switches off the permanent tabs, buttons, scroll bars etc. as soon as they realise they can because it is unnecessary.
>I want a passive, not an active interface. I want to be able to visually scan the tabs. I want to be able to click them when I'm not in the mood for keyboarding
Ibuffer is included in the gnu Emacs distro and does all of this.
It's true that tabs would be nice sometimes, but usually Emacs users have lots of files open all the time. The usual open-edit-close workflow doesn't really apply to Emacs sessions. An Emacs tab bar would resemble that of a browser with 100+ tabs, so the problem is that the people that would be capable of implementing that feature wouldn't use it in the end.
> * super powerful, easy to use, integrated command and fuzzy file search, also with a good UX.
Sounds like you should try ivy and its companions. Ivy offers fuzzy matching for all operations in Emacs (e.g., switching buffers, opening files, looking up documentation) and the counsel packages (e.g., counsel-rg) use that same interface to interact with external tools such as ripgrep or git grep.
Ivy has completely taken over my Emacs experience, and it did not require a lot of configuration, just a few keybindings.
As for a terminal, I don't have a Windows machine to test, but `M-x ansi-term` is pretty much exactly like a regular terminal: you can run any program in it, including htop or even vim.
EXWM/Fulltime Emacs user here... Well... No, ansi-term, sane-term etc are not like regular terminals, they can work for simple things but they are limited, limiting and buggy...
When I start living in Emacs I reduce significantly the dependency of the shell (tramp and dired do most of the business) and start using eshell a bit, but I still use terminator when I need a real terminal...
For all its flaws, the VS Code terminal is quite strong. I've been putting it through its paces recently and if only they'd offer an option for real full screen and proper splits, it could almost get all the way there.
There are very few respects in which Emacs is less functional than other editors (good integration with semantically aware refactoring tools is the primary one, imo), and it has excellent support for the only functionality you explicitly mention (command and fuzzy file search).
Honestly, I've opened that page expecting to see a "Don't!" or "Use Vim instead" message...
The different between Emacs and Vim tutorials nowadays is that, while both of them have a section about how to open it, only vim has a section about how to exit it
</joke>
Ok, that's all I had...
That said, I still think that both vim and emacs are going to lose the battle against those fancy-new-shinny-atom-sublime like editors eventually. Which is sad (I'm a vim user), but no one wants to memorize lots of short cuts anymore.
For example I am currently using Org mode to write some documentation complete with hyper-links, tables, foot notes and the option to export the results as LaTeX, HTML, Open-Office, and so on with just a few keypresses.
It's not just an editor, or an IDE, or even a windowing system - it is a cross-platform computing environment that can be fashioned to exactly suit whatever purpose you require.