4 ms·
I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they'
by cytzol 11y ago
I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they're designed for use on the command line rather than as an environment I can switch in and out of. I know this isn't strictly true as both editors can be run as separate applications that you don't quit for weeks, but their roots have persisted into how they're expected to be used.
Take my first foray into vi, at its most basic level. I'm at a shell prompt, where I can use vi to edit multiple files, saving each one when I'm done with it and occasionally switching to another window to run something else, coming back when I need to edit more. But there's nothing storing my list of open files or buffers and where they are on my screen, my position in each file isn't saved; it's like vi expected me to spawn a new instance every five minutes.
When I tried emacs, which allows much more functionality inside the editor -- connecting to servers, databases, or hosting shells or debuggers -- it just made the problem worse. If I started a shell inside emacs before stopping the emacs process entirely, that shell won't be there when I get back and my files won't either. If I want to have a specific file on the right-hand side of my screen, emacs will forget where I put it. If I open a file in a new window, that file will be gone. If I want to have a file stand out by changing its background colour to a subtly-different hue, that will have changed back by the time I need to re-open my editor.
I don't like this idea; I don't want my editing environment to be some ephemeral process that's created when I start and gets destroyed when I'm finished. And while Vim has sessions and Emacs probably has three forms of saved states, they don't quite work: no saved window positions and sizes, no working with files you haven't given a name. I imagine that it's the same feeling you get when you read that something allows Emacs-like functionality: on a checklist, they might both have tick marks on each row, but when you try to use it, it doesn't work how you expect. I think that Emacs and Vim's command-line history have made its users used to this behaviour, spawning all sorts of tools to make configuring your environment easier instead of just trying to save the changes as they happen. I've seen plugins like CtrlP or projectile that enforce the idea that your environment shouldn't last, you can just set it up again each time. And that means you don't bother personalising your environment and putting things where you want them to be, because it's all going to be irretrievably gone if your computer crashes, so don't get attached. Alright, rant over.
- protomikron 11y agoShort life times for vim are more a thing on remote sessions, e.g. for server configuration. I agree with you, that such a work flow is suboptimal for the general development case, so I will just describe what works for me: Do not close vim. I keep a main vim instance which has different buffers open. These buffers have their own history, e.g. undo-tree, etc. And keep in mind, that it takes time to get adjusted to vim, otherwise one gets overwhelmed quite quickly. E.g. I suggest to ignore windows and tabs at the beginning and get comfortable with buffers first (e.g. mostly I only use buffers).
- cytzol 11y agoYeah, I do still use vim on remote sessions where I know I'm just going to be making a small change and then be done with it -- losing your entire environment or history is a lot less worrying in that case, and it's way easier than mounting the server locally or something. However, as someone once said: "The universe tends toward maximum irony. Don't push it." If you don't close vim and keep it open for weeks, then all your environment changes are going to keep on building up, only for you to lose everything the next time you need to restart your system, or upgrade your editor or terminal, or your OS crashes, or there's a power failure, or your computer catches fire.
- super_mario 11y agoIt seems like your major objection is persistence of your session (which is more than just editor instances) but it includes your shells, their position on filesystem, your terminal splits, their position and color etc. There is a tool that handles exactly that and its called tmux. It allows you to create a session (or multiple sessions), create windows, position them exactly the way you like, open your editor of choice in one or more of them, or have other tools display useful information etc. And these session survive restarts, and you can connect to them through ssh etc. And you can navigate those windows with keyboard or mouse etc. This is useful for long running work, but more often it is not necessary. If you are just exploring the code base or making small edits here and there you don't really need persistent tmux session for that.
- 11y ago