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.
During the upcoming holidays, I should try to explore and "stumble upon" advanced features and neat tricks that I haven't come across yet.
"For instructions on how to integrate Remember with Org Mode, consult Capture"
Okay, let's go and read the documentation of Capture; 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'd like to add a note: time can't be only measured in hours, days, etc. To learn Emacs enough to decide that's the way I'd like to interact and use my desktop it take a very little time, in around three month I start using Emacs as WM (EXWM), MUA (notmuch-emacs) in around two months with a "false start" on Mu4e, main docs solution, tramp, personal finance (ledger) etc
But the real point is: I do it when I like to do, as much as I like, in my free time. In other words I can start easily and grow as I wont and need, and this knowledge will survive for decades to came.
With commercial software you need to invest time (and money) before start, and after having reached a certain amount of knowledge you can't go further, you have to keep yourself up to date following upstream changes and you new knowledge have a very little value in the long run.
That distinction is important because too many people say "hey it took too much time to proficiently use FOSS" completely ignoring the big picture. Good time to learn FOSS is at school, when you have plenty of time and (in theory) you are willing to learn, after you get the benefit for the lifetime. Another good time is when you feel the need, in free time. You do not have to pay something in advance, you do not have "training", "diplomas" etc, you grow at your speed and desire, limitless.
That's the real matter, not how many hours.
How's that different from learning to how use FOSS? Except the money investment part.
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.
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.
- major and minor modes,
- special, regular, mini and read-only buffers,
- backup files,
- mark and kill rings,
- the difference between C-x and M-x,
- mode line,
- and whatever else there is in emacs' configs, packages etc.
I dunno. Perhaps in emacs lingo "standard" means "no one uses these terms anymore"?
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?
> 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.
> 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 ...?
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.
(setq package-enable-at-startup nil)
'("melpa" . "https://melpa.org/packages/") t)
;; Bootstrap `use-package'
(unless (package-installed-p 'use-package)
(org-babel-load-file (expand-file-name "~/.emacs.d/myinit.org"))
then you can put your configs in an org file. using `use-package` means I can just copy/paste the file to new emacs and all my packages are auto installed etc..
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.
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.
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.
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 :-)
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...
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.
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.
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.
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.
CTRL-X CTRL-F then => /ssh:firstname.lastname@example.org:~/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:
as if they are local. Merges/diffs all just work its really great.
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.
Format is C-x C-f /gcssh:compute-instance-name:/path/on/remote/machine/filename.txt
To that, I usually bring up tramp and say, who cares you just ssh in from emacs.
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.
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.
Again, I'm saying that as someone who uses tramp-mode all the time, otherwise.
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.
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.
mg, I don't know!
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 :)).
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:email@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.)
And lest I forget - GDB integration works over Tramp too.
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.
This helped me quite a lot with tramp
Is there something beyond that I should be doing? Does tramp need to be configured in some special way to take advantage of the persistent connection?
FYI: You can set it up to use the container names:
M-x customize-variable docker-tramp-use-names
- edit over tramp
- dired over tramp
- magit over tramp
- build over tramp
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 actually does something more clever than an scp too, so it even works on servers that don't support scp.
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 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..
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.)
Edit: found more-canonical URL.
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!
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?
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.
Well, Emacs is older than all of them.
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.
Most of what you mentioned already exists in most IDEs.
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.
Meanwhile I've had emacs configs fail in subtle and not-so-subtle unpredictable ways with every system or emacs, or mode, or... update
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.
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.
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...
Emacs on its own is nothing but a fancy extensible notepad. The things that make an IDE come and go in the emacs world, too.
> 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
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...
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.
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 :-)
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?
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!
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.
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.
Word and Excel (and probably other Office apps) have the same. You can edit one part of the document while viewing another part.
I imagine the vi solution (if it doesn't support that) would be marks.
is another way to do it.
I've tried Vim a few times but got turned off by the slow process of learning the multiple keyboard shortcuts to do a simple task.
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: ).
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 for managing and installing plugins.
5. There are many useful plugins out there. Two I would strongly recommend: CtrlP and NERDTree.
Once you have a good grasp of Vim, I would recommend exploring Emacs + Evil-mode if you want a more complete IDE experience.
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;
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.
Helm: https://tuhdo.github.io/helm-intro.html Fuzzy searching of anything: emacs help files, man pages, your code, your code function/class/variable names.
Magit: I generally hate git interfaces but this one is pretty good and allows commit, merge, rebase, and interactive adding seemlessly.
org-mode/org-babel: Note keeping to automatically create tickets in my help files and keep my place where I am. Execute code inline as a test.
- It's already 99% configured
- The keyboard shortcuts are mnemonic
- There is a UI display of all the shortcuts within one keystroke at any given time
- You can still function with your mouse -- if you need to
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.
But yes, basically
(setq omnisharp-expected-server-version "1.32.8")
(add-hook 'csharp-mode-hook 'omnisharp-mode t)
The annoying issue that at first prevented this from working was that on OS X I also needed
(setq omnisharp-server-executable-path "C:\\path\\to\\OmniSharp.exe")
If you use Doom make sure to use the develop branch.
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.
There is a challenge configuring your version of Doom, but the project's Discord channel is active, friendly and helpful.
Multiple eternal branches are pointless and need to stop.
Slightly less (directly) extensible than Emacs but still feels it can do pretty much everything that needs doing, plus way nicer & friendlier default UI.
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.
> pretty much an inferior copy of an existing thing (Atom)
How? For starters, it's a lot faster which appears to be a major reason why people switch
> but not really built as a nice platform to be meaningfully extended
Well that's up for debate now isn't it? Its plugin ecosystem disagrees with a perceived lack of extensibility.
> used cynically as a wedge to pull developers into your orbit
How does VSC do that? I use it and I've never seen it advertise other Microsoft products or services to me.
> and controlled by a single company
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.
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.
Exactly. That's another program whose "open source" status frustrates and saddens me.
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.
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.
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.
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.
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.
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:
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.
Simple things CTRL-C, CTRL-V does not work out of the box.
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.
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.
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 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.
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.
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.
...Obligatory mention of Xi editor: https://github.com/xi-editor/xi-editor ...
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.
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.
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, 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.
 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.
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.
My old //e has control there naturally.
I'm guessing the "combination to-do list and notebook" might have been org-mode?
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?
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.
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.
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.
And Mac users should know that Mac OS X has had basic support for Emacs style editing in native controls, inheriting it from NextStep.
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.
something like https://truongtx.me/2014/08/23/setup-emacs-as-an-sql-databas...
I'd want either:
* tabs with a good UX
* super powerful, easy to use, integrated command and fuzzy file search, also with a good UX.
I'd also want a terminal at least as good as the VS Code one, on Windows, to use with Cygwin.
With Emacs I'd have to learn a big bunch of terminology no other editor uses for a bit of flexibility while losing quite a bit of functionality.
Sadly for Emacs, I think that most devs are closer to my train of thought than to that of existing Emacs users.
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.
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 and helm as alternatives to Ido which are very popular completion systems with integrations that span the package ecosystem.
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.
I find it interesting that you can decide for me what I "need" or "do not need" :)
People's brains work in different ways.
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.
Ido or its siblings are very powerful for fast buffer switching.
Ibuffer is included in the gnu Emacs distro and does all of this.
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.
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...
M-x term does the same.
Those lead down this rabbit hole: https://stackoverflow.com/questions/4535432/terminal-in-emac...
M-x shell seems kind of dumb.
M-x eshell is not a usable shell.
Anyway, everything feels and is very stitched together.
(I also don't understand why declaring VS Code better than Emacs for my use case is downvoted, since it's the truth...).
Ah, that's too bad.