Hacker News Reader

Comment by dragonsh | Hacker News Reader

Great job a very good example of programmable editor.

Emacs had been my work horse since 2002 and never disappointed. In the meantime tried many ide only vim and emacs stayed with me. Sometimes do use nano and sublime text but then back to either emacs or vi.

All those shiny IDE based on electron, Java or C++ are just too slow to be productive be it VScode, atom or eclipse or visual studio or kdevelop. I am forced to use them due to tooling support for some framework. But I avoid them as much as possible once I have configured emacs to work with the language or sdk or framework or library in question.

View on HN

http://spacemacs.org/ with its org-mode and magit (https://magit.vc/) integration, combined with the modal editing of vi, is truly superior.

Don't care about your platform, desktop (I'm typically working over SSH in the cloud, so why bother?) or any of that hooplah.

Just waiting for everybody else to catch up.

Personally for me spacemacs is bit slower in startup for my liking, so I use my own custom configuration. It's just lisp at the end of the day. Also for people who prefer emacs keys instead of vi, they can start with emacs-prelude package. But it will be hard to beat custom configuration in long run.

> Personally for me spacemacs is bit slower in startup for my liking

I have see this many times and never understood how startup time could be an issue. I startup Spacemacs at the beginning of the day, and close it when I leave. 10 second of startup time is nothing.

10 seconds of startup time 10 years ago was nothing.

The day had 86400s then as now.

I wonder if part of it is some people hacking emacs and going through a update-save-restart cycle instead of just evaluating their change in place.

Then again it may be the case that part of the cycle is seeing if the package management system of your custom distro (be it spacemacs, doom, or whatever) picks up and configures the new packages correctly.

I've noticed a divide between the workflows of emacs and vim users and I think it ties directly back to startup times. I'm an emacs user and, like you, I start it up once and keep it running indefinitely. Vim users tend to enter and exit the editor repeatedly during the day, typically alternating with their shell of choice.

I would say this is largely true in practice, although when I found out that vim could have multiple buffers, windows, tabs, and that you could save session files, I suddenly was keeping vim open for many hours and opening new files in my existing instance. I would say a lot of people learn vim in a hurry and don't go far beyond the basics.

I never close Emacs unless I am shutting down the machine and that happens, perhaps once every month or two.

It's kind of a sign of inefficiency as, at least as far as you can tell, a similar task was done in 1/10th of the time on a 1/1000th as powerful system. This may not be true, but just as you can't get to know every person you interract with you need to use plausible correlations to make judgements and predictions.

You can also have emacs run as a daemon(1). That way you never have to wait.

1 https://wiki.archlinux.org/index.php/Emacs#As_a_daemon

This is the /real/ killer feature for me that I would find very difficult to live without and I don't know of any other editors that offer this functionality.

Being able to remotely open my editor (either from a terminal, or with X11 forwarding) with all the files I have open, exactly where I left off is incredibly useful.

I never really learned screen because daemonised emacs sufficed for me. My daemon uptimes are normally the same as my system uptimes, with the one on my VPS currently at 77 days.

A few years ago, I started using one daemon per project with server-use-tcp, each with a slightly different theme so I can easily tell them apart.

(posted from emacs-w3m)

using emacsclient in screen or tmux is kinda handy if you're using a flaky connection and keep disconnecting (like on a train)

Any benefit over using screen/tmux?

Main benefit is you don't need to remember to start your editor frame in screen/tmux and you can use both terminal and gui/x11. So when I'm at work I start emacs in X11 windows, when remote I simply ssh in and do emacsclient and connect to all the buffers I have open (if I have low latency i'll do x11 forwarding and start x11 emacsclient ) It's basically the same as tmux/screen but gives you a lot more flexibility.

Other big benefit is starting emacsclient is basically instant, so opening a file from a webbrowser or whatever is super fast (some folks have 30 second or longer emacs startup times).

Only real downside is it really sucks bringing back your state when emacs crashes and you have hundreds of buffers open for multiple projects across 20-30 emacs clients.

There's the promise of faster Emacs (https://www.emacswiki.org/emacs/GuileEmacs written in Guile Scheme.) But it has 2 main problems: A) it's apparently stalled and B) not even it's supposedly known-good commit is compilable... :-(

Also check out https://github.com/hlissner/doom-emacs. It has a faster start up time, and is updated regularly (everyone uses the develop branch).

Oh yes I saw it forgot to mention though.

I have been using Spacemacs exclusively for around three or four years and I don't know if I can actively recommend it.

The problem is that the 'stable/master' branch of Spacemacs is incredibly outdated. I found myself needing fixes or improvements that existed in 'develop' so often that I migrated over to that branch. The idea of regularly cutting stable releases just isn't done within that project so if I'm recommending Spacemacs to new users I have to give them installation instructions that aren't provided by the documentation. Also, to get more up to date documentation I need to go to the layers docs in the GitHub repo and that can be hard to track down.

Every fresh install I've setup there has just been... so many problems with melpa and pulling down packages. Most of the time I have to repeatedly delete the package cache and restart Emacs until Spacemacs successfully pulls down packages - usually using the insecure flag so that packages aren't downloaded over HTTPS.

It's just... not as a polished as installing VSCode and a bunch of extensions. Spacemacs can require a lot of work and patience and I've just had too many things break with it over time.

What do you suggest instead?

Is there a nice how-to for setting up emacs with evil mode and a reasonable set of defaults that don’t require endless tweaking?

Doom emacs is great and way faster.

https://github.com/hlissner/doom-emacs

set capslock to ctrl and don't use any modal stuff. Also I use avy, bound to C-j, for navigation within the buffer.

I don't really have a suggestion, to be honest. I've only used Emacs within the context of Spacemacs and don't know of a better alternative. Maybe sometime later in my life I'll look at what Emacs looks like without Spacemacs. I've been putting that off because I haven't really learned elisp and I don't know if it's actually possible to have a more flushed out and polished emacs experience without being an elisp master.

I've been planning the move to vanilla emacs for a while now. Spacemacs is a good way to see what powerful tools are out there. I'm just gonna write down which packages I actually use regularly from Spacemacs and then start my config with those and see what's missing. It will probably be a stressful transition, so I'm putting it off for now. I will probably also take the chance to manage all my emacs packages with guix at that point, too.

I've had a similar, although not as extremely bad, experience to you. It does make the project look bad, but I've actually run into this issue with lots of stuff where "stable" is horrendous to use (Debian) and gives the whole project a bad name. I wouldn't mind recommending spacemacs to a friend around my age, but I guess the issue of having to be on develop is something that would make me hesitant to recommend it to my parents (something I've genuinely considered, by the way).

I also frequently wonder how I'd introduce spacemacs to someone who hasn't used vim or emacs... I used vim for a very long time, so to me it's great that my knowledge carries over. I just don't know if it makes complete sense to say to someone "vim has better bindings than emacs, so even though this is emacs, you should learn these vim binds". Plus then they should probably still know at least the basics of emacs for screens where evil fails you, or for if they ever have to use emacs on another machine, or for when an emacs bind is better ("C-x h" seems better than ggVG to me).

as a vim user, I'd have to say no... don't recommend it to vim users. There have been, for me, too many edge cases where I just end up in that helm(?) display thing at the bottom when I was trying to do some simple thing. For ages :edit and :write and :quit didn't work. As the parent poster mentioned the installation doesn't work. You really have to be willing to work for it. I've commented about the incorrect docs and the need to tweak things to make it use insecure downloads and they seem content with the idea that there's a known workaround, that isn't mentioned in the docs.

i really _want_ to use it. I love vim's modal editing, but extending vim is a pain in the butt, and I'd love to use lisp to tweak my editor.

But, I absolutely can not recommend spacemacs right now.

Installation process is broken crap (at least on the mac) and you end up having to deal with meta-this-that-the-other way too often for simple (non-advanced) vim commands.

It sounds like you're avoiding some of the benefits that emacs brings. Helm was one of the biggest additions for me. I also love that every action is a function that can be called, and that you can make your own functions. I often hit `SPC SPC` and then run commands from helm. I've even used its fuzzy-finding search to find functions I wasn't sure existed. It's a real joy for me.

I do use `:e` and `:w` pretty often, so I'm grateful those work. I suppose I would've felt very differently if I'd ran into issues with them early on. I don't actually use `:q` from spacemacs since with emacs you often leave open all your visited files. If I do want to get rid of something, I tend to do `SPC b d` for buffer delete.

>installation doesn't work

I think on my GNU/Linux machine the installation worked for me. I first started switching to the develop branch because of a bug in one of the layers I enabled that was fixed in develop.

>insecure downloads

I definitely haven't made this change that people are mentioning.

Have you used vanilla Emacs + Evil? Any thoughts on that combination?

The one thing that keeps me from moving lightweight editors like vim or emacs from the bloated IDE stuff if the ability to easily find definitions, etc. If I have hundreds or thousands of source files and I want to find the definition of say a struct or function, being able to right click->go to definition or similar is a godsend. Maybe emacs or vim have similar features via plugins though? I'm not sure.

It's a pretty basic feature, so of course they can do that, and now with language servers they can do even more.

What they usually can't do is the more involved stuff, like refactoring, because there is no company who pays people to implement these for emacs/vim.

You can do refactoring in Emacs for many languages with packages like js2-refactor, clj-refactor, etc. It's language-specific.

It's true that funding is important. CIDER has benefited from this system: https://www.clojuriststogether.org/projects/

My package dumb-jump might be what you want:

https://github.com/jacktasia/dumb-jump

It's easily the best zero-configuration, nigh any language symbol locator, for _any_ editor or IDE.

Thank you for that package!

This functionality is provided by `xref-find-definition`[1]. For many languages this defaults to using keywords from a generated tags index file, but many modes have a language server or some other more specific facility to provide this functionality at runtime. I'm not familiar with what provides that functionality for C/C++, but Ruby has `robe`, python has `jedi`, clojure has `cider`, rust has `racer`, etc. It generally requires a some setup for each language you use, but there is broad support for this functionality (and it often provides some form of symbol auto-completion as well).

Some modes also support limited refactoring tools[2], but that's not quite as common.

[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Xr...

[2] https://github.com/clojure-emacs/clj-refactor.el, https://github.com/Wilfred/emacs-refactor, https://www.emacswiki.org/emacs/SemanticRefactor

There's a bunch of "plugins" for Emacs (and vim, I guess, that provide that, but I wouldn't know). xcscope largely does what I want and I've successfully used it on very large codebases (think Linux kernel + vendor-supplied HAL + a very large amount of userspace code).

It's hard to beat an IDE on a large, disorganised codebase though, I'd lie if I said I only use Emacs and never reach out for an IDE.

That sounds like it might work. The recent instance that I ran into was working on an OS kernel, where I wanted to jump interface definitions that might be in different directories

using vim for go-to-definition, `gd` takes you to local definition, `gD` to global, q.v. :help gd

I find it often quicker than an IDE..

lightweight editors like emacs... The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again.

Is Emacs Lews Therin Telamon?

Ahh. "Eight Megabytes And Constantly Swapping".

Happy sigh...those were the days :-)

Thanks to the Language Server Protocol (LSP) pioneered by VSCode, that is no longer the case. Emacs has a great lsp client (lsp-mode) and you get all the capabilities of modern text editors.

It's a great time to be alive

A simple one that works out of the box (I think) with vim is ctags, install it and run "ctags -R" in the code directory. Then in vim hit "ctrl-]" when your over a name to jump to it, hit "ctrl-o" take you back up a level.

It's not as sophisticated as an IDE, but it works with practically any language and is easy to customize.

> Sometimes do use nano

After learning vim, I couldn't stand using nano. It seemed like the worst of both worlds. No efficient keybindings like vim, and no mouse support like other conventional text-areas.

Hearing/reading you say that you sometimes use nano made me curious of why and now I see that there seems to actually be quite a few features. I see it has macros, autocomplete, mouse support, autoindent, multiple buffers, editing keybindings to e.g. delete word-wise, linting support, etc.

I never knew... and totally misjudged it as a very basic text editor.

It's still basic when compared with vim or emacs, but now I hold it in far higher regard than Windows Notepad at least.

I kind of feel like that time many years ago I found out that sed had more than just s///.

I've found sublime text to be the one exception to the slow text editor trend. It's native ui instead of based on electron, wish it was open source but I'll happily pay for good software.

I run emacs -nw --daemon, but on OS X it's noticeably slower (running in iTerm, tmux) than it is on Linux. It's not what I would call snappy at all tbh. I've checked it's not my config. I wonder how come?

That's the exact setup on macOS I run as well. I also run that way on my Linux development box (iTerm2 -> tmux -> ssh -> linux -> tmux (nested) -> emacs -nw --daemon) and it feels the same to me.

I run emacs-plus macOS variant, which one are you running?

Tried everything to no avail. `history | grep "brew install emacs"` gave me this:

  brew install emacs
  brew install emacs --HEAD
  brew install emacs --with-cocoa --with-imagemagick@6 --HEAD
  brew install emacs --with-librsvg --with-cocoa --with-imagemagick@6 --HEAD
  brew install emacs --with-gnutls --with-librsvg --with- 
 cocoa --with-imagemagick@6 --HEAD
  brew install emacs --devel  --with-cocoa --with-gnutls  --with-librsvg --with-imagemagick
  brew install emacs --HEAD --use-git-head
  brew install emacs-plus --HEAD

The thing is, I like to have things like auto-import, auto-complete, errors in the editors and other nice things (in Scala typically).

With Emacs that means Ensime, and Emacs becomes just as slow as VSCode+Metals or IntelliJ.

Testify, friend.

The most flexible programmable editor is probably Acme though.

I've seen implementations of ACME's plumber as Emacs modes, I haven't seen implementations of Emacs in ACME.

ACME's plumber is very cool, and allows very easy customization of how some things work. Much easier than these things typically are in Emacs. But this behavior is implementable in Emacs (I wish it were standard), and lots of things that are hard-coded in ACME are fully customizable in Emacs.

Sure, Acme lacks - well: intentionally does not have - theming, font changing etc., although some modifications (like Acme2k) exist which change that. Acme is probably more about "getting things done" than about "looking good" ... :-) (that sounds harsher than intended - I like Emacs for its flexibility and it was my Usenet reader until last month).

Interestingly, the first Emacs "plumber" which I have found after you wrote it literally uses Acme's plumber: https://github.com/alcah/sink.el

I wish Emacs had 9P support though.

So it's not the most flexible then.

Reply on news.ycombinator.com