top | item 35642374

(no title)

JadedEngineer | 2 years ago

IIRC a single-thread, slow userland that is. Emacs is the only CLI program I've ever run that would take a second or two to render when quickly switching tmux panes. I'll never get the "use emacs for everything" mantra.

discuss

order

m463|2 years ago

I'll tell you I would love if emacs could take over text box input for firefox.

This goes double for crufty enterprise apps that use editor-in-the-browser panes that get in the way or lose data.

forty|2 years ago

Weird, I haven't used Emacs for that long and I really feel why I'd want to use Emacs for everything. I don't mostly because it seems annoying to setup the slack integration + SSO and that kind of thing. But I'd definitely want to write all my texts in (evil) Emacs, have all my to-do/Gitlab task/slack reminder /etc in org mode and review Gitlab PRs without ever opening a browser, etc

JadedEngineer|2 years ago

I absolutely get not wanting to leave the terminal, I'm the same. And I wanted to like Emacs for that. But it's just really slow, and the moment you have a number of buffers with lots of content it's hardly usable. And don't get me started on its terminal emulators, anything with lots of outputs will show on screen at x0.5 speed. I compare with tmux for changing context and it's night and day.

ParetoOptimal|2 years ago

> Emacs is the only CLI program I've ever run that would take a second or two to render when quickly switching tmux panes. I'll never get the "use emacs for everything" mantra.

If you were using tmux, you weren't using emacs for everything!

Emacs for everything also includes replacing terminal with eshell/eat and eventually even frequently curses applications with emacs variations.

dingosity|2 years ago

because it does what i want my computer to do.

sure, VI would be faster, but i would have to use vi.

q7xvh97o2pDhNrh|2 years ago

vim is also pretty slow these days.

Even after I did the usual toil of analyzing startup times and trimming my vimrc, its speed/responsiveness correlates inversely with the size of the text file that's open. And we're not talking about some artifically-constructed benchmark — just an extra-long ordinary text file (or log file, or code file) sitting around will be enough to make vim start to feel slow.

Maybe we're all just getting old, and the dream of "one text editor for everything" is becoming one of those quaint old notions of yesteryear.