But... what is it?

Being a newbie to linux one of my first major decisions seems to be Vim vs Emacs. I've been looking around and I can find a lot of documentation on how to get started with emacs. But I still don't understand, what actually is it? Vim can be described as a modal terminal text editor. But what is emacs? As far as I can tell it seems to be much more than just a text editor, right? Could you use it as a terminal text editor? Or do I have to use the GUI? Apart from editing text what else does it do? There seem to be a lot of things you can do with Emacs that you cant do with Vim. But is there anything you can do with Vim that you cant do with Emacs? For example the modal editing stuff?

Emacs is a Lisp runtime which runs Emacs Lisp, and a set of tools for programming (both its own Lisp and other languages), which includes a text editor. > Could you use it as a terminal text editor? Or do I have to use the GUI? You can use either/both terminal and GUI. I strongly recommend that people use the GUI. > Apart from editing text what else does it do? The list is very long. Off the top of my head: Email client, chat client, shell/terminal, debugger, calendar, organizer, version control client, database client, literate programming tool. This is not remotely exhaustive. > But is there anything you can do with Vim that you cant do with Emacs? I have no idea. Maybe! > For example the modal editing stuff? Emacs supports modal editing through packages like evil-mode.

"It's a magic door."

*Succinct version:* Emacs is a text editor, and also a programmable framework for text-oriented keyboard-driven applications (including, but very much not limited to, text editing), often interacting with files and processes (on both local and remote hosts). *Non-technical elaboration:* Emacs is an extensible application which contains any number of 'child' applications inside it. You can display multiple applications at the same time, switch between them, and hide or show them as you wish. Applications can interact with files, processes, and network resources. By default it comes with dozens of applications including a text editor^1, a file manager, an organisational tool, a scientific calculator, and many, many more. Emacs is fully-programmable, meaning that new applications can be written for it by anyone (including its maintainers, third-party developers, and any user), and hundreds of applications are available for download. All applications are text-based and fully keyboard-driven as standard (graphics and mouse UIs are both supported too), and text-based commands (including searching, copying, and editing) can generally be applied to any text in any application, taking powerful advantage of familiar keyboard commands and a standardisation on text formatting. ---- ^1 Actually a large number of text editors, each one specialised for a particular type of file. In principle each of these editors could be a fully-independent application, but in practice most of them share many common behaviours, and generally provide a consistent user interface, giving the impression and feel of a single unified editor. The extent of the shared or inherited behaviours really depends on the similarities or differences of the file types in question, and the practical editing requirements for each of those types.

Thanks for your expansive response!!! What do you mean Lisp runtime? What is a runtime? Also, Why do you strongly recommend the GUI? Its crazy how 1 program can do so much. Does it do all of these things well? Like the email client, is it any good?

Hahaha

Woah! Thats quite the program. Does it do all of these child applications well? Or do you often end up using something else that works better For example, do you use the emacs email client or is it kinda meh so you use something else instead?

There's an old quote: "programs naturally grow until they are capable of sending email / browsing the web. Those that can't are replaced with ones that can." Emacs is Notepad + natural selection x40 years. It can do everything that vim can do. You can make it do _only_ what vim can do, or you can make it do everything. It can be your terminal. It can be your app launcher. It can be your desktop environment. It has a built in browser, several mail clients, games, and a built-in therapist. This is the problem with Emacs: each user has a different idea of what Emacs even is. For me, it's a neovim with a better configuration language. For the vimtuber Luke Smith, it's a big blob of bloat. For the creator RMS, it's the flagship of the GNU project and first testament to the success of the Free Software Movement. If you're just getting started with Linux, you should probably learn vim first - the learning curve is steep but quick, vi is everywhere, and it feels cool to use hjkl navigation. But remember that whatever someone says about Emacs, they are not entirely correct. It is here now, and will be here for you when you are ready.

Some disagree with such definition, but I call Emacs "a classic editor", witch means a human-computer interface, witch happen to be called editor because anything we do on a computer is visualize and/or edit something. The first workstations, like the classic Xerox Alto actually was an "editor-desktop environment" (Tioga) https://youtu.be/z_dt7NG38V4 witch was different from Emacs but essentially equal in "editing as a human-computer UI", Emacs was NOT born with such goal, but for instance Zmacs, the Lisp Machine Emacs port, was, since it was the LispM desktop environment and so on. Essentially, Emacs can be: - your windows manager, a flexible tiling one, EXWM (my favorite, since I discover it I was UNABLE to came back to classic floating or tiling WM) a random example from an YT search https://youtu.be/CLX7oGjYhBU; - your personal information manager, files for instance managed as org-mode attachments, accessed via org-roam in a search&narrow style instead of traversing a classic filesystem tree, but also a classic powerful file-manager (dired) that allow quick filenames editing, moving, deleting etc BETTER than modern ones, who are better generally just in previewing terms (dired offer thumbnails with some extensions, but they are slow/limited compared) see for instance https://cestlaz.github.io/posts/using-emacs-38-dired/; - you mail client, with a local maildir and GMail-alike search, see for instance https://youtu.be/g7iF11qamh8; - your presentation software and office suite with org-mode, with so many features for so many use I suggest this a showcase https://youtu.be/B6jfrrwR10k - many, many more, from a Home Assistant UI (hass) to a connected dildo control device (deldo.el), a simple top replacement (proced), a REST client for some on-line retail service etc Essentially you might want to tray it for a use or another, like "I want another IDE", then IF you have patience to learn you might discover many others (re)discovering the classic desktop model, the user-programming concept where extending your desktop is just write a small bit of code (a sexp) embedded anywhere, also in simple documents like an org-mode elisp: link or a function not much different than a shell function, but in a 2D graphic environment instead of a CLI. The downside: it's fragile because it's born around 50 years ago and still developed today by very different peoples with very different knowledge, so various layers might be not much known to many new devs and especially with third party packages something might be broken or break something else. Since it's recent popularity respect of the very past was less than Vim witch is itself far little used/developed compared to pretty anything else there is some "age debt" where something is there but feel old and ugly while it's very powerful and potentially revolutionary. The builtin feed reader NewsTicker is an example, GNUS is another. By itself is revolutionary: you can have with THE SAME UI and model mails, news, Reddit, HN, feeds, ... with personal scoring and so on. Unfortunately is born in another era and not much evolved since then, for instance is not threaded, you can wrap it in a separate thread or process, but by default many operations are blocking, for the entire Emacs, many are slow, sometime it freeze witch is very annoying. IF you have patience and interest you'll easily see that the advantages pass by far the annoyances but it takes time to learn and pay back countless of time later. Not all accept such classic model preferring something quick and ready even if without a real future.

Around here on this subreddit, you get people who try to live in Emacs as much as possible, and so they use it for their email, their terminal emulator, their calendar, git client, etc. Depending on your use case, it does all of these things well. I personally like using Emacs mostly as a text editor, and use other things for the rest of it. All are valid approaches.

Whether any particular application "works well" depends enormously on the effort that has gone into that particular application, and what your (being the end-user) expectations of it happen to be. YMMV, essentially. The main advantages of using something inside Emacs are (a) familiar/consistent keyboard-driven user interfaces; (b) not having to switch between entirely-dissimilar programs in order to do the things you do (and in turn getting to leverage general-purpose features of Emacs across all of those applications); and (c) extensibility -- pretty much *everything* can be customized one way or another, so users have an enormous amount of control over the child applications they use and, should they choose to dive down the rabbit hole, can bend most things to their personal preferences (making Emacs *your* application, rather than merely *an* application). OTOH those other non-Emacs programs written for one specific purpose (and possibly by a whole team of dedicated developers) are often slicker (especially graphically), perhaps more comprehensive, very likely easier for beginners (Emacs is so old that many of its conventions conflict with those established in the decades that have followed), and more likely to Just Work (or to guide you through the set-up) out of the box. Using Emacs for something (depending on the something) can require more time spent reading documentation and configuring things than with other programs. There are also limitations -- no one is using Emacs as a photo editor, for instance; and while there are various web-browser options, I believe extremely few people would use Emacs as their *primary* web browser (personally I find it superb for accessing certain web-based documentation without leaving my editor, though). Conversely, there are some things Emacs arguably does better than anything else out there. People have reported learning to use Emacs purely for the `org-mode` suite of organisational tools, or the `magit` client for the popular Git version-control system, for example. Whether the benefits outweigh the disadvantages is all up to the individual. Because Emacs can do so much, the learning curve can feel daunting; but people who do take the time to learn how to customize Emacs, and to understand and write Emacs Lisp code, often find themselves more and more enamoured with the idea of having that level of control over as many programs as possible.

Lisp is a highly dynamic programming language that's been around since the 70s. You could say that emacs uses it like an extension language, but that's selling it short. Lisp has the ability to modify and extend itself as its running. So you're editing in emacs, with this language constantly at your fingertips that doesn't just extend emacs, it has the ability to fundamentally change what emacs is. Which, mostly is used to do more types of text editing. The thing is, when people say all the things that emacs is, it does have this core concept of an editor buffer that manipulates text. So it does all these things from the perspective of buffers of text. Its a different way of thinking about how you do things. Take a look at org-mode, to see what its like to use text to control something other than text.

> Thanks for your expansive response!!! What do you mean Lisp runtime? What is a runtime? > https://en.wikipedia.org/wiki/Runtime_system > Also, > > Why do you strongly recommend the GUI? > The terminal interface lacks features in comparison. The GUI can display images, supports different text sizes and faces, and proportional fonts. And terminals are incapable of representing some key combinations. > Its crazy how 1 program can do so much. Does it do all of these things well? Like the email client, is it any good? There are multiple email clients, and good is subjective. I use mu4e as my only email client and think it's pretty reasonable, but applications inside Emacs are very different than what most people are used to. They see that it's some ugly text interface and think it must be primitive, limited, or hard to use.

I use Emacs as my desktop environment. This gives me an easily customizable set of global hotkeys and a tiling window management where I can easily take notes and file them with a few simple keystrokes.

Honestly, the whole vim vs emacs is very stale and tasteless debate. End of the day, they are just text editors. You can use anything, from a beast like intellij to vs code to Vi, just don't use Ed please :) Yes Emacs has a ton of plugins, but so does Vim, or intellij, or vs code. One thing to note is that sometimes you would have to use vi if you are working in a software company. You have to ssh to a box, and there almost guaranteed to be Vi, but not emacs. Other than that, whatever makes you happy. I like Emacs because I like Lisp, even never had a chance to use if for a real project.

Emacs is a software platform. Emacs is THE GNU OS.

> what is a runtime? The CPU in your PC executes machine code, which is the most “low-level language”, and it consists of a few hundred instructions (there are more instruction on x86 (also called Intel/AMD) architecture, than on ARM architecture). There are two main ways programs on your computer deliver that machine code to your CPU: by running already compiled code, and by interpreting code. Compiled code is faster to run but in order to be able to run it you need to first do a step called “compilation” which is time consuming. Compilation is a process run by a program called “compiler”. Compiler reads the human-readable code written by a programmer and turns it into machine code, the output of successful compilation is a binary file (e.g. “.exe” on Windows(tho not always true)), and you can run that binary file as many time as you want without any sort of waiting for it to build (because it's already built, thanks to compiler). In order to change code’s behavior, you'd need to edit original code and compile it again -- there is no way to modify the behavior of the compiled binary by telling it “hey you, you change yourself!”. Please note, the explanation is correct in layman’s terms, but massively oversimplified with a great level of detail skipped (loader, linker, os calls, dynamically linked libraries, compiler optimizations - Google to dig deeper). Examples of compiled languages: C, C++, Rust. Interpreted languages work differently, they skip the compilation step and the code is stored in a human-readable format. At some point when you decide you want to run that code, you need to feed it to a program called “interpreter”. An interpreter will read the code and on the fly generate machine code, however note that there is a performance penalty involved is such on-the-fly code translation. As opposed to compiled code, each time you'd wish to run that code written in interpreted language again, you'd need to feed it to the interpreter, which would again take its time to translate the code from human-readable code into machine code (tho there are tricks to greatly speed up the execution time, eg byte-compilation or native-compilation). One of the biggest (if not *the* biggest) benefits of using interpreted language is the fact you don't need to wait for your code to compile to test it (it's a tradeoff: you gain the speed as a developer because you can test your code faster, but your program has worse performance) and also you can “step into” the interpreter. Stepping into in practice means you can define variables and functions and you can change their values manually, and the interpreter will remember the values until you manually delete these variables and functions from memory or until however long the interpreter will be running - this job is done by the interpreter’s *runtime*. Examples of interpreted languages: Python, JavaScript, Elisp (Emacs Lisp). > Emacs is a Lisp runtime To put it in other words, each time you're opening Emacs, you're looking at the running engine while sitting inside the engine, and you're free to extend it and modify it and test your changes live. If you wish, you could change the code behind a function named “add” and just like that you fucked up addition for every single thing that will try to add two numbers together in your emacs session, and things will stay that way until you either restart your emacs or you reassign correct code back to “add” function. If you wish to make your buggy “add” function to be more permanent, you could add it to .emacs.d/init.el file, that way it will get loaded each time you start emacs.

I'd just add that Elisp is a Lisp dialect that, in particular, has text-editing constructs. More particularly, its programming objects include buffers, windows, etc. Lisps generally have things (data types) such as numbers, strings, vectors, and lists. Elisp adds text-editing things.

But GNU is the GNU OS. (Well... mostly.)

As a non-programmer who uses Emacs daily, here’s the answer I wish I had when I was in your shoes: Emacs is a text editor that’s special because it has its own programming language, Emacs Lisp, that lets you write little macros and programs that make the editor work in a way that fits your style best. This may not sound like a big deal, but if you spend most of your day writing words, like I do - taking notes, writing articles, writing responses, writing memos - then anything that can make writing text more efficient is a huge boost to your productivity. It has an email client, but if you’re expecting something like Gmail you’ll be disappointed. Some of the things I use Emacs for are for outside of writing are to keep track of some of my contacts, as a desktop calculator, to make todo lists, and to help prepare my taxes. If I were you I’d check out “Emacs org mode”. It shows a lot of useful things Emacs can do. That’s the non-programmer perspective!

> what else does it do I use emacs daily to * todo list and take notes, using org-mode. Which is, sure, text editing, but org-mode is specialized for those activities. * Do things in shell (vterm). * Oh and write code.

Emacs is difficult to summarize, because it’s at once very simple and very deep. Emacs is a text-editing-oriented LISP engine. That means its purpose is to facilitate text editing. However, the WAY it does that is very special, very LISPy. This kind of gets to the heart of why emacs is what it is. You see, when you compile a normal program you end up with, well, a program. A chunk of (hopefully) immutable instructions. That’s the end of the story. But LISP is different in two important ways. First, a LISP program continues to exist, in development mode, while you run it. In a sense, you live inside the program and can continue to add to it and modify it whenever you want to. This is what happens every time you start emacs—the program starts kind of nude and then executes LISP code, which incrementally modifies the program into a larger program—your emacs. The program you are actually running, which we collectively call “emacs”, is most likely entirely unique to you. Second, LISP programs are written as LISP data structures and LISP is VERY good at manipulating LISP data structures. LISP programmers often write code that modifies code, or write data that controls code, or write data that controls data, because to the LISP programmer they can all be the same. The saying along LISP programmers is, “it’s just data,” used when referring to absolutely everything. This second difference is important, because it’s a metaphor for emacs as a text editor. You see, in emacs, everything “is just text.” It’s not a joke. You kind of have to go on the journey to really understand it, to “grok it.” There is a “mode” that comes with emacs, called dired. When you open a directory in emacs, this is what pops up. The first few times you hit it, you think “oh, I’m in the file opener” or something. You boop around, find the file you meant to open, and don’t give it much thought. At some point you’re in dired in a large directory and think, “man, I wish I could search in here” and in a bit of defiant pique, you try it. And. It. Works. “Okay, neat.” You think, and don’t give it much thought. Later you’re in dired again and you really want to rename this damned file under your cursor. You discover wdired. You rename the file and move along. You get back to your file where you were experimenting with rectangle edits. You pause for a moment, go back to wdired and try rectangle edits on your file system. And. It. Works. Okay, you try a macro. Of course it works. It’s just text. Regep replace? It’s just text. The permissions column… yes everything. Okay, dired has a recursive search. I’m going to find every mp3 and turn on wdired in the search results. Surely it won’t let me—holy shit EVERYTHING works here too. In emacs you can record macros. You can also stores those macros as functions and edit them. Macros have no boundaries, because they’re just emacs programs. Anything you can do in emacs can be done in a macro. So, you can record yourself copying the sender of an email and pulling up their commit history or pull requests and save that as a function. You can bind that function to absolutely anything, and, depending on how carefully you did it, now you can do that for any email address anywhere in emacs. It’s quite insane. So, is emacs a good email client? It’s not bad. But that’s not the point. Any email client in emacs is infinitely more *useful* than one outside emacs. Is emacs a good terminal emulator? It’s pretty OK. Quirky, maybe. But that’s not the point. In emacs you can move text into and out of any part is the terminal at any point. You can run a command and EDIT the output. You can run a command and EXECUTE the output, or part of it. Perhaps the only useless mode in emacs is Tetris. But I still use it. Because it’s in emacs. And, if you’re feeling cheeky, you can interrupt Tetris and edit the game state and resume right where you left off. Because it’s emacs.

Wow! Thanks for the ellaborate explanation!!

Thanks! Could you explain thiss buffer concept you mentioned?

Its a shame about the terminal, I'm kind of drawn to the idea of doing as much as possible from the terminal. Would vim then be a better option for that?

Emacs is more like an OS. Basically everything is built around the Emacs-Lisp language. Thats why it is so extensible and easy to modify, because anybody can build their own software on top of the base program.

Why do you prefer not using emacs for as much as possible?

Interesting, thanks! A difficult decision for sure.

The way I understand it, it's a small elisp runtime, and a large elisp script, that's the editor, a giant elisp script.

Very interesting. Do i still need to install a windowmanager/desktop environment or could i just use emacs instead

Nice, so i wont even need to install a windowmanager/desktopenvironment I can just use emacs instead?

Interesting, so for anything regarding remote access its unlikely that one would be using emacs?

Lol, im a little confused

Thanks! I'll look into Org Mode Did you use vim before you used emacs?

Nice! So you use it as an IDE? For what language do you use it?

I'm also quite new to the subject but I think there is something like a tiling window manager in Emacs called (EXWM).

I personally don't have a problem with what's working for me right now. E.g., I only use macOS's built-in mail client, and it works well enough for what I do. Eventually, I'll probably try to get Emacs configured for my mail, but not really anything pushing me to that.

There are frames windows and buffers. The naming is based on old terminology so is not the most intuitive in the world. Frame is a emacs window (in Windows OS you have “_ [] X” buttons at the toolbar to minimize/maximize/close window, clicking on “X” would close emacs frame). Emacs frame will display one or more emacs windows. Window is the way you split your viewing area, you can split it horizontally or vertically as many time as you want. Inside emacs window you display emacs buffers. You can have as many buffers as you want. The buffer is not tide to the window, meaning closing a window will not close the buffer, and closing the buffer will not close the window, and you can also display one buffer in multiple windows simultaneously. Buffer is a space where information is being stored in emacs. When you open a file in emacs to view/edit, the contents of the file will be stored in buffer. Your email client will list your emails in a buffer. A list of all possible commands (M-x (M = meta = alt)) will also be stored in a buffer. Any piece of grouped text you're looking at in emacs has it's underlying buffer

Emacs works just fine in the terminal, however there are features which are not available in the terminal, like displaying images and rendering webpages (via xwidgets Webkit). > drawn to the idea of doing as much as possible from the terminal You can launch emacs in terminal, and inside that emacs run terminal (term, vterm or eshell) and do everything there if you wish :) (you can even open vim there if you're into inception-things haha), however Emacs offers you ways to do all the things via shortcuts which become part of your muscle memory, for example in the past I used to do <open terminal> git add . <enter> git commit -m “MSG” <enter> git push origin master <enter> and nowadays in Emacs I do <space> g g S c c MSG Ctrl-c p u and not only it's done, but I also get to see whole git-related dashboard/summary - what am I committing, what's the message of last commit, are there any unpulled changes from remote, how many unmerged commits are sitting on my PC etcetcetc If you're interested I recommend you try doom emacs (pre made emacs config), I found it the fastest way to get off the ground

"my first major decisions seems to be Vim vs Emacs" Why do you feel you _have to_ choose? No one is forcing you. Ultimately _you_ are using it so explore, experiment and use what you like. Really there is no wrong answer. I use and like Emacs because life's accidents brought it to me and it sticks but honestly the _Vi vs Emacs_ is just a tired meme at this point.

You may also want to search YouTube for the recent talks from EmacsConf 2022 to see the wide variety of things you can do with Emacs today.

Wrong. You can edit remote files with Emacs or use a package manager to quickly install a pre-built version on the remote host.

Under the X window system only, there is the EXWM window manager. On other systems, you run Emacs as a normal windowed application but most utility programs you need then run inside Emacs.

That quote doesn’t make sense because it looks like emacs is the one being replaced, not the other way around tho

There are lots of long and confusing answers here. My simple answer is this: Emacs is really a kind of Lisp programming language that is designed for text editing and shell program control. In some ways, Lisp is for Emacs what JavaScript is for your web browser, it lets you write text editing apps. So you can edit text, but more importantly, you can write scripts in Lisp that edit text for you, once you have learned how. The most useful Emacs commands can be activated with key chords like `Ctrl-Alt-%` for find/replace, so it is useful even if you do not know the Lisp programming language. Emacs is also a shell, so you can launch programs just like you would in the command line. But since it is a text editor, you can capture the shell output in a text buffer and edit it (`Alt-&`). You can also feed any text buffer into any shell program (`Ctrl-U Alt-|`). So this makes Emacs just as powerful as any other shell program like Bash, Zsh, or Fish.

No, I've never used vim. When I was first choosing between Emacs and Vim, I read somewhere that Emacs was better for programmers, and Vim was better for jobs like system administrators. I now know that's not true, that both Emacs and Vim are incredibly sophisticated pieces of software. I think it's fair to say that in almost every case one editor can do whatever the other can do. They also both seem more capable than the newer editors, most of which only have a GUI and can't be used in a terminal (which is a big plus for Emacs/Vim). But, at the time, that persuaded me to use Emacs. Still, I'm glad I went with Emacs. I've found Emacs Lisp to be really useful, and much easier (for me) to understand than the scripting language that comes with Vim. Plus once I learned Emacs Lisp, I found I was able to follow along other programming languages better - certainly Scheme and Lisp, but even something like basic Python now makes sense to me. So I felt like I got a two-for-one by learning Emacs Lisp: a useful language to make my writing more efficient, and a window into other general purpose programming languages. Another helpful thing about both Emacs and Vim is that *because* they've been around so long, people have tried to use them for almost everything. That means that whenever I've searched for how to get Emacs to do something I needed, there has always been an answer already posted on how to do it. This may or not be the case with editors like Atom or Sublime that haven't been around as long. For example, a few years ago I needed to send out a mass email, sending out a message to the several thousand addresses I had on my list. I had no idea where to start, but I searched for an answer and, of course, someone had asked how to do this and received an answer. I copied the Lisp code and it worked perfectly. If you want another perspective on how Emacs can benefit people who aren't programmers, there's a terrific video from a professional writer (who, like me, doesn't know how to program) who learned Emacs to help him write a book. He explains everything really well. Check it out [here](https://www.youtube.com/watch?v=FtieBc3KptU&t=755s).

Wow that explanation you gave using dired is amazing! Thats example just cleared up so much for me in terms of what Emacs actually is! You honestly ought to have like a tech site or blog or something. Thank you very very much! Edit: thanks again for taking the time to write that all out for me! Enjoy the award!

And then there are [image based programming languages](https://wiki.c2.com/?ImageBasedLanguage), where both the user and the developer work inside the running program (the "image"). The image itself consists of the implementation of a language, some editing and debugging facilities, compiler *and* interpreter and the functionality and data of the actual application. The image gets modified by the user/developer through defining and running portions of its functionality (i.e. through writing source code and applying functions). Written/modified application source code can then be interpreted or compiled by the system in order to assemble wanted functionality. Portions of functionality can exist in compiled state, while other portions are interpreted within the same image. All (or most) portions of *functionality ([and data](https://lispcookbook.github.io/cl-cookbook/clos.html)) can be redefined, while the program is running* and their representation (compiled or linked) within the image can change. In my view, `Emacs/Elisp`, `Common Lisp` and `Smalltalk` are such image based systems/languages, they don't fit in that pure "interpreted" or "compiled" language scheme. (Python and many other "interpreted" languages lack the redefinition facilities. i.e.: you have to restart a program in order to change previously existing functionality)

Emacs is a runtime environment for elisp (Emacs Lisp). It can be whatever you want. That's where the "Emacs as OS" come from. Ppl write packages for music management, project management, personal knowledge management, calender and personal time management, bibliography, file management, blog publishing, etc... ...and many, many more use cases that don't all have directly anything to do with text editing or programming. It truely is whatever you can come up with how to manipulate text/data for. And now you know.

Cool!

Is it difficult to manipulate or is some basic programming skills all you need?

emacs in fact excels at remote editing operations. I'd read the parent post very literally ... If you ssh into any random Linux box, it is likely to have vim available, but not necessarily your favorite emacs setup/configuration. You can certainly use text-mode emacs remotely, though.

I use it for everything except web surfing, IM, and email. Which is still quite a bit. But yeah: I am devops so shell / text editor is an IDE for me, and it’s handy to have them in one interface. I’m currently doing shell and python. Things I would like to shift over to emacs; Jira Slack Git operations Updating confluence.

thats remember me when I come to Emacs and was searching documentation in the web and couldn't understand why these people said that "Emacs is actually an operative system" ¿Is just emacs a text editor?. I'll say you that only way that you can understand is trying by your self, but this is my point of view: Emacs is an editor highly customizable, that's mean that has its own code interpreter in real time (what?), i mean, you add elisp code to emacs, and emacs will run this code and implement in its own configuration, so, you can buid all you want with Emacs. I mean, not only configurate key bindings or font, actually Emacs behavior. But why an operative system?, this is so interesting for me, because the Emacs community phylosophy seems to be dont leave Emacs if possible. Since I start in emacs, i found me looking for ways to dont leave emacs at all cost, even when exist other programs that do other stuff better (like see an pdf), I really love emacs and its philosophy, I am trying to dont leave emacs too, even when configurations for do an specific stuff make me "waste" time (actually improve your workflow in future). When you realize that you can dont leave emacs if you don't want, even for banal activities like listen music, whatever you want, you understand that Emacs is not just an text editor, and actually it can become in a lifestyle. In other hand, there some missing stuff, or that can be improved, but its free code, all we are welcome to contribute.

Exwm is great in certain cases, but don't start with it. I've been using Emacs for ~8 years and WMs for 2-3 and it was still rough. Use something simple like i3 to get used to WMs, learn Emacs, and then at some point when you feel comfortable writing elisp try out exwm.

Wow, that's very interesting, never heard of it before. In the first link and they've mentioned smalltalk and I remember checking out https://gtoolkit.com which I think has some of the ideas from emacs but is implemented in smalltalk. I always wondered if gtoolkit could fundamentally offer something emacs couldn't (at the principal level) but now that you've lebaled them together, I think I know the answer is no

Ah i see, thanks!

You definitely need programming experience, and also you need to have had the experience of switching to (learning) another language before. Especially if you want to create packages for Emacs or customize things that go beyond trivial settings. There are exceptions, i.e. there are ppl who only use it for writing (itself), but those cases are very niche, I think. Most ppl who use Emacs use it for some form of computing, if not directly for software development. Obviously if you just wanna use it, the skill requirements are lower than if you want to extend it (as in writing own code for interacting with Emacs packages, or writing your own Emacs packages).

I feel like it would take a lot of time to learn and become proficient at either one, so I guess I dont have to choose *permanently* but if I make the wrong decision now then I will have to start from scratch with the other one later on

Thanks for the tip!

Oh cool, thanks! &#x200B; When you say edit remote files with Emacs, how would one go about doing that? Or maybe that is too broad of a question, ive never even used ssh before

Ah, is there benefit or cost to either way of doing things?

Thanks for your perspective! Indeed both seem very powerful! Edit: I will check out the resource

hmmm interesting, I think i do not have quite enough understanding about remote editing and emacs to understand what using text-mode emacs would entail / look like

Thx!

The don't leave Emacs if possible philosophy does sound very appealing to me!

I cant say anything about GT, but it certainly is no new idea. [Have a look what was possible 30-40 years ago on the old Symbolics Lisp Machines](https://www.youtube.com/watch?v=o4-YnLpLgtk) which are an incarnation of that idea. Maybe the GT guys have done something right and it is worth it. In this context I like the quote of Grady Booch on GT.

Thanks!

Thanks!

>And then there are image based programming languages, where both the user and the developer work inside the running program (the "image"). The image itself consists of the implementation of a language, some editing and debugging facilities, compiler and interpreter and the functionality and data of the actual application.The image gets modified by the user/developer through defining and running portions of its functionality (i.e. through writing source code and applying functions). Written/modified application source code can then be interpreted or compiled by the system in order to assemble wanted functionality. Portions of functionality can exist in compiled state, while other portions are interpreted within the same image. All (or most) portions of functionality (and data) can be redefined, while the program is running and their representation (compiled or linked) within the image can change.In my view, Emacs/Elisp, Common Lisp and Smalltalk are such image based systems/languages, they don't fit in that pure "interpreted" or "compiled" language scheme. > >(Python and many other "interpreted" languages lack the redefinition facilities. i.e.: you have to restart a program in order to change previously existing functionality) Thanks for the explanation!

I'll definitely look into it! Though i might first try just GNU Emacs, just to get a hang of the basics

Okay great :)

If you ssh into a box, and you "only" have terminal-level access, you can use /most/ of emacs, since – as you've probably been described eleswhere in this thread – much of emacs is built around simple text-uis. So, like, the excellent "magit" git porcelain in emacs will work just as well in gui emacs as it will in tui emacs. There's certainly things only gui emacs can do, or improvements over tui emacs. But /lots/ of what's available will work. You can get the same effect / compare them locally by starting `emacs -nw` to stay in text ui mode. On the pure remote side, you should look into TRAMP for remote system operations. It's pretty great.

When you say, emacs is also a shell do you mean you can run bash commands in it?

Thanks for the advice!

Thanks! Is TRAMP also an Emacs thing?

[yes](https://duckduckgo.com/?t=ffab&q=emacs+tramp&ia=web)

Cool! Thanks!

Thanks! The video on the window manager is very cool. He is using emacs as a windowmanage so when he opens discord does that mean, in a way, that he is opening discord in Emacs? Hmmm the lack of mulithreading seems like a major thing that could be holding emacs back, no?

> Zmacs, the Lisp Machine Emacs port, was, since it was the LispM desktop environment Zmacs was just one applications on the MIT Lisp Machine (and derived systems). Most applications on the Lisp Machine were not based on Zmacs. Zmacs wasn't the desktop environment.

Mh, I know only the emulator but... zmacs in the emulator is essentially the UI, what's the rest of the desktop if not zmacs?

> He is using emacs as a windowmanage so when he opens discord does that mean, in a way, that he is opening discord in Emacs? In the sense that's inside the Emacs frame, with the minibuffer underneath etc, yes. In practice is just a process hierarchy, X run Emacs who run the rest, the "order" does not matter much beside the wow effect :D > Hmmm the lack of mulithreading seems like a major thing that could be holding emacs back, no? IME, as an EXWM user not much, in the sense that blocking operations happen to be noticeable in practice are VERY few, like a package upgrade, but sometimes if Emacs freeze it's annoying since your desktop it's frozen... IMO before EXWM you need a stable Emacs config, once anything is done as you want adding EXWM is almost issueless, at first you might feel lost, but it's a small phase. Changing the config/frequently tweaks Emacs in EXWM is less nice since anything impact the whole desktop but the outcome is so positive that all annoyances while they do exists are far less important then the advantages...

No, Zmacs in the emulator is not the UI. The Lisp Machine has a GUI with a full graphical window system. On a Symbolics the Listener, the Document Examiner, the File Browser, the Process viewer, the Debugger, the Window designer, the Namespace Editor, the Inspector, the Terminal, the System Menu, the Preference dialogs, ... none of those are using Zmacs.

>In the sense that's inside the Emacs frame, with the minibuffer underneath etc, yes. In practice is just a process hierarchy, X run Emacs who run the rest, the "order" does not matter much beside the wow effect :D Ah so its not like, if you run discord in emacs that you can then use emacs keybindings in discord?

> When you say, emacs is also a shell do you mean you can run bash commands in it? Well yes, sort of. You can use Bash from within Emacs `shell-mode` and from `term-mode` (terminal mode). This can also be used to run REPLs like Python, Perl, Ruby, Julia, Common Lisp, Scheme, really any language that has an interpreter REPL. But `shell-mode` and `term-mode` require an external Shell program like Bash ("Bourne-Again **Shell**") Dash, ZSH, Fish, or Nushell. These shell programs are written in other programming languages like C or Rust. What I really mean when I say "Emacs is a shell" is that Emacs can actually replace Bash -- you can use Emacs instead of Bash to run command line programs. So the key shortcuts I mentioned above: > ...you can capture the shell output in a text buffer and edit it (`Alt-&`). You can also feed any text buffer into any shell program (`Ctrl-U Alt`-|). > these let you actually run shell commands *directly* without needing to use Bash or any other shell at all. Emacs is it's own shell. Emacs handles the child process and console logs with it's own internal programming. In fact, there is a Bash-like command line shell written in Emacs Lisp [called `eshell`](https://www.gnu.org/software/emacs/manual/html_mono/eshell.html ) which works like Bash or Zsh, but it is more similar to Fish or Nushell in that it has a different syntax. Bash and ZSH are shell language interpreters compliant with the POSIX standard, shells like Fish and Eshell are not. This is all because Emacs is not an Editor, it is an interactive Lisp programming language designed for editing text. As a full programming language, it can do all the things other programming languages can do.

Interesting, thanks!

Only partially, you can use the WM bindings, since Emacs get them first, but for instance you can't use native Emacs editing inside an X11 app.

Ah okay, I think i understand Though what is an X11 app?

A graphic application, essentially any non-Emacs app inside EXWM. Formally you can wrap pretty anything, but practically it's something limited to some frequent shortcut otherwise you have to write a gazillion of bind for anything and still only mimic Emacs...

Ah okay, so only with terminal stuff can you use emacs wm key binding?

Only with Emacs, you simply get: - Emacs windows management, witch means a VERY comfy tiling WM easy to tweak with very little code (in many forms, from a simple function bound to a key to an org-mode `elisp:` link witch allow for graphics scriptability very close to easiness of CLI/shells one. You can have "perspectives", i.e. programmed Windows layouts even in many tabs if you like them etc; - Emacs get any key press first, so you can execute anything in Emacs, like fire up a posframe minibuffer for M-x, org-roam-node-find, counsel-linux-commands etc while Firefox or anything else is focused; Essentially a MODERN, effective windows management like no "modern" (in reality archaic) WM/DE/DS can offer. The price is the long config phase and the casual bugs/freeze. What you get is a far more effective and comfy desktop usage, something modern users can't even dream simply because the maximum they got are modern limited tiling WM. Just see https://youtu.be/B6jfrrwR10k as a generic example of easy Emacs automation.

Thanks!