I am having high hopes for this project.
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
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).
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.
For interactive use, profiling is as simple as M-x profiler-start, doing what causes the slowdown, and then M-x profiler-report.
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.
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.
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?
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.
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.
but folks here are talking about _each_ line >1k characters, not total number of lines in a file...
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.
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.
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.
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...
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.
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.
It annoys me, actually, that "theory" has this negative connotation of noncorrespondance.
I will bring the obligatory guile Emacs rant:
I am very much biased,but guile Emacs is very much a viable option IMO. Guile3.0 will be natively compiled (or at least jitted), and the work Andy Wingo is putting into guile is just amazing. The guile codebase is nice, and most of the hard work integrating it into Emacs is already done.
The elisp runtime has some optimization work left, but it seems to be quite a lot of low hanging fruit.
Guile is a very nice scheme implementation for those who are brave enough to leave the warmth of elisp.
As an example, I get that emacs would have to parse the entire buffer I'm in in order to syntax highlight as I'm typing. For that, I think this is going to be required. However, emacs should be able to offload to another process to look up external symbols. GLOBAL is the tool I use nowdays, and updating the tags database or looking up symbols is something that should be getting heavy lifting in an external process.
Or am I looking at things the wrong way?
… there's life outside of emacs? grin
I'd rather do stuff in-process, but with good support for asynchronicity. It's nice that I can M-. to the definition of anything I'm using, nice that I can patch it in-memory and nice that it's all written in a decent language (elisp isn't perfect, but it's pretty good).
And, I cannot argue against the merits of a language server. Having a single one would be more efficient in many ways. I just find our fixation on "not reinventing the wheel" to be detrimental in many ways. I'd rather we were "don't get stuck with a monoculture."
And I say this as someone that highly respects the LISP community. It is impressive how much you can do with really old libraries there.
Note that this isn't really that new, for the modern tag. Cscope was already an external command. And you already offloaded the tag creation to an external process. I see very little need for the tag navigation to all be in elisp.
The final selection, of course, can still be in elisp. Since that will be user input driven.
What do you use for GLOBAL? ggtags.el works like you describe (calls start-file-process to start a GLOBAL process).
My only complaint is it still blocks sometimes. Overall, works like a champ.
Clojure has a compiler option toggle for this called direct linking. It just says that functions can't be redefined (unless they are marked redef using a metadata key). You can also mix and match libraries compiled with or without direct linking, for example the core library uses this compile switch.
I have used guile-emacs and back then even org-mode ran fine. Elisp-compatibility is very close to 100%, and the runtime is getting better by the week (guile3 will do native compilation!), but nothing will ever be enough.
So instead of having a runtime not bound to Emacs, with all the cons that would have with libraries and such (Imagine a guile-orgmode that contained the vital parts of org scirptable in guile without Emacs), we are stuck with a language tethered to an editor bound to be just an extension language.