41–50 of 340 posts
Emacs is fine, but buggy as hell. Their version of Lisp is clearly not suited for any large-scale development. (This trickles down hard into user experience, i.e., lack of parallelism or multithreading.)
Is this so obvious as to go without examples? I'm no Emacs power user, nor even really an Emacs user, but it certainly conflicts with my understanding of core Emacs.
Earlier quoted context omitted.
> If text in Emacs looked as pretty as text on the web does Do you have an example of this? I can't tell any difference for the fonts that I use (with emacs-pgtk). I believe Emacs uses Harfbuzz (same as Chrom{e|ium}).
Huh. I use pgtk Emacs, too, and am surprised to find someone who doesn't find my statement obvious.
I would probably just implement vscode but for the terminal. Emacs shortcuts already work by default in vscode for the most part.
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.
Instead of making the first class installable extensions plugins create a primitive called modes that encapsulate groups of plugins with extra configurations so that instead of having to pick every plugins for our setup we just pick the most popular javascript or ruby etc. mode and then add a couple of our own plugins on top.
Add some system that suggests hotkeys based on usage. If I hit l 20 times instead of just hitting f’ to get to the end of the line show a popup. Gamify the key maps and suggest key maps and features even from my plugins.
Instead of having a package manager for your editor just use homebrew and integrate it deeply into the editor.
The core should be in rust, verfied in lean, and the runtime should be in guile. Literate programming in org-mode should be a hard requirement. Package management should require patch algebra. Macros should be submitted to a leaderboard in a blockchain and yield flair in EUDC. M-x measure-beard-length should require 10000 hours of logged usage and unlock the major mode infinity-categorization. Tongue-no-longer-in-che…
Since I agreed with all of these, I’ll add some more non-ironic, idealistic wishes:
Plugins must be written in sandboxed WebAssembly so you can know what a plugin is capable of without reading the source code. The runtime must be portable so it can run in wasm32-wasi.
- instant startup
- blazingly fast scrolling
- minimal keypress-to-display latency
I have written a lot of elisp (and had to deal with with buffer variables, dynamic scope, etc.), but aligning with modern scheme or lisp (if it can be kept compact and efficient) probably makes sense at this point. (Current emacs should provide backward compatibility as needed.)
Since so many people use emacs as an IDE, I think having an official emacs co-project/subproject focusing on a standard, extensible IDE framework (perhaps for other apps as well) would make sense.
It still seems like a pain to display graphics in emacs in various terminal apps. This should be easy, fast, and standardized.
As others have noted, supply chain attacks against open source are rampant, so vetting and sandboxing packages seems to be more important now.