[cies]

Emacs+Evil is the next Vim.

And yes, CtrlP is probably the thing you'll miss most.

But all the other things I got from switching from Vim to Emacs+Evil easily outweigh the missing CtrlP.

Vim was great, until I wanted to customize it heavily. It is simply not made to facilitate things like: child processes, SSH, understanding my code, a visual interface for Git.

[klibertp]

Fuzzy file finder was a thing I missed the most. Fuzzy-other-things-finders like ido and helm are there and work very well, but fuzzy file finding is either slow or incomplete with most solutions. So I found one plugin I liked - https://github.com/justinweiss/fuzzy-find-in-project - rewrote most of it and now I use it exclusively: https://github.com/piotrklibert/ffip

It's documented in the code - more or less - and I'm very happy with it, especially with having multiple directory sets I can change between (which I implemented recently) and how fast it is (aside from initial caching done by the ruby backend).

I actually never thought about releasing it publicly, so the readme is non-existent and the Ruby script is hacked with hardcoded ignores, fonts are not customizable, and it's even possible that I hacked the Ruby gem source at one point. I could clean it up a bit if there was some interest in it.

[alwillis]

>Emacs+Evil is the next Vim.

Actually, Vim is the next Vim--it only seems to get better and better.

After switching to Vim full-time about two years ago, I recently tackled exporting the text from a 10-year old PDF to markup it up using AsciiDoc[1] so I can output HTML and ePub.

It’s over 37,000 words but I was amazed how easily I was able to jump anywhere on the screen with just a few keystrokes fix all of the little things that need to be fixed in a text file.

And because editing paragraphs of text is somewhat different than what I normally do (writing HTML and CSS), it was pretty cool being able to leverage the composability[2] of Vim and how seamlessly that knowledge works in new contexts.

[1]: http://www.methods.co.nz/asciidoc/index.html [2]: https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...

[akerl_]

Do one thing well. My text editor shouldn't be managing child processes or SSHing or trying to be a visual Git interface, and Vim does a great job displaying my code so I can understand it.

[sjolsen]

Programs that "do one thing well" are utterly useless unless you can compose them. Emacs is a tool that composes programs that do one thing well, like Bash or X.

Emacs, as has been said time and again, is not a text editor. It is, if anything, a development shell. It contains a text editing program (the default program), and that program does not manage child processes or SSH or Git.

You could also take the stance that Emacs _is_ a program that "does one thing well:" develop programs. That's the actual task of importance. Text editing is a secondary, ancillary task that owes its importance entirely to the archaic practice of representing complex interrelationships between data and operations on those data as a static linear stream of ASCII-encoded bytes.

Unfortunately, almost all programming languages are like this (hence, "languages"), but if you ever use Emacs to edit Lisp, you'll find that it's far less like text editing than it is like directly manipulating the abstract structure of the program. It does a reasonable job trying to replicate this experience in other languages, but when you have utterly inane constructions like seventeen-precedence-level infix notation, there's only so much you can do.

[cies]

> Emacs is a tool that composes programs that do one thing well, like Bash or X.

or like Vim! (as in Evil)

[clarry]

Do one thing well does not really apply to larger user-interface applications that inherently have to aggregate lots of unrelated functionality. It applies to one-shot commands that you'd use in shell pipelines; that's why the other commandment is to use text streams. The point is that by combining these small utilities which do one thing well, you can create the aggregated functionality you need to perform a higher level task. Whereas if you didn't have these little utilities which do one thing well, you'd be scratching your head trying to figure out how to do something that a big monolithic application can do for you but which you need in a different context, i.e. where running that big monolithic application to do that one thing is very very incovenient if not impossible. Why do people quote this out of context?

If you stop and think about it, it's really pretty much impossible to define the "one thing" a code editor does.

Forcing the user build everything out of shell pipelines is not the goal, and achieves nothing. At some point, it is appropriate to build the aggregate and combine these functionalities for the user so that he doesn't have to do it himself. And in many cases, you end up reimplementing the thing because it is more efficient that way. The shell utility is still there for the user should he need it.

[qbrass]

Displaying code and editing it are two separate things. Sounds like Vim is pretty bloated acting as both an editor and a pager.

Use ed to edit, and pick a side in the more/less wars if you want to read it.

[gknoy]

I realize that you're joking, but... vim is a better less than less is, in almost all cases, for viewing code, because you get syntax highlighting.

I'm not a vim user, but I use it to replace less because syntax highlighting is the bee's knees: (you may need to change `vim74` to whatever it is on your system.)

  alias less='/usr/share/vim/vim74/macros/less.sh'

You can then do things like:

  less Makefile +400

which pairs very nicely with `grep -n`.

[tomjakubowski]

Why not just pipe pygmentize to less? That's truly embracing The Unix Way™.

  pygmentize foo.py | less -r

[MichaelDickens]

But ed also displays code. I think you're looking for some way of editing code without displaying it on the screen at all.

[aaronem]

Emacs does a great job at that, too. (In fact, it contains a complete Javascript parser, which is invaluable to me since that's the language around which my professional life revolves.)

It also does a great job managing child processes and SSHing. (Or FTPing, or speaking whatever other protocol you need to use to access remote files.) I can't speak to it as a visual Git interface, but I don't doubt it's at least reasonably good at that, too.

"Do one thing well" is a good start, sure. But why not aspire to more?

[akerl_]

It's great to aspire to more, and that's why my system has more than one binary in $PATH. If a project wants to release an awesome $thing_doer in addition to their main tool's function, it should be a separate tool. That way I can use esshhelper and egitbrowser and eftp separately from emacs (yes, I know the names are contrived).

[jff]

Do you consider the shell an overly-featured program because you use it to copy/delete/create/link files, install packages, etc? No, because it's a tool which loads up other tools for your use, providing some conveniences like job control in the process.

Emacs provides a lisp implementation. People have used this lisp implementation to write ftp clients, web browsers, and yes even text editing functionality; you then use emacs to load some of that lisp code and execute it. I don't say the Bourne shell fails at "doing one thing well" since people write shell scripts and run them from within the shell.

[__david__]

That's how Emacs works though! There's a bunch of TeX junk in Emacs but since I never use TeX, Emacs never loads that lisp. It's just sitting around in a directory waiting in case I do need it at some point.

And Emacs has a command line for its stuff: "M-x".

And if you really want to have separate executables you can do that with small 'emacs --eval' wrappers.

[aaronem]

Different perspectives; Emacs has a built-in shell, which is closely integrated with most of the editor's functionality -- for example, Tramp, which transparently supports almost every remote access protocol in existence; if I want to copy a directory tree from host A to host B, in bash I might

    mkdir ~/tmp/foo
    scp -r user@host-a:/foo/bar/* ~/tmp/foo
    scp -r ~/tmp/foo/* user@host-b:/foo/bar
    rm -rf ~/tmp/foo

or

    ssh user@host-a 'cd /foo/bar; tar -cf - .' | ssh user@host-b 'cd /foo/bar; tar -xvf -'

while in the Emacs shell I just

    cp -r /user@host-a:/foo/bar/* /user@host-b/foo/bar

and if I want to inspect the result, in bash I

    ssh user@host-b
    ls -R /foo/bar

while in eshell I simply

    ls -R /user@host-b/foo/bar

and all the key management happens automatically, via ~/.ssh/config and ssh-agent, just as it does when I invoke OpenSSH binaries by hand.

Oh, and lest I forget, if I want to edit a remote file in Vim, I have to either ssh to that host and invoke vim there, or scp the file here and invoke local vim on it, or deal with sshfs or something -- the latter of which might seem like a perfect solution, until you consider that I use all of Linux, OS X, and Windows machines extensively in my daily life, and not all of them do sshfs well or at all. By comparison, eshell's

    find-file /user@host/foo/bar/file

is exceedingly simple, and works equally well on whatever machine I happen to be using at the moment. I don't have to worry about marshaling temp files or configurations or, indeed, anything at all; Emacs does all of that for me, quietly, in the background, so that I can spend all my time and mental effort on the changes I actually want to make, instead of doing a bunch of annoying sysadmin work just so that I can make them at all.

There's value in having lots of loosely coupled tools, but it's not the only paradigm worth considering. There's also value in a single, unified interface to an enormous range of tightly integrated functionality; indeed, I've found the result to be something of a combinatorial explosion of productivity.

[klibertp]

> Do one thing well.

For example, be an outstanding VM, IDE and a thriving ecosystem of libraries for development in a quite nice (and becoming better with each version) Lisp dialect.

Anyway, that's really a matter of preference. It's ok if you want to tell the world about yours, but try to word it in a way which isn't confrontational for people who have different preferences.

[Dewie]

> Do one thing well.

Do you really demand that an OS should only 'do one thing well'? :ø)

[rthomas6]

Well, yes. That's what makes Unix OSes so great. Programs all the way down to the command line are separate from the OS. Modules and drivers are also semantically separate from the core.

[Dewie]

So how would you envision that the Emacs OS should be structured/used?

[rthomas6]

Something like this:

  sudo aptitude purge emacs
  sudo apt-get install vim gvim
  gvim

Edit: Clearly I'm joking. If you wanted a serious answer, Emacs is just a large, easily extensible program. It's not really an OS. That's like saying Google Chrome (contains a package manager, web browser, text editor, scripting language, and much more) is an OS.

[SoftwareMaven]

You have heard of Chromebooks, right? It wouldn't be a far stretch to imagine a developer laptop where Emacs was the entire interface.

[phaer]

I haven't used CtrlP too much, but what are you missing in ido-mode or helm?

[MetaCosm]

Fast proper fuzzy-find completion on files, buffers and tags that works across multiple platforms and even on files not in source control. In Vim I have it bound to <leader>f, <leader>b, <leader>t -- on my multiple trips over to Emacs land -- I have tried lots of ways to get the equivalent working and always come up short.

[tuhdo]

Is able to use GNU Global/Cscope/Ctags to jump around Linux kernel source code, in Linux/Mac OS/Windows good enough? Like this: http://tuhdo.github.io/emacs-tutor.html#sec-8

[aaronem]

Lusty Explorer may well satisfy your first two requirements. I don't believe it searches tag files at present, but the capability shouldn't be too hard to add; for files and buffers, I've used it for some years, and find it quite nice.

[MetaCosm]

Actually, I think I have used a clone of Lusty on the Vim side and it worked nicely. Getting tags support working would be nice as well -- I really like the global tags option in CtrlP (I got this function name somewhere in an open file, take me there).

[aaronem]

Lusty actually originated on the Vim side, and was ported to Emacs by someone who liked the functionality.

Emacs comes stock with good tags support; once you've built a tagfile, M-. on a tag will take you to its definition. (I don't use tags myself, although I really should, so I don't know whether Emacs can automate construction and update of a tagfile, but I strongly suspect it can; check the relevant documentation for details.)

[phaer]

You could mention in which ways you tried it, because helm (https://github.com/emacs-helm/helm ) does all the things you mention as far as i know.

[craigching]

I only discovered ido about two years ago and, man, I can't imagine emacs without it now ... and I've been an emacs user for over 20 years! Only dabbled with helm a bit, there was one helm-enabled package that I really wanted to try.

[tokai]

I thought that neovim was the next vim.

[omaranto]

It might be the next one after Evil. Evil is already here, neovim is coming.

[falcolas]

I tried Evil for about a month, and couldn't stand it. Some parts didn't work the same (ctags word boundaries), and the need to move back and forth between Evil mode and normal emacs mode when using other emacs plugins (it never worked quite right in plugins like magit) negated much of the benefit of having Evil mode in the first place.

I'll probably be sticking with boring old Vim and the command line.

[JelteF]

I'm not sure why you need child processes or SSH (I mean you can use vim over SSH). But have you tried syntastic for the syntax checking? And I'm not sure what kind of visual interface you want for git, bit the combination of fugitive and gitgutter (super simple but awesome) works quite well for me.

[lfuller]

I don't understand why people want to do this in Vim. To me, a text editor should be extremely good at text editing / analysis and nothing else.

I use tmux, so all the advanced functionality of the terminal is only a single keypress away (to switch to another open terminal split).

[ue_]

Emacs isn't really just a text editor though, it's a Lisp environment whose primary use is as a text editor. It's possible to do many other things in it, so much so that it's joked about as being an operating system in its own right. Emacs is extremely good at text editing, but it's not just a text editor.

[hollerith]

When I visit a file in Emacs, indications appear on the screen (in the "mode line") as to which version-control system, if any, the file is under the control of and whether the file contains any non-checked-in changes.

Perhaps grandparent wants something like that in Vim if it does not exist already.

[JelteF]

I hope you do use vim splits, since you have the same (copy/paste) buffers then.

[lfuller]

I do! I have both tmux and vim configured so that <C-{h,j,k,l}> will navigate through both kinds of splits.

[swah]

Isn't Helm, sucessor of Anything, much more than CtrlP could ever be?

[bwilliams]

I tried using helm when I wanted to learn emacs and my problem is that helm is incredibly ugly, and customizing it would take a good amount of time.

[tuhdo]

Really? You should checkout my guide: http://tuhdo.github.io/helm-intro.html and see if Helm is ugly or not. Nothing like Helm (except itself) ever exists. Check "Why Helm is powerful" section: http://tuhdo.github.io/helm-intro.html#sec-28

[pyre]

> understanding my code

Both Vim and Emacs have a horrible time trying to syntax highlight Perl, but I find Vim's flaws to be more tolerable. Emacs isn't some sort of panacea.

[thebelal]

I have written a good amount of perl in both Vim and Emacs and can't recall noticing bad syntax highlighting in either. Do you have an example?

[pyre]

One of the examples I seem to remember was string interpolation of things like:

  " @{[ blah() ]} "

I was never an Emacs user, but paired with Emacs users quite often during a 4 year stint at a Perl shop.

In Vim:

  my $variable = <<EOF;
  STUFF GOES HERE
  EOF

Vim highlights everything from "<<EOF" to "EOF" as a string, but technically the string highlighting shouldn't start until the beginning of the next line. In the example above it's not the end of the world, but you can have examples like this:

  my $variable = function_call(<<EOF, $blah);
  EOF

where ", $blah);" is highlighted as part of the string, when it isn't.

[edit: I tried to replicated this, and I'm not seeing the HEREDOC portion highlighted as a string, but I also notice that Perl 5.20 has removed <<HEREDOC in favour of <<"HEREDOC" or <<'HEREDOC', so maybe that made parsing for syntax-highlighting easier.]

Also in Vim:

  "text @{[ callFunction(sub { }) ]} text"

The first '}' encountered terminates the '@{' instead of parsing matching pairs.

[__david__]

I find Emacs's default Perl mode isn't so good. Luckily Emacs also comes bundled with cperl, which works much better in my experience. So much so that I have this in my .emacs:

    (defalias 'perl-mode 'cperl-mode) ; perl-mode sucks; use cperl-mode

[farresito]

Take a look at Projectile. It works pretty much like CtrlP.

[platz]

There are many keybindings that conflict between emacs and evil/vim

[Symmetry]

I miss CtrlP, but I miss the jump list even more.