4 ms·

I use it in a pinch fairly constantly. Despite being a heavily customized Emacs user all the rest of the time. Mostly when I'm already scouring around the shell

I use it in a pinch fairly constantly. Despite being a heavily customized Emacs user all the rest of the time. Mostly when I'm already scouring around the shell poking at files or need to make a simple new one (like a .gitignore) and I don't want/need to perturb whatever else I'm doing in Emacs.

subway 9y ago
This post makes me so glad to have been forced into vi all those years ago. Its everywhere, its quick, and unless you've done some pretty nutty stuff in your configs, basic usage is the same between a heavily customized vi and the vi you find bundled with every is bundled windows and gentoo. (Not to disparage any preference for emacs; it just seems a bit much to have to fall back to an entirely different editor seems a bit much)
- im_down_w_otp 9y ago
  I don't _have_ to "fallback". I just choose not to interrupt the extremely rich development environment I have setup in Emacs and my projectile projects by bringing in random other files/buffers. It's akin to the same justification for why I wouldn't bother opening a random tiny file in Xcode or IntelliJ IDEA. I don't use Emacs as just a simple text editor. I can probably count the times I've typed `emacs some/file/path.whatever` into the shell on one hand.
confounded 9y ago
If you start Emacs server as a daemon, you can use it pretty much like you'd use nano/vi/vim in the terminal, without disturbing anything. With an Emacs server running, for me, it loads faster than vim. I have a bash function along the lines of et() { emacsclient -tty --alternate-editor '' "$@" } .. for using Emacs in the terminal a-la vim/nano. When you close the file you opened, you'll be right back where you left-off in the shell. I still tend to use a long-running GUI instance as you describe, but for jumping into config files from a terminal to edit a line or two, it's great.

subway 9y ago

This post makes me so glad to have been forced into vi all those years ago. Its everywhere, its quick, and unless you've done some pretty nutty stuff in your configs, basic usage is the same between a heavily customized vi and the vi you find bundled with every is bundled windows and gentoo. (Not to disparage any preference for emacs; it just seems a bit much to have to fall back to an entirely different editor seems a bit much)

im_down_w_otp 9y ago
I don't _have_ to "fallback". I just choose not to interrupt the extremely rich development environment I have setup in Emacs and my projectile projects by bringing in random other files/buffers. It's akin to the same justification for why I wouldn't bother opening a random tiny file in Xcode or IntelliJ IDEA. I don't use Emacs as just a simple text editor. I can probably count the times I've typed `emacs some/file/path.whatever` into the shell on one hand.

confounded 9y ago

If you start Emacs server as a daemon, you can use it pretty much like you'd use nano/vi/vim in the terminal, without disturbing anything. With an Emacs server running, for me, it loads faster than vim. I have a bash function along the lines of et() { emacsclient -tty --alternate-editor '' "$@" } .. for using Emacs in the terminal a-la vim/nano. When you close the file you opened, you'll be right back where you left-off in the shell. I still tend to use a long-running GUI instance as you describe, but for jumping into config files from a terminal to edit a line or two, it's great.