5 ms·

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 p

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.

dingosity 3y ago
because it does what i want my computer to do. sure, VI would be faster, but i would have to use vi.
- q7xvh97o2pDhNrh 3y 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.
  - JadedEngineer 3y ago
    > 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. I mean, that's only ever been a dream in the emacs community. Vim might have toy plugins for other stuff, but by and large people use it to edit period. As it should be, isn't the whole UNIX philosophy to do one thing well? If I want email or a text browser in the CLI (I don't) I'll use dedicated, better, faster programs, each on a tmux pane that I can use instantly with a keyboard shortcut, rather than wait for a slow emacs buffer to load.
    - ParetoOptimal 3y ago
      > I mean, that's only ever been a dream in the emacs community. That's not true and not something you could really accurately guess at. I have exclusively used one text editor for everything (emacs) for many years. I also know others that have done the same.
  - User23 3y ago
    The problem is one of context. When editing a programming language buffer, the editor needs to be aware of the entire buffer, because a { on the first line could match to a } on the 1235987th line and affect hilighting as well as editing commands like indentation, or sexp navigation. Meanwhile, ideally, in a log buffer the only information needed to nicely render a single line is contained on that line. Or perhaps the log unit is multiline, but still somehow boundable. In that case the editor should be able to do presentation in constant time based on the segment of the buffer that's visible. Unfortunately, what with logging in JSON and so on, these two cases aren't really distinct anymore. But if I did want to use one editor for both log viewing and coding, I'd pick the one that was the most easily and interactively customizable.
forty 3y 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 3y 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.
  - pama 3y ago
    I use the latest versions with native compilation and gave up on terminals and curses codes in favor of plain M-x shells. I tend to accumulate hundreds of buffers, some of them GB size, and all is super snappy. I am very sensitive to latency and can’t stand slow pings, avoid wireless for that reason, and have tuned my keyboards over the years to reduce input latency and errors. Emacs out of the box is super fast. The plain text input loop is in microseconds so not perceptible. And there is hardly ever a need for terminal emulators but when there absolutely is (say htop) then you can use vterm.
    - pmoriarty 3y ago
      On the terminal emulator front, emacs-eat[1] is also worth mentioning. [1] - https://codeberg.org/akib/emacs-eat https://codeberg.org/akib/emacs-eat
    - ParetoOptimal 3y ago
      With eat I can even run htop. This means I have the typical char, semi-char, emacs-mode while the terminal application is active but as soon as I exit it I'm returned to normal eshell where I can treat it as a mostly normal buffer and evaluate elisp. It really feels like the best of all worlds.
m463 3y 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.
- bloopernova 3y ago
  Have you tried anything from this page? https://www.emacswiki.org/emacs/Mozilla https://www.emacswiki.org/emacs/Mozilla
ParetoOptimal 3y 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 3y ago

because it does what i want my computer to do. sure, VI would be faster, but i would have to use vi.

q7xvh97o2pDhNrh 3y 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.
- JadedEngineer 3y ago
  > 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. I mean, that's only ever been a dream in the emacs community. Vim might have toy plugins for other stuff, but by and large people use it to edit period. As it should be, isn't the whole UNIX philosophy to do one thing well? If I want email or a text browser in the CLI (I don't) I'll use dedicated, better, faster programs, each on a tmux pane that I can use instantly with a keyboard shortcut, rather than wait for a slow emacs buffer to load.
  - ParetoOptimal 3y ago
    > I mean, that's only ever been a dream in the emacs community. That's not true and not something you could really accurately guess at. I have exclusively used one text editor for everything (emacs) for many years. I also know others that have done the same.
- User23 3y ago
  The problem is one of context. When editing a programming language buffer, the editor needs to be aware of the entire buffer, because a { on the first line could match to a } on the 1235987th line and affect hilighting as well as editing commands like indentation, or sexp navigation. Meanwhile, ideally, in a log buffer the only information needed to nicely render a single line is contained on that line. Or perhaps the log unit is multiline, but still somehow boundable. In that case the editor should be able to do presentation in constant time based on the segment of the buffer that's visible. Unfortunately, what with logging in JSON and so on, these two cases aren't really distinct anymore. But if I did want to use one editor for both log viewing and coding, I'd pick the one that was the most easily and interactively customizable.

forty 3y 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 3y 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.
- pama 3y ago
  I use the latest versions with native compilation and gave up on terminals and curses codes in favor of plain M-x shells. I tend to accumulate hundreds of buffers, some of them GB size, and all is super snappy. I am very sensitive to latency and can’t stand slow pings, avoid wireless for that reason, and have tuned my keyboards over the years to reduce input latency and errors. Emacs out of the box is super fast. The plain text input loop is in microseconds so not perceptible. And there is hardly ever a need for terminal emulators but when there absolutely is (say htop) then you can use vterm.
  - pmoriarty 3y ago
    On the terminal emulator front, emacs-eat[1] is also worth mentioning. [1] - https://codeberg.org/akib/emacs-eat https://codeberg.org/akib/emacs-eat
  - ParetoOptimal 3y ago
    With eat I can even run htop. This means I have the typical char, semi-char, emacs-mode while the terminal application is active but as soon as I exit it I'm returned to normal eshell where I can treat it as a mostly normal buffer and evaluate elisp. It really feels like the best of all worlds.

m463 3y 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.

bloopernova 3y ago
Have you tried anything from this page? https://www.emacswiki.org/emacs/Mozilla https://www.emacswiki.org/emacs/Mozilla

ParetoOptimal 3y 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.