Completely agree

Also add to this the trend or rise language servers .. emacs can continue to be used as a solid ide alternatives

And .. guile emacs hopefully one day

Any work to improve and re-use emacs is good for everyone

> And .. guile emacs hopefully one day

I'm hoping for a Common Lisp emacs, myself. Scheme as specified just isn't a big enough language, and if you pick one of the better implementations (e.g. Racket, which is awesome), then it's not really Scheme anymore (e.g. Racket, which is really its own language by now).

I would still call it Scheme, just not R*RS Scheme.

I hate to admit it, but the slowness of Emacs is why I avoid it. A good JIT which hopefully speed it up would be amazing.

I don't find emacs slow, and I spend most of my day in it. What is annoying, is that when it blocks, all frames and windows block.

Maybe this will improve in Emacs 26: https://www.reddit.com/r/emacs/comments/7ta67n/is_emacs_mult...

Which use cases are slow for you ? you used it on large code base or parsed cpp source ?

A quicker emacs would be neat, but most of the time emacs gets speed from flexibility (it might be slow but I can automate something) and design decision (magit for instance blows 99% of the fastest git interfaces)

ps: one part that realize is that I don't like emacs daemon, and even curated my setup on windows (probably the culprit) takes a few seconds. It's not slow but often I want a buffer right away so I use notepad u_u; stupid I know.

Also worth mentioning that whatever is slow, profile it to find out why. Sometimes only the smallest tweak is necessary to get it up to speed again. (Different tweaks for different configurations, so can't be a default.)

For interactive use, profiling is as simple as M-x profiler-start, doing what causes the slowdown, and then M-x profiler-report.

Good point, emacs has a lot of tooling (edebug and tracing too) but it's rarely demonstrated, and since emacs is so large..

In my case there's nothing slow but IO, I should try on another windows laptop with a faster SSD (mine is low grade) to see what is what.

With an Emacs server/daemon, it loads faster than Vim for me.

I would happily agree but I lost the one emacs and 119422 buffers mindset. I get lost in my own shit. I should spend time improving my ibuffer grouping but even then.. I like the idea of pop, edit, kill (which causes my harm).

If you bind crux-kill-other-buffers[1] to a key, you might end up with a workflow you're happy with.

[1] https://github.com/bbatsov/crux/blob/master/crux.el#L496

My solution: Accept that there will be dozens or even hundreds of buffers and use helm-for-files (which lists recent buffers first) to switch between the buffers I care about at any given time. Works really well.

I think I need some fancier categorization like day columns, and content tags. But I'll keep your suggestion in mind

I've noticed that pasting large amounts of text (> 1000 lines) can make it grind to a halt for several minutes. I don't know if it's due to the mode I'm in.

More than the number of lines, it's the number of characters on a single line that causes the slowdown. Thankfully I don't have a real usage scenario where I handle thousand character line files.

I can edit multi-thousand line (5k+) Org documents just fine. So it's probably the major mode or some minor mode(s), or a combination.

In my experience that's often due to major modes that try to format and syntax-highlight on the fly. Keep in mind that some forms of pasting are really equivalent (from Emacs' PoV) to a crapton of keystrokes being entered.

Anyway, the workaround I have for the occasional time I have huge things to paste is to switch the buffer to fundamental-mode before pasting, and then switching back.

As a curiosity, what kind of things are you pasting that are that big?

If you are dealing with large text files of JSON or XML of 1MB or larger you can turn the buffer into Fundamental mode and turn off line numbers.

I’ve found that the reason why large files are slow is due to formatting and linting and not the size of bytes on disk.

With fundamental mode and no line numbers it feels as fast as Vim or Sublime to me.

Long lines are slow, but it handles well otherwise. For long lines, I disabled bidi-display-reordering and switched to fundamental-mode and it really helps.

Few editable systems are happy with 1K lines. I remember a discussion where only one editor was happy dealing with that, all other became sluggish.

1k lines does not stress many editors. It only stresses emacs when the major mode is doing lots of stuff to highlight and format.

I regularly used other editors on C files with 30k+ lines, 15 years ago when machines were slower.

Emacs' real weakness is an over-reliance on regexes for highlighting and poor integration with sources of semantic and symbolic information for richer highlighting, editing and browsing. That, and synchronous operations for the same.

> 1k lines does not stress many editors.

but folks here are talking about _each_ line >1k characters, not total number of lines in a file...

it's true that the syntactic system is too ad-hoc for heavy duty

Honestly, I don't much notice emacs being slow, esp. given how much it's doing for me under the hood.

One key thing is to always always always use emacs in dæmon mode, rather than starting up a new emacs for each file (as would be done with vi). With an always-running emacs instance, start-up time is no longer a factor, and the editor itself is plenty fast enough once it's running.

I use a nox emacs with minimum .emacs for quick editing in terminal. Its startup time is comparable to vi.

ELISP is a pretty fast language, faster than VimScript or JS for sure.

EDIT: Also, Emacs is bloated is bloated because it's not just a editor its's an Web Browser, Email Client, News Reader, Music Player and File Manager. If people want a light emacs, they can go use uEmacs or become the last JEDi.

It's a good glue language, like Python. Better than Python in the sense that its internal representation is based on tagged values instead of ubiquitous pointers: for example, 43243 represents itself and isn't a pointer to a some reference-counted PyObject representing an int.

And because Emacs Lisp a lisp, you get extensive syntactic malleability that you can use to build DSLs and convenience facilities.

Elisp is actually a very nice little language.

Your absence from emacs-devel is felt, there was so much excitement when you were around.

“Fast” is really a meaningless and vague word. What specific part of emacs lisp is faster than javascript in what regard?

For what it’s worth, V8 among with some other JITs are some of the fastest engines in the world: https://arewefastyet.com/#machine=29&view=breakdown&suite=as...

> V8 among with some other JITs are some of the fastest engines in the world

I find that doubtful, when the jvm is so close to native code in terms of performance, and mozilla said that wasm (or was it asm.js? Forget which) was still 50% slower theoretically than native code.

Hotspot among with other JVMs are no doubt fast -- but partially that came from Java being a static and compiled language.

Not saying that JavaScript is faster, but JavaScript is fast. If you look at the benchmarks I posted, you'll notice that 50% slower is hardly the norm -- many benchmarks have the VMs performing at a near-native performance, and the VMs are even faster in some cases.

In fact, number crunching in JavaScript has been fast for a long time, and even faster than Java in some cases: http://www.stefankrause.net/wp/?p=144

I'm not trying to advocate JavaScript's performance in anyway however. I'm merely pointing out the fact that performance cannot be single-handedly described as "fast" or "slow", especially "for sure". Context matters. A lot.

> still 50% slower theoretically than native code

How can something be theoretically slower? What's the difference between theoretically slower and practically slower?

Only practical implementations have a speed that you can talk about.

I don't know what you mean by 'theoretically' as an adverb there.

I suspect it means something like "according to calculations using a noticeably approximate model of reality". That's what people tend to mean, anyway. "Theoretically" is often code for "My model does not correspond to reality".

It annoys me, actually, that "theory" has this negative connotation of noncorrespondance.

Not being an emacs user, can you compile all that out to slim emacs down?

You can, but it's probably not worth the effort. Most of that's in the form of lazy-loaded byte code. Other than some lightweight stubs for the entry points, Emacs doesn't load those pieces until you use them.