The Unix Philosophy as commonly invoked is rigged. You are apparently not allowed to implement the Philosophy on top of (as an application) Unix. Only by using the OS—which gives you the options of Unix, and… Windows?—are you practicing the philosophy. But hold on. What if you don’t have a lisp machine lying around? What if Unix, or Unix-likes, or asterisk-nix is all you’ve got? Well it seems you have to implement your own lisp platform and run it on those icky Unixen. Great, what could be more composable than an application which can be extended using Lisp, where key presses and functions are interchangeable? And now you get to communicate with your “small programs” on your Lisp platform. But then bam, you’re disqualified. Because now people have decided—for arbitrary reasons—that you have moved one level too far up.
The article doesn't really do justice to the composability - it provides little to no examples. So I'll try to provide some:
Emacs has a lot of functionality on displaying email, handling attachments, etc. This made it almost trivial for notmuch[1] to make a frontend for their tool. If you think about it, notmuch is merely a stand alone indexer. But they quickly made a full blown email client in Emacs revolving around notmuch by borrowing most of the functionality from packages like Gnus, etc.
magit has a neat menu based interface. Now many other packages make use of its interface even though they have nothing to do with git.
There are multiple completion frameworks, and it's always gratifying to utilize one of them for your own needs. As an example, I wanted to keep a directory of contacts. I used org-roam to create a node for each contact, and freely put any information I wanted in there (notes about the person, etc). However, I sometimes keep meeting minutes at work (in org mode) and whenever I mention a person, I want a link to his/her contact page. So I hacked up some elisp functions to:
1. Insert a new person (and return a link to him/her)
2. Select an existing person (this is where using a completion framework comes in).
Think of all the different pieces I used:
1. Org mode
2. Org-roam
3. A completion framework like vertico to show me only nodes that are people, and not all my notes nodes.
4. Calendar functionality to specify times/dates (really I'm using the functionality in org mode, which builds on the Emacs calendar functionality).
Basically I built a minutes taking tool + contacts management by using various components of packages. It was not a lot of code - perhaps 1-2 screenfuls.
I once had a directory with a lot of video files. I wanted to share some with friends, but needed to go through each one to decide if it's relevant to them. I wrote some simple elisp that, within dired (Emac's file manager), when I hit Enter on an mp4 file, would play the file using mplayer. If I wanted to share it, with another keybinding, it would put a link to the file in a particular org document.
This is a typical example, of utilizing several different Emacs packages to achieve a custom task.
It’s a playground for text. If you dream of a feature you want and your elisp is decent, the dream can become reality. It’s a beautiful big mess of features that mostly inter-operate. It feels like you can create ‘emergent behaviour’ when you compose the features.
I started off in emacs just using it to take notes at uni. I wanted to get inline previews of LaTeX equations. Previously I was doing the old ‘markdown written in vim converted to pdf via pandoc’, but I knew something was just.. off. It was a slog to add pictures to notes, I couldn’t render my equations easily, exporting was cumbersome and not the way I wanted it to look… I wanted to do MORE with my notes, have them feel like live documents, not just plaintext in a terminal.
I stumbled across doom emacs 2 years ago, knowing only a paltry bit of python. Picking emacs on that day was one of the greatest choices in my whole life, without any exaggeration. It was very daunting to dive into this big, alien world and ingest so much information (conventions, package names, functions, …). I just kept finding myself amazed that, for someone who prefers to limit mouse usage, emacs contains the absolute best experience in:
- note taking
- document creation (org, ox)
- literate programming (org-babel)
- pdf viewing and interaction (pdf-tools)
- time management and planning (org)
- version control (vc, magit)
- desktop RPN calculation (calc)
- PKM (roam, denote)
This was just a Cambrian explosion of creativity for me. Any number of these killer features were composable in whatever way I fancied. I was no longer held back by the poor interfaces and segregated nature of literally every other piece of software I had used in my life previously.
I mentioned that I only knew a bit of python when starting… the barrier to entry for most languages drops sharply every time you increase your emacs skill. Language major-modes are the distilled knowledge of thousands of man-hours in any particular machine language. Using these (none of which I’ve even mentioned in my list above), I’ve been able to learn (on my own, while studying civil engineering):
- emacs lisp
- Julia
- Common Lisp
- Scheme
- Racket
- APL & J
- JavaScript
- R
- (a few more at a cursory level)
I’ve interviewed at a few engineering firms based on these skills and they’ve all asked me “how did you go about learning all of these things?”, to which I couldn’t just reply “emacs”, but I really should have.
I actually was picked out of the pile of resumes/cover letters because of the presentation and formatting (LaTeX pdf export from org). I was then offered an internship because of my skills gained by using emacs for a few years.
I don’t exaggerate by saying it changed my life. Anyone reading this with any spark of interest: please put aside any notions you have about emacs and just give it a chance.
One of the original Unix creators, Doug McIlroy, credited with inventing pipes,
wrote in [1]:
"... I have always detested emacs and vi. With ^D, ^C,
and ^\, Unix has more than enough mystery chords to learn. Emacs
and vi raised that number to a high power ...
... Unix was born of a taste for achieving big power by small
means rather than by unbounded accumulation of facilities. But
evolution, including the evolution of Unix, does not work that
way. ..."
The editors favored by the original Unix guys are ed, sam, and acme.
This is somewhat silly. First, the mystery chords for the terminal only grew. And... Is kind of the reason to use a different editor.
Second, adding acme as a preferred editor throws the conceit by introducing the mouse to the chords.
I fully grant that chords with the mouse probably add a lot, especially after training. I struggle to see how "small means" can lead you to any one editor over another, though.
I can see that emacs (predating Unix) doesn't fit into the Unix philosophy (and I don't see a reason why it should -- it's first and foremost an editor, not a system tool), but
"The editors favored by the original Unix guys are ed, sam, and acme."
doesn't make any sense. vi was the VIsual interface to ed, so ed has all the mystery chords, just expects you to operate blindly.
Some of the original Bell Labs Unix people have a very austere view of the Unix philosophy.
In their view, it all started to go wrong -- Unix began to depart from the founding principles -- as early as 1978. In their view, Berkeley Unix does not follow their Unix philosophy -- they don't like network sockets, for example, whose design was mostly imported from some earlier non-Unix system (maybe Tenex?).
Some of this attitude appears in Rob Pike's 'Good, Bad and Ugly' talk from 2001 [1]. He says the early Unix tools approach had, by then, already been replaced for most users by big do-everything programs: Emacs, Perl, browsers...
But you can use these chords inside the editor's terminal (for example (n)vim's :term), so it's easier to scroll back, search stuff and copy-paste, for example
The funny thing is that I put vi more in the "UNIX Philosophy" camp.
Specifically, as a user of vi, especially with normal vi (vs vim), a routine workflow for me is !command some block of text, or the entire file to some utility or another.
And the idea here is that with little effort, the entirety of the UNIX environment (at least the CLI tools environment) is at my beck and call. I've munged gobs of text through most any utility imaginable. I've use vi as an interactive pipeline. Running data through one sequence, then running it through another, or a 3rd. It's like an interactive pipeline debugger with undo.
It's not that emacs can not do it, of course it can. You can run a region through a shell command as easily as anything.
But, folks don't. Rather they rely on the extensive, emacs universe to solve those problems. There's lisp for that. Like the Java and JavaScript eco-systems, where "everything" gets rewritten into that world, the drive has been to port the essential utilities into the whole of emacs, rather than having it work with the system surrounding it. There's all sorts of good reasons for this, but at the same time, all of those routines and such are cut off from "unix". While its straightforward to leverage grep, sort, awk, et al from within emacs, it's less so the other way around. I'm sure it's possible, but it's not trivial.
In a world of composite solution development, a monolith stands out because it acts more as an unscalable tower rather than a thing to touch for enlightenment.
Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Visual Studio.
Honestly in the 30 years I've been using Unixes I have never needed anything but vi/vim with a few lines of configuration, mostly to satisfy some of the newer fussier language indent requirements (yaml, python). Most of the non trivial data processing is done with external tools (sed, grep, awk etc) where the knowledge and power is reusable for other tasks external to editing things!
Only on Windows have I had to leverage anything more complicated.
I think it's a common misconception that Emacs is not a collection of simple tools.
There are two major differences: Emacs' "shell" is the ELisp interpreter, not (eg) bash; and, Unix uses the whitespace-separated text stream as its common language, and Emacs uses the text buffer.
There are analogous tools in both environments, although in Emacs, most of the "little language"-driven tools use ELisp instead, giving simpler cooperation.
There's a lot of truth in the "Unix is just a device driver collection for Emacs" model though: there's little need for most of the Unix toolset if you're adept at Emacs.
I think there's a much more interesting discussion to be had in comparing the relative merits of text streams (Unix) vs text buffers (Emacs) as a unifying abstraction for a suite of programmer's tools.
> Unix is centred around composing lots of individual tools that do one job well.
By this standard, the Unix philosophy has never been realized.
Even when the tools work as advertised, they're hardly doing it well. How do you delete a file called -foo? `rm -- -foo`. Do you know what -- is? It's kludge! It's kludge that needs to exist because Unix's entire paradigm of argument passing is legacy crap.
And historically, the tools didn't even work as advertised. Before GNU came along, there used to be all kinds of hidden landmines in common Unix utilities, like tools which silently truncated long output lines because they were using static buffers instead of dynamic memory allocation. GNU's style guide specifically warns against doing this, because it used to be the Unix status quo. Things like this get left out of the romantic tales of Unix's history, leading newbies to view Unix with rose tinted glasses.
As for "doing one thing", nobody even knows what that means. What is the difference between one thing and two things? Should rm not be able to remove directories because rmdir exists? That's subjective, what qualifies as "one thing" is inherently subjective.
It's kludge since you are special casing for some files and not for others e.g. rm abc vs rm -- -xyz. If Unix utilities had a different form of specifying args which didn't meddle/overlap with file names this kludge wouldn't have to exist.
Yeah, but still kludge because we don't do that for all files, do we? If it didn't start with a minus, we'd just drop it. So there's no one true way, as we'd like to think.
Thanks for your answer. Never realised the overlap between rm and rmdir. Actually the philosophy is a nice guideline but blindly holding on to it for the heck of it is childish. Your comment made me realise that.
Oh completely agree. But the philosophy is spot on. I've applied it to many problems over the years successfully outside the domain of Unix. The reality is however less than ideal.
Exactly, because of bad habits developed elsewhere I sometimes find myself puzzling (as an example) "how do I remove HTML tags in vim?" rather than "how do I remove HTML tags? OK, now do that in vim."
vim is the improved version of vi, which is the visual interface to ex, which is the extended editor ed... the one true editor ( https://www.gnu.org/fun/jokes/ed-msg.txt )
You will not infrequently find vim and vi links to the same executable.
/usr/bin % ls -l ex vi vim
lrwxr-xr-x 1 root wheel 3 Aug 24 03:59 ex -> vim
lrwxr-xr-x 1 root wheel 3 Aug 24 03:59 vi -> vim
-rwxr-xr-x 1 root wheel 5155568 Aug 24 03:59 vim
The difference between which way you have argv[0] slightly changes the functionality... but it's the same thing.
ed remains its own thing.
/bin % ls -l ed
-rwxr-xr-x 1 root wheel 235296 Aug 24 03:59 ed
To expand on shagie's answer, vi is a separate utility except when it's not (f.g. Linux vi is usually a minimal vim build running in vi-compatible mode). For a more pure taste of vi, install nvi or use vi on *BSD.
I was about to say that. Emacs not just the LISP machines. Emacs' comes from ITS, an OS praised by RMS, basically the anithesis of Unix. Everything was hackable and shareable. No perms.
The closest in philosophy may be Guix(SD), but, for that, the Unix utilities should be converted into optional tools and make Scheme both the command line prompt shell, the configuration tool and the API.
> Emacs is a survivor from the days of Lisp Machines, hardly a UNIX.
So? Did the author claim otherwise? Not that I could see. Does the OS of origin negate any of the author's claims about Emacs? No, it doesn't. Emacs on Unix gave the author a tool that fit their workflow and their mindset. Who cares what OS it originated on?
> Also the UNIX "philosophy" besides its quote on a book, has been hardly a thing on commercial UNIXes.
The UNIX philosophy, as quoted by the author, was supported by every commercial OS I have ever seen. (They added some other stuff, but they all provided the environment where the philosophy could play out well.)
I don't think you need to shoehorn every piece of software you like into one worldview. It's OK to like two different things. Contradiction is a fact of nature when discourse is linear but reality is anything but. Unix philosophy was amazing in the 70s, modern linuxes are great work environments now, EMACS is super cool, vim is a great little piece of text editing beauty. One thing is clear tho, Windows users have a severe case of Stockholm syndrome.
I don't think anyone has Stockholm syndrome. Windows works very well at basic chromebook like tasks and runs proprietary software well, most of the time.
Linux is just now patching up the last few big issues and fully catching up to Windows, and it's really only Mint and a few others that have windows parity. If you try any distro a linux enthusiast will probably recommend, like Manjaro, you can generally expect to fuss with stuff more than you would on windows by far.
And Mac is tightly tied to their non desktop metaphor UI that relies entirely on idiomatic gestures.
Please, Ubuntu is super easy to use. Windows has been putting ads inside your desktop environment and yeah no-one is gonna move on from it because they love to be captive to that ecosystem. Textbook Stockholm syndrome.
It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" by people who presumably use Unix? Maybe it's a philosophy like "Don't do sins" is a philosophy of Christians? More of an aspiration than an actual practice?
I can't really think of any Unix programs in common use that do one thing well. Inevitably, they grow to redundantly include features that other programs have.
If anything can be said to be the actual lived Unix philosophy it's probably something like:
1) Try to make your programs communicate using text, where the 'record' is separated by a newline.
2) If you have a choice between making a program a little more friendly to use, or making it's text communication a little simpler to compose with, go with the second option. E.g. if there's nothing to output when a program runs don't output "Nothing to output", just output nothing.
I don't think Emacs really fits with the unix philosophy, whether my version or the common version, at all. One of the main things I like about emacs is that it's like a vision of an alternate computing universe, where we assume that we're operating in a giant image that's meant to be programmed and customized all the time. What if most of your work was done in a LISP repl with a bunch of UI tweaks? It's like using a research project from a 70s or 80s "Future of Computing" lab that never actually shipped, except it did ship. It feels like it should have a lightpen attached.
I don't even really think it's particularly practical to use emacs at this point, I just like this vibe and reminder that nothing about the way we use computers was inevitable so much that I stubbornly still use it.
It's worth a read, but do bear in mind that the whole Unix mindset is an evolutionary dead end.
I mean the sad fact is that we're slowly learning that Unix with all its baggage is like an internal combustion engine: it seemed like a good idea at the time, so we adopted it, and now it's ubiquitous and it's a race to move on to something else before the bill for all the damage it's caused civilization comes due. People favor comprehensive, feature-rich programs over small composable ones. The Unix process model and fork(2) in particular break down utterly in the presence of threads. It took fucking forever in tech-industry time to come up with a single solution for dynamic linking, something Windows and Amiga OS solved in the fucking 80s. Linux is only just now getting an async I/O solution that begins to approach the robustness and comprehensive of what VMS had in the 80s and Windows NT had in the early 90s; before that, it went with the Unix assumption of "disk I/O takes zero time to execute, and you can poll for everything else!" You want to know what else Windows had in the early 90s that Unix, and especially Linux, only caught up with in slipshod fashion later? ACLs. One reason why Windows got an EAL4 certification under the Common Criteria well before Linux.
Postel's law was wrong (you want strict protocol conformance to avoid surprising behavior), ASCII text protocols were a mistake (parsing and unparsing them just converts electricity into waste heat), piping together unstructured blobs of text is NOT robust and programs should communicate via objects with checkable types... Just, on and on, mistake after mistake.
And C. Just... C. If null pointers were the billion dollar mistake, how many trillions' worth of damage were done by the totality of all C's foibles, pitfalls, and undefined behaviors? Honestly if we do nothing else, we should halt ALL greenfield development in C. It's unsafe at any speed.
> It took fucking forever in tech-industry time to come up with a single solution for dynamic linking, something Windows and Amiga OS solved in the fucking 80s.
> It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" [...] If anything can be said to be the actual lived Unix philosophy it's probably something like: 1) Try to make your programs communicate using text, where the 'record' is separated by a newline. [..etc..]
The Unix Philosophy isn't just about writing programs that do one thing well (and FWIW it isn't really a philosophy or dogma, it is more of a guideline/goal), there are a bunch of things. The "write programs that do one thing well" is just one ways to think about it.
The most common set of goals is:
1. Write programs that do one thing and do it well.
2. Write programs to work together.
3. Write programs to handle text streams, because that is a universal interface.
But there is really more to it as can be seen in the Wikipedia page[0], like ESR's 19 rules and Mike Gancarz (who wrote the "The UNIX Philosophy" book from his experiences) 9 tenets (three of the most common being using flat text files for data, avoiding captive user interfaces as that makes composition harder and making programs act as filters).
Really at the very core is the goal to make programs that can be glued together with other programs (often via scripts) to perform tasks and communicate in ways (pretty always via text) that humans can see so that they can stitch them together even if they know nothing about each other (for example even if two or more programs they use different formats for their input/output, since they use text, other common tools like grep, awk, etc can be used as filters/pipes directly or via scripts to connect them together).
This is where the "do one thing" comes from: if your program acts as a filter and/or communicates just via text, there is no need to complicate your program by adding functionality that another program can provide since a user can simply glue the two together. For example if you have some program that returns the values of some sensors you don't need to add search or filtering functionality since one can use grep and awk for that.
The "Unix philosophy" is pretty debased in a modern Linux system.
A BSD still has echoes of the original, but to get the pure experience, you should probably play with a Plan9 (maybe 9front), where the "one thing, well" bit is still taken seriously.
Small, composable "Unix philosophy" programs need a substrate in order to work well, and that substrate can be heavyweight. The Unix kernel itself with its process and I/O model is one example (though Plan 9 may be considered an experiment in just how minimal that substrate can be while supporting the essential features of the model). The shell allows linking these programs together in a way that's relatively user-friendly, making the toolkit of composable programs accessible.
Relatedly, the X server is a substrate that allows small modular programs to coordinate in different ways, composing to form a graphical desktop environment.
I think Emacs on Unix is another such substrate. In a way, it's a sort of super-shell that can not only allow the user to compose Unix programs as with the shell, but to capture their input and output in buffers for further editing and processing. The ability to capture text, whether from files, programs, or network connections, edit it in a buffer, and script any operation with Lisp makes Emacs a tremendously powerful tool in its own right and an easily configurable coordinator for your other tools, with enough power to let you put a custom UI over them for smooth, flow-conducive access at your fingertips.
Inferno was an even better experiment, the kernel and Limbo VM had a minimal attack surface, everything else was based on the same principles as Plan 9 and dynamically loadable modules written in Limbo.
The UNIX philosophy is redundant. The only unique part of it is to use text for everything, which isn't a very good piece of advice.
It only exists to cover for the mistakes of UNIX. The bulk of it is saying that you should apply the same design principals you would on the inside of a program to the external interface of it. The irony here is that people only treat these situations differently because UNIX forces programs to interact through limited means (a single function which accepts an array of strings as its arguments). If UNIX allowed programs to represent themselves as modules of functions which act on datastructures richer than a string, it would be obvious to everyone that they should apply good programming principals to these modules.
Case in point: Emacs. Its programs are modular, so it needs no grand philosophy telling programmers to apply the well known practices of good design. The `find' utility is the exact sort of thing that the UNIX philosophy warns against. It contains huge amounts of duplicate functionality; I believe the version installed on my system takes more than a hundred flags. No such functions exist in Emacs, because it would never occur to someone that they should write a function with over a hundred keyword arguments to do something as basic as file handling.
The advice in the UNIX philosophy exists only to combat the issues that UNIX creates, which is why I am so confused by the fact that so many people are reverent to it. They act as though UNIX invented simplicity or good design, as though the application thereof is something special rather than what should be the default for any competent programmer. I can only speculate why this happens. My personal view is that UNIX has locked us into systems that don't follow its own philosophy. People come to view this failure as the default, so any instance of good design is remarkable.
While I'm no elisp expert, I know enough to glue all sorts of utils. It enables scratching my own itches, often resulting in accessible workflows that do exactly what I mean. Some recent examples:
For the same reason certain religion known for door-to-door proselytism insists on being classified as Christianity: because it recruits from other Christian groups. Similarly, Emacs recruits users mainly from software devs and Linux users, many of whom have almost religious belief in Unix philosophy.
This document describes UniPress Emacs 2.20, the Unix version written in C by James Gosling and distributed by UniPress (who RMS referrers to as "Evil Software Hoarders"), based on the MockLisp extension language. Version 2.20 included multi-window support for SunView, X-Windows, and the NeWS window system. The document goes on to describe the future plans for SoftWire (a networked PostScript interpreter like NeWS but for managing text file and streams and sub-processes instead of drawing graphics), which UniPress developed but by never released.
UniPress Emacs Newsletter, February 1988: What is Emacs?
That's great, but I think sometimes "Unix Philosophy" looks too much like a religion.
Programs are tools, and if they do the work they need to do, who cares if they comply with some ancient ideal or not? Yes, certainly composability is a worthy feature to have if it fits, but sometimes it's not there and nobody cares because the tool still does the job.
I'm also of the view of that the ideal might be almost obsolete in its original form. Yeah, "grep | awk | sort | uniq" style chains are neat and all, but in modern times they're actually quite inflexible. Modern data is likely to have a complex structure many of those tools are ill-equipped to deal with. Most any time I write anything of even slight complexity, I end up doing it in Perl or Python, and it works almost exactly the way the same code under Windows would.
I've also got to admit that Microsoft got a leg up here with PowerShell, because rather than holding up to tradition from the 70s, they applied new modern thought to the problem and came up with something better. I think it's unfortunate that Linux has acquired a considerable amount of traditionalism, because that risks making it slow to adapt and improve.
I use VSCode right now, with lots of little extensions to do stuff like lint my code, format my code, color my code, highlight TODO and FIXME comments, 3-way merges, debugging with conditional breakpoints and watches and stuff, etc.
How do I get started using Emacs, if I wanted to use this awesome-sounding tool, while still being friendly to the fact that I have to get stuff done and still need the tools I mentioned above? (Also, how to have my cake and eat it, too.) I am sure the Emacs community has built everything under the sun, but is it as easy to setup and easy to find as VSCode?
I really want to know how I can transition from using VSCode to Emacs, because I'm starting to realize that VSCode is always going to be a "product" of a BigCo and will continue to add anti-features, tracking, and other stuff that I don't want. I'm also starting to realize that I want to be a bit more strict about my open source software usage, and try to support communities rather than coprorations.
Picking eMacs up as a replacement for VSCode while having to get stuff done is risky. I would venture to say that it’s not realistic as far as your conceptualization. I say this because you venture to ask if the setup process is similar. The answer is a resounding no. VSCode is incredibly easy to “get productive” and eMacs is on the other end of the spectrum.
That being said, if you can work some time into your schedule to learn eMacs, your goal can be realized. (Also, it’s totally worth it.) I was a VSCode user and made some time to learn eMacs exclusively for org mode (possibly eMacs’s coolest feature). Once I was comfortable, I just played around with a dev environment in eMacs (for fun) and loved it so much that I left VSCode.
Thanks for a realistic view! I'm trying out Doom Emacs, per another user's suggestion, and I'm going to try it out for non-code text editing for a while, since I do a lot of that still anyways.
I think some of the magic stems from ubiquitous conventions regarding bindings throughout eMacs. If you use evil mode, the conventions become a little murkier. I’d recommend sticking with the vanilla bindings (I haven’t used Doom, so I’m not actually sure if evil mode is default). This is just my two cents. Doom will be a great introduction either way.
I found the ebook Mastering Emacs, and the accompanying blog to be extremely useful, even after going through both Spacemacs and Doom Emacs. I may go back to a modal workflow in the future, but for now I'm embracing Emacs' built-in ways of doing things, with a few exceptions.
To get started with Emacs: (1) install it, either from a package repository or from www.gnu.org/software/emacs; (2) start it up (3) type Control-H t to run the tutorial. Those new to Emacs might prefer to use a customized distribution such as Doom Emacs, but the official Emacs system is quite usable. Don't expect to become an Emacs Master quickly, but doing these 3 steps will get you to the point where you can use Emacs for basic text editing. Emacs comes with lots of documentation, both on the core system and on the many packages it includes, but you can defer reading it until you are comfortable with the basics.
The two hurdles you'll need to overcome are: (1) the antique terminology, so “window” doesn't mean what you might expect it to, and (2) the key bindings, which don't match up with more modern systems. (1) is something you just have to get used to, while (2) is infinitely flexible. A vi user might prefer Doom Emacs or Spacemacs, which come with vi-compatible key-bindings; I'm not aware of something similar for the VSCode user. As you become more comfortable with Emacs, you will be able to make your own key bindings.
Thanks! That actually is what I found in the past, that (1) is hard to get through in order to setup an environment with the cool tools I want to use, and (2) is hard because I'm used to VSCode bindings. I think this time, though, I'm going to stage my use of Emacs because you gave me a good idea:
> doing these 3 steps will get you to the point where you can use Emacs for basic text editing
So, I'm going to replace my use of VSCode for text editing with Emacs for a while to start learning how to work with it, just not code stuff yet, and I'll replace my keybindings in VSCode with Emacs keybindings since VSCode is super easy to find extensions for and there happens to be a few "Emacs keybinding" extensions.
Thanks for the tips, I also didn't know about `Ctrl+H t` and so I'll try that out, too!
I'm actually pretty excited, I've had a ton of issues with VSCode updating the way they do things recently causing my workflows to get fucked up and have to change. I doubt I'll have that issue with Emacs!
The GP gave great advice that, in light of your response, I'll augment.
1 - Sometimes the worst helpers are the enthusiastic fans, not just with bands but with software. Most emacs advice starts by talking about customization. The GP was smart not to: just get comfortable with the model of emacs: a modeless editor. c-f goes forward a character, m-f a word. In code: c-f forward a character, m-f a symbol, c-m-f a structure (depends on the language).
You can always type c-H (^H) at any time for help. It's context-sensitive so if you're typing a long command (m-x find file) it will show you the completions. If you can't remember a command c-H a (apropos) will show you matches. etc. All explained when you start with c-H t
All of the stuff above has been true for more than 40 years. A lot of rough edges have been knocked off over that time! Even back then people who claimed that they "couldn't do anything with a computer" were writing documents with Emacs, even writing macros and such.
For more modern times: you'll find in most programming languages, markdown, etc syntax highlighting is automatic.
Once you are comfortable editing text or code, you can see how to add, say, LSP support, or investigating how to compile your code and why that's easier in Emacs, and just incrementally make your environment more comfortable and powerful. I've been using Emacs since 1978 (when it was written in TECO, not a form of Lisp) and still I learn something new every week or so.
Remember that "EMACS" stands for "Emacs Makes All Computing Simple"
Before you actually dive into coding in Emacs may I suggest to do the following:
1) Get yourself a copy of https://www.masteringemacs.org/ and read it. That gives you a very good overview on the design philosophy of Emacs and many practical tips.
2) Explore vanilla Emacs a little bit. Run the built-in tutorial. Explore Emacs's customization UI. Play tetris.
3) Familiarize yourself with how you install Emacs packages from ELPA and MELPA. On your first steps you can use Emacs' built-in UI. But, ideally, you want to learn "use-package.el" as quickly as possible because that will simplify your configuration a lot.
Coming from VScode you might feel a little bit overwhelmed at this point as you will be starting to use a Lisp macro routinely (!) to install editor extensions. Check out the "Emacs from scratch" series on YouTube for a helpful guide.
4) What programming languages are you using? For React projects you might need to use "webmode.el" which is not built-in. Similar situation with Clojure or Rust. If you want more convenience, you also might want to take a look on "lsp-mode.el" that adds more code introspection features. It is not crazily complicated to install and setup but definitely not beginner friendly.
5) Try to identify your most important extensions you are using right now in VScode. What are the features you cannot live without? Then embark on a google search what the most suitable replacements are in Emacs. For example, VSCode's "Restclient" extensions is paralleled by Emacs' "restclient.el" and it works quite well (if you use it together with "restclient-jq.el" that is).
6) For your dev work flow, checkout Emacs' built-in "compile-mode" (C-l) -- you can paste any shell command in there that will compile your code, run tests or synchronize with a remote dev server (everything that goes inside a bash script). Line errors will be clickable in the output window and help you jump in the offending code line. It's simple and effective. This will make you stop using the shell too often.
7) I recommend installing "which-key.el" which makes Emacs' display a cheat sheet of possible keyboard combos upon hitting control keys (after some delay). This way you'll learn keyboard commands more quickly.
8) However, don't let anyone tell you what the right way of using Emacs is. If you find the mouse menus convenient, by all means use them and don't listen to people who turn off the menu bar. (I even added a custom menu for Emacs modes I happen to use sometimes but not everyday.) Use CUA mode if you are used to "C-c C-v". Don't use the terminal version of Emacs. Ignore the extremists. However, definitely check out "magit.el" for version control.
The way I did it was by not using it for my entire workflow right away. The trojan horse for me was org-mode. Doom Emacs got me started in what felt to be a more modern UX, and I used org-mode not for coding outright, but for note taking and personal project management. After a while, I started to use org-mode's built in ability to run code via org-babel to experiment with ideas in code. Eventually I was comfortable enough that I just started using it to code some times instead of VS Code, because I was already there. I still dual-use VS Code and Emacs because VS Code is still better at some things (working with files on remote server is still kinda slow via TRAMP some times) but I'm about 85% in Emacs now, since I like it better for text traversal, org-mode has become more integrated into my workflow with things like tangle, and I like magit better than VS Code's built-in git interface.
TRAMP is generally performant enough with vanilla Emacs, but there are plenty of popular packages that utterly tank TRAMP performance. The big culprit I’ve personally found was helm. It made TRAMP unusable. You may also need to deal with some finnicky settings both in Emacs and in your remote shell to get it running satisfactorily.
I totally agree though that VS Code has a way better out or the box remote coding experience.
You can use the TTY emacs over SSH (or MOSH) without TRAMP. It only transmits the terminal display so it’s fast regardless of third-party extensions. VS Code remote is actually a negative for me, as it needs fast, stable connections and consumes a lot of RAM on the remote machine.
I totally get that, I've recently started on a toy programming project that has literally no purpose other than to play around, and it's great! It's such a breath of fresh air instead of working on actual work.
> How do I get started using Emacs, if I wanted to use this awesome-sounding tool, while still being friendly to the fact that I have to get stuff done and still need the tools I mentioned above?
Only use the new system on Friday afternoons or whenever your typical slow periods or lulls happen until you get used to it.
If you plan to customize your workflow and extend your system I recommend:
Don't forget to check out the MELPA (melpa.org) repository, which has a staggering array of packages for Emacs. If people do something on computers, chances are someone does it in Emacs and there's a package on MELPA to support it.
Also, the road to Emacs proficiency will be a journey, and you'll want to think about Emacs as something you'll gradually tinker with and tweak to get to a set up and understanding that is satisfying. It's not shiny nor whiz-bang by any means, but path through the learning curve can be extremely rewarding.
Thanks for that link, very useful for me to be able to find that stuff in one place. I want to treat my software development more like I do with physical hobbies and start to learn to use advanced-yet-powerful tools that are well-made. VSCode is perfectly fine, but I see it as something that won't last long in one form, constantly changing things for the flavor of the year tech.
I second the suggestion to start off with org mode. You get a low stakes note taking utility to use while getting comfortable with emacs. From there spread out to learn other features at your own pace.
I moved from VSCode to Emacs with the help of Doom Emacs. You can check it out online. It’s a distribution and configuration management solution.
Generally people like to recommend writing your config from scratch but that didn’t work for me.
It comes with pretty much all you requested out of the box.
One thing I liked more than with the default Emacs setup is that I could “activate” support for a Language just by un-commenting a line in the well organized config.
Ooh, thanks! That sounds like something that will help me. I tend to do better when I can get something running like someone else has done in the past, then slowly tweak things as I learn more about it. My current VSCode setup and all my dotfiles have been slowly cribbed and edited from various sources who knew more than me about those things.
Seconded, Doom Emacs is such a huge QoL improvement over the DYI solution with a basic Emacs.
(I did use the upstream vanilla Emacs, but the pain of LSP support, etc. etc. was just too much until I tried Doom Emacs... and suddenly Emacs is usable again!)
Not exactly what you’re asking for, but check some articles and videos about org-mode. There’s a chance you’ll get hooked on it and the following learning will be much easier because damn, it’s worth all the pain. Well, at least that was my case.
This is an incredibly underutilized idea. It still feels like there's ample room for interoperability in the realm of "I write a short piece of code for someone I'm working with, and then they take it and use it for something else" in a way that could be very specific to one project.
I'd venture to say that essentially no one thinks like this, but there's no good reason they shouldn't?
Isn't that what package managers in programming languages do? E.g. if I write a "left pad" library and put it on npm, then it can compose into someone elses program and left pad their strings.
