Hacker News Reader

Comment by smitty1e | Hacker News Reader

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.

View on HN

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.

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?

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?

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.

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.

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.

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

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... :-(

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.

> 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.

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.

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.

10 seconds of startup time 10 years ago was nothing.

The day had 86400s then as now.

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.

Reply on news.ycombinator.com