One of the biggest benefits I’ve received from Emacs is being able to work in the same environment regardless of the OS I’m running. It’s not perfect on Windows but it sure makes living in M$-land at work and Linux-land at home much easier.
Although it’s certainly quirky, eshell is a great portable shell for the vast majority of what I do, and it works equally well on Linux as on Windows. I especially like how I can use my Emacs editing functionality right in my shell.
For those of you who use Emacs but haven’t learned eshell yet (like me until a few months ago) this guide is a very good resource.
Regarding “quirky”, I sometimes wonder if it is because I’m used to classical vt100 terminal emulators, such as xterm and the GNOME Terminal + curses based shells such as bash, that makes me see eshell as weird, or what the reason is. Another explanation would be it’s insufficient-well handling of certain escape codes that some programs emit (color, line-updates, etc.).
Just recently I rewatched Russ Cox’ A Tour of the Acme Editor, where he mentions that he never needed a shell with a history, since Acme’s win (similarly to eshell and all other comint-modes) support editing the session as a regular buffer. Maybe if (actually better) mode of interaction were more widespread, I wouldn’t find it so wierd (but cool), as I do now.
The “editor buffer as shell” concept was used in Macintosh Programmer’s Workshop, where I spent several intense years, and I still really miss that interaction style. I guess it’s originally from Smalltalk (which I also miss).
…an MPW worksheet is always in visual editing mode and can be freely reorganized by its user. Hence a worksheet can be purely a command script or purely a text document or a mixture of the two—an integrated document describing the history, maintenance procedures and test results of a software project.
For each project I was working on, I had an ongoing document with a rich collection of relevant commands, all just a “cmd-enter/cmd-Z” away.
What it lacks that emacs has seems to be even more extensions of all kinds.
The ‘lack’ of extensions in VSCode more of a ‘symptom’. What it lacks is more fundamental. VSCode hasn’t been designed from the ground up to be extended on the fly. Quoting the article
Eventually I would write Elisp casually in between programming on work projects. I would notice that a way of working was repetitive, or that Emacs behaved in a way I just didn’t quite like, or I simply thought of a nice thing that I could add. I’d happily spend anywhere from 30 seconds to half an hour writing some functionality to extend my editing facilities.
The important difference is on the fly. VSCode has certainly been designed with extensibility in mind and it has some impressive extensions, like their vim extension calls neovim for the ex commands
Phrasing it as “scriping/macro capabilities” makes me think you’re still approaching this from the wrong direction; it sounds like you’re still thinking the editor itself should be a fixed core, and then maybe some of the plumbing around it can be extensible.
To reach Emacs levels of extensibility, you need to start not with an editor. You need to forget all about the editor to begin with. You start only with a tiny virtual machine that runs future editor extensions – even before there is an editor. Then you build the entire editor in terms of those extensions.
Yes, this is a very important point. I have also been patching these minor annoyances every now and then for a while, and also started contributing my fixes back to the original projects. It only just recently dawned on me that this would not have been feasible for me to do with practically any other editor. I had taken it for granted, but I realise now how privileged I am for being able to do that to my editor of choice.
(As a side effect, it’s also had me starting to re-investigate what I think my opinions should be on the whole GPL vs ISC licence.)
You can run emacs without any graphical environment (e.g. when working on a headless server), but I’m fairly certain (as someone who has never touched vs code) that vs code cannot do that. Most distros package emacs, is that also the case with vs code?
You can run emacs without any graphical environment (e.g. when working on a headless server), but I’m fairly certain (as someone who has never touched vs code) that vs code cannot do that.
That is my understanding as well. On normal nix systems thought I typically don’t edit code on the server, and Windows systems have GUIs.
Most distros package emacs, is that also the case with vs code?
More or less it seems. I guess (but don’t know) it is not available in the default repos of Red Hat 7 but between exe, snap, appimages (again, educated guess) and precompiled binaries that are easy to untar into ~/bin and use (after submitting them to virustotal ; ) it is now easy to use it everywhere I need it.
I recently started using VSCode to debug .NET Core code. While it is definitely more extensible than VS, I think comparing it with Emacs is apples and oranges. I don’t know of anything like Tramp or Magit in the VSCode world yet, maybe they’re possible, I’m not sure. I saw there were a few org mode plugins, but from what I saw they lacked agenda functionality.
Window management is probably the biggest difference for me though. Ace, Avy, Eyebrowse, and Evil-mode got me to give up tmux+vim as my preferred environment. I’ve found somewhat-similar plugins in VSCode but again, they still can’t touch their Emacs equivalents yet.
This is half of the answer I give when people ask me why I religiously stick to plain text editors rather than full-blown domain-specific IDEs. Not only do plain text editors allow me to work in the same environment regardless of which OS I’m running; the other half of the answer is that they also allow me to work in the same environment regardless of what type of content I’m editing. Be it LaTeX, Org, F#, Common Lisp, HTML, JSON – I can edit it all with the same generic text-manipulation tools.
One of the biggest benefits I’ve received from Emacs is being able to work in the same environment regardless of the OS I’m running. It’s not perfect on Windows but it sure makes living in M$-land at work and Linux-land at home much easier.
Although it’s certainly quirky, eshell is a great portable shell for the vast majority of what I do, and it works equally well on Linux as on Windows. I especially like how I can use my Emacs editing functionality right in my shell.
For those of you who use Emacs but haven’t learned eshell yet (like me until a few months ago) this guide is a very good resource.
Regarding “quirky”, I sometimes wonder if it is because I’m used to classical vt100 terminal emulators, such as xterm and the GNOME Terminal + curses based shells such as bash, that makes me see eshell as weird, or what the reason is. Another explanation would be it’s insufficient-well handling of certain escape codes that some programs emit (color, line-updates, etc.).
Just recently I rewatched Russ Cox’ A Tour of the Acme Editor, where he mentions that he never needed a shell with a history, since Acme’s
win(similarly to eshell and all other comint-modes) support editing the session as a regular buffer. Maybe if (actually better) mode of interaction were more widespread, I wouldn’t find it so wierd (but cool), as I do now.Oh an btw, “Eshell as a main shell” is also a great article on this topic.
The “editor buffer as shell” concept was used in Macintosh Programmer’s Workshop, where I spent several intense years, and I still really miss that interaction style. I guess it’s originally from Smalltalk (which I also miss).
For each project I was working on, I had an ongoing document with a rich collection of relevant commands, all just a “cmd-enter/cmd-Z” away.
FWIW VS Code is the same, it runs nicely on every platform I care about at the moment (Windows 2008 -, mainstream distros.)
What it lacks that emacs has seems to be even more extensions of all kinds.
The ‘lack’ of extensions in VSCode more of a ‘symptom’. What it lacks is more fundamental. VSCode hasn’t been designed from the ground up to be extended on the fly. Quoting the article
The important difference is on the fly. VSCode has certainly been designed with extensibility in mind and it has some impressive extensions, like their vim extension calls neovim for the ex commands
Some really good points, thanks.
Maybe VS Code could need some good scripting/macro capabilities?
I remember jEdit used to have back when it was my preferred editor (~2003-2006).
Phrasing it as “scriping/macro capabilities” makes me think you’re still approaching this from the wrong direction; it sounds like you’re still thinking the editor itself should be a fixed core, and then maybe some of the plumbing around it can be extensible.
To reach Emacs levels of extensibility, you need to start not with an editor. You need to forget all about the editor to begin with. You start only with a tiny virtual machine that runs future editor extensions – even before there is an editor. Then you build the entire editor in terms of those extensions.
Yes, this is a very important point. I have also been patching these minor annoyances every now and then for a while, and also started contributing my fixes back to the original projects. It only just recently dawned on me that this would not have been feasible for me to do with practically any other editor. I had taken it for granted, but I realise now how privileged I am for being able to do that to my editor of choice.
(As a side effect, it’s also had me starting to re-investigate what I think my opinions should be on the whole GPL vs ISC licence.)
You can run emacs without any graphical environment (e.g. when working on a headless server), but I’m fairly certain (as someone who has never touched vs code) that vs code cannot do that. Most distros package emacs, is that also the case with vs code?
That is my understanding as well. On normal nix systems thought I typically don’t edit code on the server, and Windows systems have GUIs.
More or less it seems. I guess (but don’t know) it is not available in the default repos of Red Hat 7 but between exe, snap, appimages (again, educated guess) and precompiled binaries that are easy to untar into ~/bin and use (after submitting them to virustotal ; ) it is now easy to use it everywhere I need it.
I recently started using VSCode to debug .NET Core code. While it is definitely more extensible than VS, I think comparing it with Emacs is apples and oranges. I don’t know of anything like Tramp or Magit in the VSCode world yet, maybe they’re possible, I’m not sure. I saw there were a few org mode plugins, but from what I saw they lacked agenda functionality.
Window management is probably the biggest difference for me though. Ace, Avy, Eyebrowse, and Evil-mode got me to give up tmux+vim as my preferred environment. I’ve found somewhat-similar plugins in VSCode but again, they still can’t touch their Emacs equivalents yet.
This is half of the answer I give when people ask me why I religiously stick to plain text editors rather than full-blown domain-specific IDEs. Not only do plain text editors allow me to work in the same environment regardless of which OS I’m running; the other half of the answer is that they also allow me to work in the same environment regardless of what type of content I’m editing. Be it LaTeX, Org, F#, Common Lisp, HTML, JSON – I can edit it all with the same generic text-manipulation tools.
I’m impressed and frightened of this work ethic.
Could also include time working on personal projects at home. Good odds you’ll be using Emacs for that too if you use it at work.
I’m not. If you work nine hours of the day, every day, when do you ask if you’re even working on the right thing?
I mean if you’re using Emacs everything you’re doing is the right thing ;)
touché!
The market will tell you, presumably.
Thith comparithon flatterth me
TL;DR;
https://3.bp.blogspot.com/_dWpCGfU56J8/TAKgQ4kbnSI/AAAAAAAACH8/4edCH5C7emA/s1600/emacs+user.png
Less fingers are required if you use evil-mode or god-mode :)
Depends on which god… if you have an HP Lovecraft inspired emacs user then https://i.imgur.com/pznqq35.jpg