I'd replace the underlying data structure used to represent buffers (https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...) with something more sophisticated, like ropes or piece tables.
Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
131–140 of 340 posts
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#132Allow for user controllable window layout within the frame, objectively the editor's only significant drawback.
god yes please. "Will I get a new window? If so, where will it be?" If I could have Emacs with Acme-style window management, that'd be perfect
After years of vim and windows parkour, I started using Emacs, and while the windows management was a bit irritating at first, I made my peace with it and use them in a more focused manner and rely more on the buffer list. I use register if I need a particular configuration.
Vim feels like working on a moodboard while Emacs is more a study desk.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#133I'd replace the underlying data structure used to represent buffers ( https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... ) with something more sophisticated, like ropes or piece tables.
Why? Not saying it’s a bad idea, but I probably don’t understand what’s practically wrong with the simple design of emacs’ buffer class.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#134I would probably just implement vscode but for the terminal. Emacs shortcuts already work by default in vscode for the most part.
While Emacs is recognisable for its shortcuts, it is hardly a defining feature. Example: Doom Emacs adds Vim shortcuts, and it is still distinctly Emacs. I think of VSCode as “Emacs, but JavaScript instead of Elisp.” That’s one thing I would not choose, in spite of the good things VSCode brings to the table.
VSCode is notepad with plugins, built upon a web engine. Comparing it to Emacs is a huge disservice to Emacs.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#135I like emacs for its flexibility and its ability to be a platform for people to build just about any extension. So for this you'd need a solid scripting language. I was never sold on Lisp but it's fine. I'd prefer to see lua; it just makes more sense. The repo-reference stuff works pretty well all things considered. If it were python it would be hell. Crazy side of me would like to see it fully written in a safe(r) l…
> Crazy side of me would like to see it fully written in a safe(r) language like rust, swift or zig. Emacs Lisp is a very safe language. Even though the Emacs core is written in C, that is immaterial and impalpable to Emacs users as they only interact with Emacs Lisp. What benefits would Rust / Swift / Zig bring to an average Emacs user? > Basically your config would be a recompiled subsystem, loaded at runtime, or y…
The pseudo-JIT provided by gccjit is really quite good. I’ve been using emacs for a pretty long time and it is definitely the most noticeable improvement they’ve added so far (and it even works seamlessly out of the box on windows!)
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#136I wouldn't. I just used vim
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#1371. I would like higher-level datatypes for key abstractions, such as (1.1) Marks -> StableRegions - reference specified text within a buffer - continue to reference same text despite insertions or deletions (1.2) Strings & characters -> StringBuffers - lightweight immutable buffers (no branches or versions) - able to hold any content a subset of a buffer can hold - could be StableRegions of an Arena Buffer (1.3) Abst…
Are all these “higher-level datatypes for key abstractions” trying to achieve first-class collaborative editing? That sounds a lot like Zed.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#138- throw away c language mode and and rewrite it from scratch - make dired more usable like a normal file manager. opening a file with the associated program that would persist after emacs closes should be its primary feature. ideally i want something like a mix of ranger/lf with dired - make it have fully-featured terminal, not dumb terminal. make it easy to open lots of terminal windows. add a way to change terminal…
All of this is possible in the current Emacs.
1. You can already define what program opens a file in dired. You could even use detach it from the Emacs process so it stays open when Emacs closes.
2 we already have vterm, which has all the features you described.
3. There are ways to make this better. I am actually in the process of writing a blog post about working efficiently over tramp.
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#139I’d get rid of the text editor and swap in neovim or hx code as a mode, I’d chuck emacs lisp and use Common Lisp instead, I’d definitely keep org mode and ditch old stuff like mail and news reader as core and let them be add ons written in CL . Rewrite it all in rust. That’s probably enough for today.
What advantage would you get by rewriting it in Rust?
Re: Ask HN: If you were rewriting Emacs from scratch, what would you do differently?
#140Realize that VI was the superior editor, give up on the endeavor, print out the code I had already written for emacs, shred it, then set the shredder unceremoniously on fire.
For those that downvote me, worth it.