
Buying into the Emacs Platform (2018) - unhammer
https://two-wrongs.com/why-you-should-buy-into-the-emacs-platform
======
RaycatRakittra
I love Emacs. For all of its warts, "historical reasons", and vestigal
features, it is the editor that really opened my eyes to alternative ways to
do introspection and programming, in general.

I want to believe the friction comes if you try to "fix" Emacs too early.

You kinda have to conform to the Emacs way when learning it and leave all of
your assumptions at the door. I see a lot of people who come to Emacs from Vim
expecting Evil Mode to be the panacea for Emacs. It's not. At the end of the
day, it's still Emacs and people run into friction because they expect it to
be Vim-ish all over or they want to force Emacs to be Vim.

Personally, I came from Vim to Emacs via Spacemacs. I was a bit of a zealot
about Vim until I tried Emacs. I left all of my expectations behind and I was
pleasantly surprised by many things inside. Were there things I disliked? Of
course. But, I wasn't looking for an excuse to hate it.

~~~
sdegutis
I had a similar path to Emacs: became really proficient with Vim, avoided
Emacs since everyone I knew hated it, saw someone doing things with incredible
speed and efficiency in Emacs at Enova (hi Kyle) that I had never imagined
could be done, tried Emacs myself, and spent weeks customizing it to become
extremely fast with rapid development in Clojure using CIDER.

But now that I do vanilla front-end dev, I have found VS Code to give me
nearly all the same productivity I had before, but with practically no
configuration, and in an editor that actually has _reasonable_ per-pixel
scrolling. (Emacs added per-pixel scrolling in 2017 _but still got it wrong
somehow._ )

~~~
boustrophedon
What is the utility of per-pixel scrolling in a text editor?

~~~
sdegutis
In some mysterious psychological way that I don't fully understand, per-pixel
scrolling helps me to mentally keep my place significantly faster and easier
than per-line scrolling.

------
aldanor
Being a vim guy myself, I only use Emacs (Spacemacs, to be precise, so as to
get rid of all those a-x a-y a-z a-m-s-x type shortcuts and replace them with
something ergonomic) as a git client - because Magit is the best git client
out there.

I’ve tried using Spacemacs as a main editor for a while, but it’s too much of
a mess, and if anything goes wrong (and it often does) you’re stuck with
obscure lisp tracebacks, thanks but no thanks, I’ll use vim or kak as the
actual text editor. I also noticed I spent an enormous amount of time
constantly tweaking my spacemacs config as opposed to doing actual work.

~~~
xenophonf
_if anything goes wrong (and it often does) you’re stuck with obscure lisp
tracebacks_

Is Spacemacs really that broken? I use the same GNU Emacs configuration across
Windows, FreeBSD, Ubuntu, CentOS, and macOS, along with packages like tramp,
magit, slime, and python-mode, and the worst thing that's happened in recent
memory is that either jinja2-mode or salt-mode (I forget which) doesn't indent
things the way I like.

~~~
quanticle
Spacemacs is that broken. The problem is that Spacemacs tries to impose its
own shortcuts onto other emacs packages that may or may not know about
spacemacs. For modes that perform extensive customization of their own,
spacemacs alterations to emacs can result in some very weird behavior. For
example, markdown-mode's highlighting, will, for mysterious reasons break when
used with spacemacs [1].

The other problem with spacemacs is that if you're trying to use another emacs
package, now you have to look up two sets of documentation. You have to look
up the package's documentation to find the command that you want to execute,
and then you have to look up the documentation for the relevant spacemacs
layer to figure out what spacemacs has remapped the command to.

I tried to use spacemacs as a transition path from vim to emacs, but I found
that I had much more success by just "ripping off the bandaid", remapping
caps-lock to ctrl and spending a weekend forcing myself to relearn how to
perform my most commonly used vim commands in emacs.

[1]:
[https://github.com/syl20bnr/spacemacs/issues/11790](https://github.com/syl20bnr/spacemacs/issues/11790)

------
crispyambulance
No thanks.

I've had several bouts of trying to learn emacs throughout my life.

It isn't necessary to list all the benefits, sure, there's a lot. Yes, I get
it's "extensible" and you can write little elisp programs to do just what you
want.

Here's the obstacle: Motor skills. It just takes way to long to first memorize
reams of commands and then to train your fingers to issue those commands
effortlessly. In the meantime, searching, "apropos" and googling stuff isn't
an attractive thing to do when you have _actual_ work to do.

That's a serious obstacle and no listing of all the awesome-ness of emacs is
going to convince many of us to put in that kind of effort.

~~~
fipar
I had a similar experience to yours until I realized that the extensible part
also means you don't need to use the builtin commands and shortcuts. I have
been using emacs for 10 years (used vim for about 12 before that, using emacs
with evil-mode now) and, to this day, I have to google 'how to quit emacs'
when I am faced with a vanilla emacs :)

I just feel it's "my" editor more than any other editor I've ever used.

edit: typos

~~~
klibertp
> I just feel it's "my" editor more than any other editor I've ever used.

So true! When I first tried to get into Emacs it was as a somewhat seasoned
programmer who wanted to play with a Lisp other than Scheme. I've read the
built-in tutorial and almost ran away in horror. I get it - for non-programmer
users, yes, it makes sense to try to teach them the _usage_ of an editor. I
lost quite a lot of time trying to remember exotic chords like C-u C-x ^ a and
so on, but it was ultimately meaningless - not one such shortcut remains in my
config.

Emacs is an IDE for Emacs Lisp written in Emacs Lisp (and it's incredibly
powerful at that, BTW). In other words, it's a bunch of APIs you can call, and
it also gives you the place where you can interactively execute any elisp code
and see the effects immediately in the same instance of the editor. It's
obvious in hindsight, but I believe I'd get into Emacs much faster if I
started with Emacs Lisp manual or maybe "Writing GNU Emacs Extensions" book
instead of going through the Emacs manual (huuuuuge!) first and trying to bend
my habits to fit the vanilla Emacs.

I think most programmers who wish to switch to Emacs should try to do it the
other way: start with learning Elisp syntax and Paredit, then learn about
modes, hooks, and key-maps and start hacking your own config. Everything else
- buffers, windows, fringes, faces, what-have-you - you'll learn as needed
when you need to implement a particular command which deals with them. Pull in
a healthy amount of plugins then read their source - or just read the source
of Emacs, as you can jump to definition of any function in one click, even if
it's written in C - and before long you'll have a comfortable environment to
work in, with all the features you learned to love from your previous editor.
And that's when the fun part start: exploring Emacs features that you've never
seen or heard about, wrapping external tools and streamlining their workflows,
exploring the huge pile of add-ons.

~~~
DanielBMarkham
This is excellent advice. I may make another go at it.

Like you, I've tried before. After a day or two of trying to remember alt-
command-blah-blah-blah every time I wanted to do something simple, I gave up.
Then I started mousing around which totally defeated the purpose of trying to
pick it up.

I also found (at least 7-8 years ago) the windows Emacs to be terribly slow.
Hopefully that's not still true. That also effectively kills the learning
experience after a while.

~~~
icen
> alt-command-blah-blah-blah

C-h f

And then I type sort of what I want (with helm or ivy, it's a fuzzy match) and
select it from the list, which brings up it's documentation and what
keystrokes call it.

There is also `where-is` if you remember the name, or `M-x` (or `M-:`) if you
don't mind typing it out.

------
triska
Very nice list, thank you for the writeup and for sharing this!

One interesting thing about the Emacs modes listed here is that many one of
them are by themselves already enough to justify the use of Emacs for at least
someone in specific application domains.

For example, there are statisticians who do not use much of the breadth of
Emacs, except for the listed ESS mode, and who do a lot of their work in that
mode. The same for magit, Org mode, calc, dired, Tramp and others.

In addition to this richness in features and flexibility, a major attraction
of Emacs is that switching between all these aspects is instantaneous.

~~~
tonyarkles
And with org-mode you can start to weave them together using the source
blocks! I’ve been doing a fair bit of numerical code lately, and being able to
have a Maxima repl, org, and my C source all in the same place has been
amazing.

------
burtonator
I used Emacs for 15 years. I've been off of Emacs for about 5-6 years now and
I won't ever go back.

Here's why:

1\. Refactoring. The refactorings in IntelliJ are amazing. Amazing. The
ability to say (yeah, this class is now called Foo instead of Bar) and have
everything automatically changed is outstanding. This is a basic example of
course but you can also do things like remove a function parameter, and also
do things like lookup reverse symbols.

2\. Stable. IntelliJ is just amazingly stable. Part of this is that I had to
write elisp to get Emacs to do stuff that IntellJ just already provides for
me. Everytime Emacs would upgrade I would have to upgrade Emacs.

3\. Pair programming. I could NEVER work with other engineers on their code
and vice versa. We just didn't speak the same language.

Now mind you I also created a lot of the code you use in Emacs. I co-created
EDE for example.

~~~
kamaal
Java is more like assembly language programming at this point in software
history.

You shouldn't be editing Java with any editor, let alone emacs.

This is because if you are using 3 frameworks, and 30 classes with DI and
reflection, just to post a json to a http end point, you should be using an
IDE to handle that kind of madness.

~~~
ethelward
That's more of an architecture problem rather than an intrinsic characteristic
of Java though. I'm not a fan of the language, but I think the latest versions
added some nifty features that make working with the language not as bad as it
used to be.

------
JohnStrangeII
I'm using Emacs for my daily tasks, both writing and programming. One question
I have to more experienced Emacs users: Can you recommend an email client? It
needs to be able to display html mails. Currently, I use claws-mail and am
fairly happy with it, except for the search. I've got about 30,000 mails in
the inbox and full-text searching them takes too long.

Is there a way to transition my claws-mail folders to Emacs, or ideally use
both programs at the same time for a while?

The article recommends notmuch-emacs. But I'm afraid of 2 things, (i) loosing
existing mails in the transition (due to e.g. faulty conversion tools), and
(ii) that after a complicated transition I'm not happy with the new setup. Any
recommendations? Is it possible to use the claws-mail email inboxes directly
in Emacs?

Another thing is org-mode. I never really managed to get deep enough into it
to really see the benefits. I've even bought the printed org-mode manual, but
the setup seems so complicated. Can someone recommend a good "light" tutorial
for it? What are you using it for?

~~~
jwr
> One question I have to more experienced Emacs users: Can you recommend an
> email client?

Contrary opinion from an experienced Emacs user (parts of my init.el are older
than many users in this forum): I used to be a fan of Gnus, but then noticed
that dragging attachments into E-mails is such a productivity booster than I
switched to Mail and haven't looked back. If you are on a Mac, the combination
of seamless drag&drop everywhere, Mail.app and LaunchBar simply does not
compare to what you get inside of Emacs.

I do feel some regret, because I liked the customizability, but facts speak
for themselves: I do things much faster with Mail.app.

~~~
patrick5415
Interesting. One of the reasons I switched to mutt (well, neomutt) is that it
is faster for me to work with attachements from a cli. This is mostly due to
tab completion, which for commonly accessed locations is practically muscle
memory. Takes me forever to to click my way there.

~~~
jwr
I often don't even know what the filenames are for my attachments, or where
they are in the filesystem. Some are ephemeral.

I'm guessing you haven't worked with MacOS? Most people coming from a
Linux/UNIX backgroupd (I was one of them) tend to assume that MacOS doesn't
offer much, especially for advanced users, which isn't true. You can do many
things _significantly_ faster on MacOS.

In my case, I drag/drop attachments from other applications, from the
filesystem, or from LaunchBar (finding things in LaunchBar is _way_ faster
than manually navigating through an entire path using tab completion).

------
rbanffy
The way I see it, there are two major approaches to IDEs - Extendable text
editors (of which Emacs is the best example) and Visual Studio knock offs.

There is no right or wrong answer, but I like the Emacs way.

~~~
yaantc
I'd put it slightly differently, but I guess it is the same idea.

There are two major approaches to software development: 1) powerful text
editors (vi, Emacs) or 2) IDE.

Powerful text editors are universal, but up to now their language support was
often subpar compared to IDEs. They tend to do well for niche languages with
no dedicated IDE, as then they're the reference editors. But for mainstream
languages on can usually find IDEs with better language specific support.
Still, they shine in pure editing power and after an initial investment you
can use them for anything text based.

Then an IDE can have the best language support for some usually small set of
languages, but is not as powerful as a vi or Emacs for pure editing.

That's the situation so far, but I see this changing thanks to the language
server protocol [1]. It's the pattern seen in portable compilers, where a
universal IR avoid a MxN explosion with M languages front-ends and N target
ISA. Except here one avoids the M editors times N languages by having a
universal protocol between an editor and a LSP server for a language. What the
LSP allows is decoupling your editing front-end from the language support
back-end (the LSP server).

All this is a bit young, and moving fast, but in time it offers the
possibility of a no-compromise experience: use the best editor for you, and
still get the best language support available. It's already possible to
extract Eclipse Java support, or Microsoft Python support, and use it with any
LSP compliant editor for example, with some ad-hoc work. In time, all this
should get more streamlined. Which makes me happy to have invested into Emacs
;)

[1] [https://microsoft.github.io/language-server-
protocol/](https://microsoft.github.io/language-server-protocol/)

~~~
josteink
> That's the situation so far, but I see this changing thanks to the language
> server protocol

It’s really interesting how LSP shifts what I’ll call “Visual Studio only
features” into all editors, while at the same time you had Microsoft being the
ones who initially pushed for LSP-adoption.

I wonder how many internal discussions they had on this subject before saying
“Go”.

It’s a fantastic initiative and I’m glad it’s there for me, in my Emacs today.

~~~
rbanffy
Visual Studio-like IDEs are a dead end. There is little revenue opportunity in
them and a huge downside in losing relevance in the overall developer
mindshare.

How many of us would be using a Microsoft IDE/text editor if it were not for
VS Code?

~~~
coldtea
The millions that use and will continue to use Visual Studio?

~~~
rbanffy
Visual Studio is great for developing on Windows software that'll run on
Windows or XBox.

Feels like a dead end to me. The ecosystem has colossal inertia, but it's easy
to see the lack of future.

~~~
dmitriid
So, you propose to give up on Visual Studio because in 20 or so years maybe
Windows and XBox won’t exist? Or?...

Also, speaking of IDEs. There are also Jetbrains’ IDEs and XCode. Can’t speak
for XCode, but IDEA offers capabilities that Emacs can’t even begin to
approach.

~~~
rbanffy
I have already given up Visual Studio because none of my work is intended to
run only on Windows and Xbox.

------
tasubotadas
I remember giving Emacs a serious go 5 years ago. I really wanted to like it
but the archaic mode switches[1] were just too much when you are used to the
convenience of Ctrl+C and Ctrl+V (I'll call these "modern shortcuts").

I've tried using ErgoEmacs[2] but what I've learned was that it doesn't really
play nicely with all the other extensions.

It's a shame because I've wanted to find something a bit more powerful than
nano for config and code updates on remote machines.

[1]
[http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html](http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html)

[2] [https://ergoemacs.github.io/](https://ergoemacs.github.io/)

~~~
didibus
You can use CUA mode:
[https://www.emacswiki.org/emacs/CuaMode](https://www.emacswiki.org/emacs/CuaMode)

I also highly recommend Spacemacs. If VI isn't your thing, it is still great
to use it, just set it up in Holy mode using Ivy.

What it adds (on top of a great default config), is bindings which start with
M-m (that's Alt+m). For almost everything. Like saving your file is M-m f s
(that's Alt+m release, f release, s release).

~~~
fao_
Sure, but with a leader key in vim set to 'f', I can save with f-s (that is,
press the f key and then the s key), which after a month is next to automatic

~~~
dan-robertson
You’re arguing about vim shortcuts in reply to a description of what one can
do if one doesn’t want vim shortcuts. Note that the equivalent in vim is not
really f s, but ESC f s, because in most modes where one might do M-m f s,
most characters insert themselves, the equivalent of insert mode in vim.

Note also that in regular emacs one can do C-x C-s (ie holding control press x
then s).

------
betenoire
As a former Vim addict of over 12 years: to those who would like to try to
move to Emacs, and Spacemacs doesn't cut it, try Doom!

[https://github.com/hlissner/doom-emacs](https://github.com/hlissner/doom-
emacs)

It is a much thinner configuration, and you will learn Emacs instead of layers
and Spacemacs conventions.

It only took me about a week of deliberate use to adapt my work flow and get
used to it, and it has been my primary editor for nearly a year now.

~~~
AdmiralAsshat
At first glance, I thought this would be an Emacs tutorial superimposed on top
of the Doom engine, ala DOOM as a Tool for System Administration.[0]

[0][https://www.cs.unm.edu/~dlchao/flake/doom/](https://www.cs.unm.edu/~dlchao/flake/doom/)

------
egypturnash
“I don’t care what editor you use for source code – you can use Quick basic
for all I care – but look, you have to know that Magit exists. Even if you
don’t use Emacs in any other capacity, you may want to use it for Magit.”

There are exactly two instances of “Magit” in this web page and I just quoted
both of them.

~~~
egypturnash
A quick web search brings me to Magit’s page, which tells me that Magit is “A
Git Porcelain inside Emacs” which just creates further questions. How does one
make delicate pottery out of a version control system? In what circles is “a
porcelain” a synonym for “user interface”?

~~~
gknoy
The Git documentation refers to everything Nicely Shaped that is tacked on to
the core git functionality as "porcelain" [0]. (Pretty much everything that we
normally use when interacting with git counts as porcelain.)

0: [https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-
Po...](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)

------
lame88
So, emacs is a platform for text-based programs to do things that i already
have other stable, reliable, and familiar programs to accomplish. I’m not
sold. I need a better value proposition before i feel sold to spend my time
climbing that learning curve.

~~~
ernst_klim
>text-based programs

Not text based, it has buttons, widgets, can embed pictures and graphics.

>reliable, and familiar programs to accomplish

In emacs these bits of code are integrated, so I could, for example, save an
IRC chat as buffer, edit it, and send a e-mail. Or open an interactive REPL of
maxima, for example, copy result to latex having embedded previews for
formulas, and then compile it to pdf (and preview in emacs).

Different parts could be combined in any possible way with elisp code. You can
easily call any email-related or rfeed-related function from your code at any
time.

~~~
dmitriid
The question is: is it worth it? Trying to figure out all those functions,
setting all tose modes, and then programming them the way you described.

Especially when all you just described can be done with regular copy-paste
between dedicated programs if needed.

------
fourier_mode
I've been a vim guy for 5 years now. And last month I tried to switch to
emacs. But it just didn't feel natural for the following reasons:

1\. My usual coding session would involve Vim+Tmux, on trying the same with
emacs. I was seeing some lag(although small, but noticeable).

2\. I am very used to the key strokes "g-d, g-D" in vim to quickly move around
calls/declarations of functions. For that emacs makes use of Ctags, which is
more versatile but not great for a quick lookup.

3\. I have had better luck with Vim's linting plugins like ALE and haven't
found similar plugins for Emacs which was eventually a major game changer to
switch back to Vim.

On the other set of tools:

\- Org-mode and latex-preview-pane-mode are the 2 set of tools which I have
integrated into my workflow and they are very suitable to me.

\- ERC is also pretty neat.

\- I have tried Magit and although seems useful, for my use case of Emacs
currently doesn't hold a lot of promise.

\- Switch to Gnus, mu4e as mail clients replacements is too painful, at least
to a Thunderbird user.

~~~
dan-robertson
Regarding your first point, do you mean that you try running emacs inside a
tmux inside a terminal?

If that is the case, I would recommend not doing that. The emacs gui will give
you more colours, images, thinner window borders, better keyboard shortcuts
(eg a difference between C-m and RET), mouse controls (if you ever want them),
as well as potentially less lag.

The analog to the vim-in-tmux workflow is to instead keep emacs always open in
the gui, run somewhere between none and all shell commands from emacs
(depending on how you feel), and have a terminal in another window (as you
might for web browsing or email) for more prolonged terminal things. One might
skip this somewhat by running shell (or even term-mode) in emacs.

Similarly, for editing remote files one uses tramp to ssh from inside emacs
and edit files whereas with vim one sshes into the remote box and runs vim.

------
roland35
I am currently only using Emacs for org mode, and overall it works great for
taking notes, keeping track of tasks, and outputting documentation.

However... I would _love_ to see a GUI version of just org mode which would
combine a few features of OneNote, well I would be happy if it only made
adding pictures better!

------
jstewartmobile
If only Emacs had become the VM of the web rather than Chrome! I'm more than
ready to trade our impending soyberpunk police-state dystopia for a case of
carpal tunnel syndrome.

------
mark_l_watson
I bookmarked this. I have been using Emacs since I bought a manual around
1980, but, the article mentioned a few packages I didn’t know about.

~~~
m463
This happens all the time to me.

The other day, I found my old hitchhiker's guide to the galaxy infocom image
(interactive fiction) and it turns out someone wrote some elisp that lets you
play it in emacs.

(that said, elisp isn't a very expressive language for me, python is my
favorite language right now)

------
ReneFroger
A good resource for anyone who wants study Emacs further or try out things, I
found this very helpful for me:
[https://emacs.zeef.com](https://emacs.zeef.com)

------
sprash
I used emacs for years and had accumulated about 10000 loc init.el over that
time.

With my new employer I'm forced to use notepad++ on Windows. The difference in
actual productivity: zero!

Emacs is a nice hobby but when you want do get shit done it won't help you
being more productive except for some rare corner cases.

So don't buy into the Emacs Plattform. Maybe just learn the basics because
sometimes it is the only editor installed. If you spend more than two hours on
it you are wasting your time.

~~~
alexhutcheson
Once or twice a quarter I'll end up with a relatively mechanical task that I
can do with a keyboard macro, query-replace-regexp/dired-do-find-regexp-and-
replace. That normally saves me at least 30-45 minutes compared to either
doing it manually or writing a script.

~~~
AlotOfReading
The parent mentions notepad++, which offers similar regexp and macro
functionality.

------
spellcard199
\---- TLDR ----

I completely agree with the others who say:

    
    
      - learn elisp instead of learning "emacs"
      - if you want to memorize something, just learn the name of the command: if you use it very often then learn/define a keybinding for it
    

\---- part 1: I'm happy I've learned elisp in the last year

People complain about memorizing emacs keybindings, but most of the time I
just call the command name with M-x command-name. Only if I find myself using
it often I bother memorizing or setting a keybinding for it.

As for why I use emacs, I started using it for org-mode, which I considered
it's only killer feature at the time. Since 1 year ago I started learning
elisp and I think only now I can see what's the whole point of emacs.

In just 1 year of (beginner-level) elisp I wrote 75 files containing elisp
functions to help myself with dozens of tasks that comprise:

    
    
      - move/mirror parts of ascii diagrams
      - automate some tasks just clicking on custom org-mode links
      - wrap ammonite-term-repl to get Ammonite completion for scala scripts [1] [2]
      - add rudimentary support for kawa scheme to geiser (my first pull request ever (still waiting for response))
      - control video player from within emacs while I'm writing subtitles
    

\---- part 2: you can have different emacs configurations

Another common complain is that emacs tends to become slower as you add more
and more packages. As a spacemacs user, I noticed that too. For this reason
when I don't need spacemacs goodies I use multiple, different emacs
configurations (with evil-mode though).

This is how I do it:

1 - Make a new ".emacs.d" user directory somewhere

2 - Make a new "init.el" user file inside it

3 - Add to the beginning of init.el :

    
    
        (setq user-init-file (or load-file-name "path-to-init.el"))
        (setq user-emacs-directory (file-name-directory user-init-file))
    

4 - Call emacs with:

    
    
        emacs -Q --load "path-to-init.el"
    

That's it.

You could achieve the same result using cask, which would be more elegant imo,
but takes a couple of seconds more to start.

\---- part 3: use elisp to call other languages

As for elisp, once you have learned enough of it (not much), if you are
determined not to use it, there are different ways to call other languages
from it:

    
    
      - clojure through cider plus clomacs
      - common lisp through slime
      - shen through shen-elisp [3]
      - different compiled languages through dynamic modules:
        - C  (example at [4])
        - go (example at [5])
      - ... many others I haven't investigated...
    

Just out of curiosity, I explored the shen-elisp path. I tried a whole week to
see if I could replace it with shen-elisp. At the end of the week I learnt how
to call elisp from shen-elisp and shen-elisp from elisp... and the fact that
every time you restart shen-elisp you have to re-declare types. However I
abandoned the idea for 2 reasons:

    
    
      - Plain elisp is faster: I don't know the implications
      - I wanted to focus on elisp so I can contribute better to other elisp projects
    

\---- references

    
    
      [1] https://github.com/zwild/ammonite-term-repl
      [2] https://github.com/spellcard199/ammonite-term-repl-completion
      [3] https://github.com/deech/shen-elisp
      [4] http://kitchingroup.cheme.cmu.edu/blog/2017/07/08/Adding-numerical-methods-to-emacs-with-dynamic-modules/
      [5] https://mrosset.github.io/emacs-module/

------
milin
Vim is life.

------
raphinou
I recently tried to switch from vim to Emacs with spacemacs. I enjoyed it
until I discovered Emacs has no support for tabs (ui tabs, not the character
;). I went back to vim mainly due to that, but still miss magit....

~~~
rout39574
You can have many things going at the same time, and select between them using
the buffer menu. I find the devotion of yet another chunk of screen real
estate to the tab list rather a waste, but _shrug_ aesthetics.

C-x C-b

shows you the list of tabs ("buffers") and lets you select from them easily.
As a bonus, the title portion isn't compressed to incomprehensibility when
they get numerous.

~~~
klibertp
I use tabs to switch between window configurations.

Say I code in Python, with docs and shell windows on the right. Then I want to
quickly take a look at git history. But, if I start magit, it will hijack the
window configuration and my carefully placed/resized windows will get messy.
So, I open a new tab and start magit there. Now, I can switch between the two
tabs - ie. window/buffer layouts - with a single key.

The fact that I mention saving the layout of windows should hint that I know
you _can_ do this in vanilla Emacs by saving and restoring window
configurations, but it's much less hassle with tabs. Also, you can hide tab
bar (as well as menu bar and button bar) when you don't need it, and it's
actually quite handy when you do need it.

To each their own of course, just saying there are good uses for tabs in
Emacs, unless you want to delegate this to your WM and launch one frame per
window config.

~~~
dmortin
> To each their own of course, just saying there are good uses for tabs in
> Emacs, unless you want to delegate this to your WM

You mention window configurations, and you say " it's much less hassle with
tabs." You can assign a single key to switch between window configurations too
and then it's practically the same, isn't it?

~~~
klibertp
Yeah, not "practically", but simply "the same" \- that's exactly how half of
my tabs (elscreen.el) is implemented (the other half being creating,
displaying and updating the "tabbar"). In other words, if you use winner mode,
or have a couple of custom wrappers around window layouts and use those,
you're practically already using tabs, just without a tabbar! ;)

------
module0000
Logging into "work" systems and typing "emacs" == "command not found". Typing
"vi" opens a useful editor.

It's not that I hate emacs or have some aversion to anything _except_ vi/vim.
The problem is that vi is _everywhere_ , and by mastering the always-available
editor, I always have my tools at hand. On foreign systems, or highly
regulated systems that I can't add software to, this is a huge advantage.

~~~
yaantc
True, but the workflow you describe is not the natural one for Emacs.

Emacs has a built-in package called TRAMP [1] for remote work. You don't log
into a distant server and open Emacs there, you use Emacs on your local PC and
open the remote file naturally, using a syntax like
/method:user@host:/path/to/file, but most often /-:host:/path/to/file (when
using SSH access set as default, with your local user name). Except for the
special file path it's just like for a local file.

Then when launching a shell command, or a full shell, or a grep or compile or
whatnot from a buffer editing a remote file, Emacs will automatically launch
the command remote machine too. That makes the experience rather transparent.
It's possible to have multiple buffers editing files on different machines at
the same time.

[1] [https://www.gnu.org/software/tramp/#Quick-Start-
Guide](https://www.gnu.org/software/tramp/#Quick-Start-Guide)

