Can vim become an emacs or is it already one or not?

\>an emacs\[1\] This assumes that emacs is not a single program; GNU Emacs, but a class or type of program of which there are multiple implementations; emacs with a small e in the same way that there are different Lisps. Do forks of emacs count, such as long dead XEmacs? What about the aspirational and mostly abandoned attempts to rewrite emacs in Common Lisp, R or other languages? The so-called distributions such as Doom are a configuration veneer that runs on top of Gnu Emacs so they can not count as an emacs either. There are a number of light weight editors which use Emacs key-binding conventions but they are certainly not "an emacs". Unless there is something I am not aware of, there is only one emacs: GNU Emacs. If there WAS a class of emacs programs, I agree that the extensible e in emacs is the most important thing. Emacs does not have an extension language or an API for extensions. When you write and run elisp it becomes a part of emacs. Emacs has packages which become part of Emacs when you run them. There are no plugins. From what I have read this is not the case with vim+vim script, even if it is Turing complete. I would also find it hard to call anything "an emacs" that didn't use Lisp. Homoiconicity is far more important than it is given credit for. Lisp and a handful of other languages have it, but most do not. Emacs is large, it contains multitudes, but there are not a multitude of Emacs. \--- \[1\] For some reason this reminded me of the most common brand of soy sauce in Cambodia (because it's cheap as dirt), which is simply called "An Ox" (brand soy sauce) which has a charmingly cheap and retro depiction of a bog standard garden trampling Brahman cow, with a suitably inscrutable demeanor. [https://circlekcambodia.com/shop/an-ox-lable-ox-soy-sauce-6x450ml-btl-8/](https://circlekcambodia.com/shop/an-ox-lable-ox-soy-sauce-6x450ml-btl-8/)

I agree that being "an emacs" means being one of those variants and offshoots of the original editor, and no one calls an extensible editor which has nothing to do with that tradition "an emacs". (I think there are a few people using things other than GNU Emacs, they pop up on the mailing list from time to time. Last I heard Torvalds was still using MicroEmacs for some reason.)

Where did you read that definition?

This article says so. https://www2.lib.uchicago.edu/keith/tcl-course/emacs-tutorial.html

> an emacs My source is this article. I do not know enough to argue on this point. https://www2.lib.uchicago.edu/keith/tcl-course/emacs-tutorial.html I do not understand some of the things you say. Can you please clarify? > Emacs has packages which become part of Emacs when you run them. There are no plugins. How is this different from vim plugins? I always thought plugins just meant extra code in that language like a python module. For eg, there is no difference in principle between standard python library and python modules people have written, right? They are all just indistinguishable python code to the interpreter. Is this different for vim and other programs? If so, why? >Homoiconicity is far more important than it is given credit for. Lisp and a handful of other languages have it, but most do not. Please elaborate.

I think it's misleading. Extensibility is a necessary but not sufficient requirement for being Emacs.

Vim and Emacs are not two editor, as many see them, as unfortunately some devs advertise them, Vim is the Unix editor, witch means is the Unix companion, witch is the first admission from Unix devs that Unix model does not work, the second one happen when unices got GUIs. Emacs is an ecosystem lacking something underneath to connect it to the hw, since we miss LispM or something like them. That means: Vim is part of an ecosystem, designed to be used inside it. Emacs is a self-contained ecosystem. You can pipe text to both of course, but Vim is meant to be quickly called from CLI, used as a part of a CLI, not to live inside Vim. That's not a critique of both, they are simply two different projects with a big legacy and different targets. In that sense the advantage of Vim is unix, meant Vim is already complete, Emacs lacking a kernel and a bootloader INSIDE the system is incomplete. On the other side you can do pretty anything, X11 windows management included, in Emacs, while you can't in Vim, at least not without completely change Vim itself.

You mean TECO & Co.? That is going a little too far back. I think the wording in the article is a bit misleading. Those were ancestors of Emacs more than "an emacs". BTW The PDP-10 was the second computer I spent substantial time using and the first that had a video display. The disk drive was a stack of platters that you had to clean using this scary thing that worked like a dishwasher. Most of the time we used tape drives and the console went straight to a dot matrix printer with a keyboard.

>If there WAS a class of emacs programs, I agree that the extensible in emacs is the most important thing. Emacs does not have an extension language or an API for extensions. I'd add: *extensible* not only in the ability to add new functions but also the ability to change the behavior of all existing functions, whether through hooks, advice, or redefinition. Advice, in particular, is potent. Here we advise `memq` (a C language built-in) to return `'t` instead of its usual return value when the comparison succeeds: (defun ii/memq-p (&rest args) 't) (advice-add 'memq :after-while #'ii/memq-p) (memq 1 '(1 2 3)) ;; (advice-remove 'memq #'ii/memq-p) This isn't trivial (though it's obviously a contrived example).

What else then other than lisp? It's certainly not keybindings. The only other thing is "self-documenting" which brings us back to lisp. Emacs is a lisp interpreter that is used to create a badass text editor, and email client(s) and git porcelain and IRC client and literate programing platform and hundreds of other things where everything is treated as plain text. It's all plain text, all the way down. Extensibility is the "e" in Emacs. It's part of Emacs' DNA. The very fact that Vim folks can extend and customize Emacs to the point where a few poor souls deny that they are using Emacs (as if it were toxic waste). "Oh, I'm a vim user, using Doom" or Evil or whatever. Anything that is that powerful sort of speaks for itself. I would like to add that you shouldn't conflate the tools you use with your identity. Use the tools that are the best fit for the task at hand. That might be Vim, it might be Emacs. I personally seldom use Vim any more because Emacs is a better fit for my work. YMMV. That's it for me this evening on this topic, unless anyone wants to talk about brands of soy sauce they are especially fond of; or better yet OYSTER SAUCE.

That definition doesn't even mention what kinds of software we're talking about, for a start. You could make a fully extensible web browser, that wouldn't be "an Emacs". You could even make a fully extensible editor that wasn't. Like I said elsewhere 'being "an emacs" means being one of those variants and offshoots of the original editor'.

Vim/neovim is scriptable with a dozen of different languages, among them a few lisps. So it could become an emacs like system but it isn't. The default configuration does not resemble any emacs, the default keybindings, nor the UI resemble emacs and the all known classic tools aren't there. It does not have the legacy of any emacs. I was thinking of using neovim as an emacs, but it's simply easier to stick to emacs of you need an emacs. But people already port stuff. There's spacemacs and there's spacevim. Both the current vims and the current emacs can be used as emacs but most users stick to emacs of they need emacs

Systems called Emacs have been around for ages--several are as old or older than Gnu Emacs. Linus Torvalds still uses and maintains his own version of the ancient MicroEmacs, which has a *small* extension language (smaller than vim's). Jove (Jonathan's Own Version of Emacs) is older than Gnu Emacs, and doesn't have an extension language at *all!* The original Emacs was a set of macros for the TECO editor. It inspired a *number* of spin-offs and copycats. Gnu Emacs is the best-known and most popular of those, and is certainly what most people mean when they *say* "emacs", but it does not have exclusive ownership of the (borrowed) name.

That definition is arbitrary and historically inaccurate. Bottom-line, the whole thing is a mess! :) Emacs was originally a set of macros for the TECO editor, and the name has been used for a wide variety of editors inspired by that original Emacs. Some of those editors lacked *any* significant extension capability (such as Jonathan's Own Version of Emacs, or JOVE, which predates Gnu Emacs, and is still in use). As Gnu Emacs (and its fork XEmacs) gradually became *the* emacsen, though, new systems stopped being called Emacs, and were instead referred to as emacs-like (such as the Minix editor ELLE, which stood for "ELLE's Lots Like Emacs", or the MS-DOS editor Epsilon, which was a near-clone of Gnu Emacs, except for its C-like extension language). At this point, the difference between being an "actual" Emacs and simply emacs-like is historically confused and unclear. There is no trademark, so nobody can tell Jonathan that his Emacs can't use the name. But in general, I suspect most people would object to *any* new system being called an Emacs if it wasn't a fork of Gnu or *amazingly* compatible.

Glad someone still remembers Jove! That was where my Emacs keyboard muscle memory was first developed. Folks at my college (who went to High School with Jonathan) ported Jove to a Data General Eclipse MV/10000 running AOS/VS back in the late 80s. It was the most popular editor among CS students who used the DG.

Jove is still included in Debian, so apparently *someone* is still using it! :)

Homoiconicity means code (eg function calls) and data (eg a list of values) have the same form. Makes certain things like macros easy and elegant.

> For an editor to be called "emacs" the main requirement is that it be fully extensible with a real programming language, not just a macro language. For GNU Emacs, this language is Lisp. I'm going to include neovim in this comparison, only because neovim has far more options with configuration languages than vim does. I personally use https://fennel-lang.org to configure neovim, a lisp that compiles to lua. While it isn't elisp, its still quite good and a lot faster. > One thing I noticed with emacs is that you can very easily run lisp code in it and change the properties of editor with M-: (alt plus colon). What is the vim equivalent for this? I use https://github.com/Olical/conjure/tree/master to evaluate lisps and of course you type in ex commands to change the properties of the editor. Putting `set syntax` in your .vimrc is the same as running `:set syntax` in the command line. You can also add a fuzzy wrapper to look through commands, e.g. telescope, which I have bonded to `SPC-:` like doom does. > Writing applications with vim. Emacs has the ability to create many applications and run them with the lisp interpreter built in. While the same can be done with vim, I have noticed that the scope of vim based programs was much lower than emacs ones. Is this due to limitations of vimscript vs lisp (which is a full fledged general purpose programming language)? With the introduction of lua in neovim, can this be totally changed? Its a combination of vimscript issues with the limitations of a tui. It wasn't until pretty recently we received floating window support and and lua in neovim, whereas emacs has had lisp for years. People were afraid of vim script, not just for having odd syntax but also for being very slow. Any large-scale program like some major-modes for emacs were completely out of the question. With neovim I think its only a matter of time until neovim catches up with emacs. People have some crazy programs, see: https://github.com/nvim-neorg/neorg and https://github.com/alec-gibson/nvim-tetris (the latter is written in fennel too!). My personal configuration is also written in fennel if you would like to take. look: https://github.com/shaunsingh/nyoom.nvim. Neovim's come a long way in what you can do with it. Fennel has a macro system as with any lisp, so you can make the syntax feel right at home with emacs https://github.com/shaunsingh/nyoom.nvim/tree/main/fnl/macros. You can even create dynamic-module like integrations with rust programs (see https://github.com/shaunsingh/nyoom.nvim/blob/main/fnl/parinfer/init.fnl, interacting with https://github.com/eraserhd/parinfer-rust/tree/master/src) tldr: (neo)vim can fulfill that definition, albeit still with a few limitations (proper gui support isn't too good). You can configure it in a lisp and its very fast, capable, and powerful. Its only a matter of time till we see more and more "large" plugins.