hell \ Rebekah Hellbergpeople who have gone from neo/VI/m to Emacs or wise verse - what made you swap? what made you then either stay or revert?
Paul SomeoneElseI switch back and forth between vi and emacs.
Vi is nice if you are into "Unix IS the IDE".
It starts instantly. You use the shell for shell
things.
Emacs is nice to do EVERYTHING in.
When I use emacs I leave it running for
days. It's especially nice for programming
any kind of lisp.
Emacs is definitely more of an ideal for using
as a pure programming editor, but i have
become more and more unix pilled so I
tend to use vi more lately.
An example is auto formatting. Emacs is great
at this IN the editor. Press tab and emacs will
do the correct thing indent wise.
In vi I have to find an external program
that formats (like gofmt or indent) and
pipe the buffer contents out to that
program and back. This is made easier
by using map commands to map keys
to do the indenting. But shows how emacs
and vi differ basically.
Vi is nice if you are into "Unix IS the IDE".
It starts instantly. You use the shell for shell
things.
Emacs is nice to do EVERYTHING in.
When I use emacs I leave it running for
days. It's especially nice for programming
any kind of lisp.
Emacs is definitely more of an ideal for using
as a pure programming editor, but i have
become more and more unix pilled so I
tend to use vi more lately.
An example is auto formatting. Emacs is great
at this IN the editor. Press tab and emacs will
do the correct thing indent wise.
In vi I have to find an external program
that formats (like gofmt or indent) and
pipe the buffer contents out to that
program and back. This is made easier
by using map commands to map keys
to do the indenting. But shows how emacs
and vi differ basically.
tusharhero@pkw I recommend reading https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-the-unix-philosophy.html by @ramin_hal9001
Ramin Honary@tusharhero thanks for the shout-out!
“people who have gone from neo/VI/m to Emacs or wise verse - what made you swap? what made you then either stay or revert?”
@hell the article mentioned by Tusharhero is a little long, so to summarize it in a way that more directly answers your question: I basically realized that Emacs was not a text editor, it was a programming language designed for text editing that came with a built-in text editor and IDE. And the built-in editor and IDE are setup so that you don’t really need to learn the Emacs Lisp programming language to use it.
I had become frustrated with my editor (Vim) my terminal multiplexer (Screen or TMux), my shell (Bash), and many of my other CLI tools all being programmed, scripted, and/or configured in different languages. For example, when trying to get my shell to notify my editor that a build process completed, I was able to program Vim and my shell scripts to both use inotify or similar tools to do so, but I just thought it was a little ridiculous that I had to hack together solutions to these problems.
So I started thinking about ways of using the CLI with just one programming language and one runtime. Then it hit me: Emacs is exactly that: a combination of Tmux, Vim, Bash, and dozens of other tools all programmed in Lisp. Once I realized that, I decided I didn’t care how hard it was to use, it was exactly the tool I needed so I had better just learn how to use it. And it turned out not to be too hard anyways.
The best part was, I hardly ever need to write my own tools anymore because I was always able to find some Emacs Lisp code somewhere that solved practically any problem I had ever come across.
If you’d like to know more, then yeah, read my article, or ask me anything you’d like here on the fediverse!
restoranteSometime I wonder, how did people start to compare emacs with vi? Indeed it is true that vi and emacs are both text editors.
But in a sense, emacs is an editor and much more. Are these two computer programs even comparable to begin with?
Just like what you wrote, emacs acts like vi. But emacs also acts like tmux. It is also acting like a shell and more.
Comparing emacs with vi is like comparing emacs with python or java or perl.
Zenie@restorante @ramin_hal9001 @hell @tusharhero
Back in the 80s, if you were on Unix, the easy path was Vi.
It was just there. Emacs was a rumor, then it was yet another big thing to download and build.
It was painful. Vi and Emacs were the most popular once Emacs gained momentum. It was big, ate a lot of memory and was the butt of jokes. It didn't get easy until the 90s, and even then 18 meg's and constantly swapping.
It didn't matter that Emacs was so much more than Vi.
You were in one camp or the other and most everyone still had Vi fu. Vim came late and is much bigger than Vi and still much less than Emacs.
Apples and oranges.
@restorante yes. I think Emacs is probably most similar to JavaScript and Node.js.
When you combine Node.js, Electron.js, and the Monaco Editor Engine all together, you get VSCodium. But Electron.js is a huge WC3-standards compliant browser engine that can render beautiful graphics. You don’t really need all that just to do text editing.
Emacs doesn’t have a fully WC3-compliant browser engine built-in, it does it’s own rendering, and it focuses mostly on rendering text with some images. It comes with many useful libraries for working with source code, e-mail, IRC, revision control systems, system processes, and the filesystem. It comes with it’s own markdown system called “Org Mode,” which is useful for composing documents that are not source code. It even ships with a few games.
Vi, on the other hand, is more of a UI/UX implemented by many software. There is the old Unix Vi, there is Vim, and Neovim. Emacs also has a Vi implementation called “Evil” which is written in Lisp. Of course, none of these editors have anything in common except the user interface and user experience, so they all “feel like” Vim.
So it is a little strange comparing Emacs and Vim. Emacs is a programming language and IDE, Vim is a user interface. It is like comparing Node.js with Xfce.
Karl Voit 
@restorante @ramin_hal9001 @hell @tusharhero
My take(s) on that #Emacs and #vim comparison part:
https://karl-voit.at/2026/01/23/Emacs-vs-vim-Cargo-Folding-Bike/
and https://karl-voit.at/2015/10/23/Emacs-is-not-just-an-editor/
Timothy Roes@publicvoit What a great blog you have. I might give #Emacs another shot. I tried org mode during my PhD but couldn’t remember all the keyboard chords and ultimately wrote my thesis in #Vim. I’m wondering about the UI when using org mode as a to do app for #GTD. Don’t you feel plain text can become quite cluttered? Could you manage a list like that on mobile?
@TimothyRoes I recommend https://karl-voit.at/2020/01/20/start-using-orgmode/ + https://karl-voit.at/2021/08/30/the-org-mode-way/
Why should plain text become quite cluttered? I'm managing lots of data and do not have the impression of getting clutter: https://karl-voit.at/2020/05/03/current-org-files/
I don't understand your question about mobile.
@publicvoit thanks! I might need to add tasks when on the go, or quickly find all tasks that relate to a certain location. Finding and opening a long txt file seems less convenient in that scenario?
@TimothyRoes I don't have those use-cases but I know them from the GTD method, yes.
You could try out the apps that can handle #Orgdown files on your mobile OS of choice. You could implement those markers using categories, hierarchy, or tags. So before that, you'd need to decide a few things: https://karl-voit.at/2021/01/18/feature-vs-method/
bignose@TimothyRoes
> Could you manage a list like that on mobile?
I do! The excellent #Orgro is a mobile app designed to manage an #OrgMode document. Powerful and straightforward.
https://orgro.org/
https://f-droid.org/packages/com.madlonkay.orgro/
@orgro
> Don’t you feel plain text can become quite cluttered?
I don't. #Emacs GUI is consistent across platforms (sometimes that means it is a bit misfit to a specific desktop style, but that's okay) and Org adds good presentation to the #PlainText.
@bignose Great tip. On iOS I've also found https://xenodium.com/plain-org-for-ios which looks slick. I'll soon be moving away from iOS to SailfishOS, though. @publicvoit @orgro
Andrew Wigglesworth"Comparing emacs with vi is like comparing emacs with python or java or perl."
GNU Emacs is a runtime for the Emacs Lisp language as much as anything else, and Emacs Lisp "is a full computer programming language. You can use Emacs Lisp as you would any other programming language."
So, you can compare GNU Emacs to Python, Java or Perl.
I understand what you meant and I agree with it. Indeed we can compare elisp with python, perl or java since all of them are programming language.
But on the other hand, emacs is more than a programming language.
It is also true that we can compare emacs with vi since they are editors. But on the other hand, emacs is more than an editor.
Thus, I am wondering whether emacs and vi are comparable, since emacs is more than editor.
Also wondering whether emacs and perl are comparable, since emacs is more than a programming language.
Vassil Nikolov | Васил Николов«how did people start to compare emacs with vi? Indeed it is true that vi and emacs are both text editors.»
The heretics that do not use The One True Editor must understand the error of their ways.
This is as old as the hills...
As someone rightly pointed out earlier in this thread, the only winning move is not to play.
But it is a somewhat expensive lesson.
@restorante @ramin_hal9001 @tusharhero
I feel like this when people compare scripting languages to programming languages.. yeah no shit one of them can take higher loads.. but it feels like asking what is better, a van or a motorcycle - I don't know - what are you trying to accomplish?
That said, I am continuously questioning and trying to to make my computer use more effective*, and I am standing at a point where Emacs seems like a very sensible choice forwards. At least workflow wise in it being a lisp interpreter - but I am also meeting a lot of backlash to that idea, the viable ones that Emacs tends to be slow because of how much it does and not or not properly implementing multi thread processing (tbh I am quite confused here).
If I do not choose the Emacs route I feel like the way forwards for me might be to chase lightweight software and build modes to launch (keep in mind my super/ctl/etc is at thumb position).
*hence going qwerty --> colemak, 100% stag keb --> 35% ortholinear, windows --> linux, plasma --> gnome --> tiling --> scrolling
tl;dr: I am not diehard anything - but I would like help to decide if it makes sense to deepdive into Emacs as dev/hw/sec enthusiast who wants to streamline their computer experience to the max and dont mind a learning a whole bunch of shortcuts if it makes the overall experience better.
@hell @restorante @ramin_hal9001 the difference between a "programming language" and a "scripting language" is not some hard definition.
@hell @restorante @ramin_hal9001 BTW, as ramin explained, it is possible to write non blocking software in Emacs lisp, I just needs to be written in a non blocking manner. Also, just because you are using Emacs it doesn't mean you are forbidden from writing little scripts in other languages. I have some bash and guile scripts that I just call from M-!.
@hell I have been trying to understand what you mean but I can't figure it out. Can you explain your question?
@tusharhero I was saying that following @restorante's reasoning comparing a is like comparing a script lang to a prog lang, which you seem to have taken literally instead of like the analogy for comparing incomparable things - this was probably on me. There's no question, just an attempt to analyze what had been said..
That said, the underlaying question thou I suppose is what direction I should lean towards in my pc env.
I try to approach my env pragmatically rather than dogmatically, and I tend to have a quite pessimistic approach. For example, I use Arch - not because it's Arch but because I've yet to find anything that is (subjectively) better.. what more is, my subjective approach is that Arch is bad, but that other operating systems I am familiar with are worse.
My move from Gnome to i3wm was very recent blew my mind in terms of what I want my env to be.. so the question now is do I deep dive into Emacs for most tasks or do I build my own layered shortcut driven env with mini software.. or something in between when where Emacs is used for smaller tasks such as rss reader, ftp client and so on - might even end up using it for some tasks but not text editing.
What I know right now is that the way I use shortcuts in Niri-wm feels unsustainable. That is, setting up single shortcuts to launch software - I gonna always have to relay on d-menu as there isn't enough letters to build individual shortcuts - meaning if I choose to not go with Emacs I may set up modes. A big advantage with Emacs is that when forced to use Mic!oslop or Mac I can simply install Emacs, copy my init.el and hit the ground running.
I feel like it might have all got a bit muddy - but feel free to provide feedback on that :)
@hell @tusharhero @restorante @ramin_hal9001
Historically a scripting language was shell, awk, and later python or lua...
You could say interpreted vs bytecode vs compiled.
But that's not exactly true. BASIC is/was interpreted.
Java is bytecodes. ECMA script is bytecodes.
Lua is now JIT compiled. While lisps are often considered interpreted, many lisps, common lisp, Emacs lisp actually compile to machine code like C or Rust. Emacs is not slow.
Clojure goes to java bytecode.
Then graal has muddied the water further.
I consider a scripting language to be standalone, no heavy infrastructure, easy to solve smaller problems. Shell, babushka, etc.
@Zenie that is a good definition of a scripting language. I agree it has more to do with the runtime being small and the syntax and keywords being suited for a specific purpose.
But then again, a Scheme program can be either run as a script or compiled to an efficient server-side binary, so like @tusharhero said, the distinction is never very clear.
@hell @restorante
But then again, a Scheme program can be either run as a script or compiled to an efficient server-side binary, so like @tusharhero said, the distinction is never very clear.
@hell @restorante
@ramin_hal9001 @hell @tusharhero @restorante
I avoided scheme in my description ...😅
I'm sure scheme isn't the only one either.
I avoided scheme in my description ...😅
I'm sure scheme isn't the only one either.
@ramin_hal9001 @hell @tusharhero @restorante
I guess emacs lisp qualifies too. You can just have an .El file and invoke from the command line with emacs.
@Zenie any language qualifies for anyone sufficiently motivated
@tusharhero
I suppose. But I think a requirement for
A scripting language an easy runtime.
I can write something and run it with no hassles no compilation.
@Zenie well, no hassle, yes. But compilation or interpreted doesn't matter.
@Zenie those are implementation details imo
@Zenie But I guess in this context, we mean, no separate step for compilation?
@tusharhero
Lua is JIT. But it's still a scripting language.
Bit I wouldn't consider java a scripting language.
@Zenie java feels like it was designed to be the most not scripting language ever
Actually I do not really understand the exact meaning of scripting.
So far my impression is if I define a variable with 'int myAge', it is not scripting language.
But if I can define a variable simply as 'define myAge' or 'var myAge' or 'def myAge' or '$myAge', it is a scripting language.
I think wether or not a language is typed is irrelevant.
Typescript is typed and is still a scripting language.
It is ECMA script.
Clojure is not necessarily typed and is not a scripting language.
I think it really just comes down to a lightweight infrastructure with no extra steps and ease of execution of the raw code file.
The characteristics of the language have no bearing.
@hell that is true, sometimes the distinction between scripting and programming is clear, as with your example of Python (scripting) or Java (programming).
But with some languages it is not very clear. For example, Scheme can be used for both scripting and system programming.
@tusharhero @restorante
But with some languages it is not very clear. For example, Scheme can be used for both scripting and system programming.
@tusharhero @restorante
@ramin_hal9001 wrote:
«And the built-in editor and IDE are set up so that you don’t really need to learn the Emacs Lisp programming language to use it.»
That's certainly true, but moreover you _have the option_ to learn and use Lisp as well _and_ to _gain a lot_ from that _in addition to_ the rest.
And then access to executing Lisp programs is highly integrated with the rest.
For example, you can insert an Emacs Lisp fragment into a plain text buffer (a text file opened for editing) and execute it right there with a trivial command.
It can change the same buffer or it can do a lot of other things.
And it goes on.
Chris L@vnikolov @ramin_hal9001 @hell @tusharhero I have a function that is one of my most used functions which puts commas into numbers into a buffer. I just have a much stronger grip in the sizes of numbers with the commas and so I can add this in for my reading pleasure
This was a very interesting read..
Question then, as complete Emacs noob, who have used ti for editing text and opened eww once, but who was attracted to it not as an editor but as one place to host small softwares and hopefully run them primarily with shortcuts:
people keep telling me because it does so many things it gets really slow - and the boot isn't laser speed I see that for sure - but but it seems to me that the workflow would be slower if I have to open separate software every time I say want to use git, ftp, email and so on? Could I have your thoughts?
@hell Emacs can sometimes be slow, yes, but it is usually not a problem.
Compared to the days when Emacs was first invented in the late 1970s to early 1980s, computers are so fast nowadays that the difference between launching a whole process like Git as compared trying to run a small function in the memory of your Emacs process is trivial, hardly worth ever worrying about. Technically, launching a whole process is slower function and takes more memory than running an in-memory, but a human can’t notice the difference on modern computers, both happen instantly from our point of view.
Sometimes Emacs is slow, and the reason this happens is not because of using too much memory or running too many processes, it is because everything in it’s memory is shared, and this makes it difficult to run multiple threads. When you perform an action in Emacs, that action may touch everything in memory. All buffers and variables need to be locked until that action is complete, because if you allow two actions to run on unlocked memory, those two actions can interfere with each other and corrupt memory (we call this “race conditions”).
So Emacs usually does one action at a time. If the action you perform takes a long time, your Emacs will freeze everything until it completes that action. This makes Emacs feel very slow, when in fact it is running just as fast as any other program on your computer. Emacs does provide multiple threads, so you can run a background process like Git or Grep and it will buffer the results without freezing Emacs. And if a command takes too long the Control-G key almost always works to unfreeze it, so it is very stable.
It is a trade-off. Though locking everything, and the “feeling slow” problems are disadvantages, there are advantages to having all memory in your computing environment shared as well, such as being able to easily change anything you want at any time.
So I think Emacs is very good for your goal of hosting small software. You should just be aware that when you use it, sometimes, some actions will freeze emacs for a few seconds.
And thanks for reading my blog!