Someone created lem [0] which is basically an Emacs in Common Lisp. I don't know for concurrency but I hope it is designed to do so. Also there isn't org-mode.

[0] : https://github.com/lem-project/lem

Hard agree that these are true ‘fundamental pitfalls’ of Emacs’ design. However I may go further on your third point. I would like to see a dedicated new user/learner mode that in addition to saner defaults would be pretty fully configured and pre-loaded with the most common extensions/plug-ins/etc. This could then lead to development of dedicated documentation/tutorials that assist the new user in becoming proficient in the common style/habits of Emacs usage.

This could provide a much simpler full featured ‘base’ state for the app, that can then be customized from that point or can be stripped back by removing the more common add-ons and customized from the ground up.

It would in some ways necessitate a strongly opinionated set of defaults and an additional focus on documentation, but I think in the long run the app would benefit from higher retention.

For those not familiar with why concurrency is desirable in a text editor, can you elaborate?

It (kinda) has multiple cursors per document if you split the frame and display the buffer twice. For longer source files I find myself splitting horizontally, editing in the left pane, and using the right pane for secondary movement and reference.

I have a buffer manager that can switch the displayed buffer quickly, when I switch to a different buffer and back again, it retains it's "secondary" cursor position that is separate from the other view.

It is possible to emulate this in Emacs Lisp. I've created a package to that extent, see http://ankarstrom.se/~john/etc/emacs/scroll-without-point.el. (I've made a few changes to it the last couple of weeks that I have yet to upload, though.) I should probably publish it somewhere else eventually, but I've always felt it to be a bit of a hack. Still, I use it and it works well 99% of the time.

Vim has the same problem: https://github.com/neovim/neovim/issues/989

This might be a dumb question, but how would an off-screen cursor work in a terminal? According to my understanding of the way terminal emulators/ncurses work, the cursor must be positioned somewhere in the screen, even if it isn't visible.

This is a really interesting case of Emacs being so old that its default (and only in this case) behavior is just unable to comprehend current computer technology and usage. I think I am correct in saying that the lack of capabilities to have horizontal scrolling of a screen was an absolute hard limit of the teletype and terminal era. It should not be difficult to add such capability, but more than the obviously connected portions of Emacs’ code could implicitly rely on the assumptions that come from the impossibility of horizontally extending text.

I'll try to use the more common Windows/MacOS terms for it, but in emacs I often have the same file opened in two different panes within one window or two separate windows. I do this when I want to be looking at one part of a file while editing another.

Markers are used to mark a different point in the file and one can pop their location to a previous mark.

This still annoys me slightly after nearly 20 years of using Emacs.

In response to keypresses, it doesn't bother me too much, as I'm used to the Windows-style behaviour of PgUp/PgDn/etc. moving the caret, much as the Mac behaviour of not doing that is sometimes useful. But for mouse wheel scrolling, which I do a lot - precisely because on Windows this typically does not move the caret! - having point follow along has never felt right.

Curious, why would it matter that the cursor stays where you were when paging down?

You might know, but you can set marks to go back when you scroll off. I have to admit it's not as convenient as the cursor just behaving like that automatically, though.

Emacs runs on terminals too. If you want GUI's, you can choose Common Lisp with Lem and MCCLIM, or that newish web oriented GUI with a similar environment.

I'm confused. On the modern devices I've recently used emacs on (including very low-powered raspberry pi devices), all of your three criteria are already true.

What kind of HW are you running emacs on where this isn't the case?

For instant startup I recommend daemon mode and emacsclient. Start emacs via emacs --daemon, open windows (in the terminal or otherwise) via `emacsclient` / `emacsclient -nc` (I use aliases for these).

> instant startup

My config is Doom-based. I use about 300 different third-party packages, and I don't even know how many built-in ones. It takes about 1.3s to start. Wishing for it to start even faster is like wanting my microwave to warm my tortilla in 5 seconds instead of 30. I don't restart Emacs every day, nor do I eat tortillas daily. Use a modern package-manager, and defer the loading of packages, it will start very fast - just like 'emacs -q' does.

> minimal keypress-to-display latency

A lot of times, setting keyboard rate is all it takes to make it nice,

On Linux: xset r rate 170 80

On Mac:

defaults write NSGlobalDomain KeyRepeat -int 1

defaults write NSGlobalDomain InitialKeyRepeat -int 10

> - Implement better sandboxing and security measures for extensions.

Why, pray tell, should this be of any concern at all? Sandboxing is used when the host is concerned about running programs that he doesn't trust. There is no reason that an Emacs package would require security measures around it, unless it were knowingly potentially malware. The only reality in which I could see this is if people were using proprietary Emacs extensions, in which case I would entirely understand it, because then people would be willingly running malware inside their editor. Perhaps this the stance VS Code users like to take towards extensions?

For the Common Lisp part, someone created lem [0], but for the other points I can't tell. I know there is an extension manager being developped, but am not able to judge the robustness. Also that there isn't org-mode.

[0] : https://github.com/lem-project/lem

> Use Common Lisp instead of Emacs Lisp.

Interesting, why not a scheme? Is it because the popularity in the industry? I don't know much about Emacs or lisps and looking to understand better

Are you sarcastically describing VSCode, I don't get it?

LGTM: Ship it!

Prefer Tauri to Electron. It is 2024, after all.

Thanks, I hate it.

> 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}).

Make CapsLock an additional Ctrl. On many old keyboards that is where the Ctrl key was positioned [1].

[1] https://en.m.wikipedia.org/wiki/Caps_Lock#Placement

emacs is not its keybindings. you can bind your emacs keyboard to do what you are asking for; as you said, you wrote a mode for emacs that works the way you want, and it wasn't necessary to rewrite Emacs.

Have never tried it personally, but this talk made me think collaborative editing is a solved or close-to-solved problem in Emacs: https://emacsconf.org/2023/talks/collab/

Are all these “higher-level datatypes for key abstractions” trying to achieve first-class collaborative editing? That sounds a lot like Zed.

My introduction to Lisp was through SICP and Scheme so I used to be in favour of Lisp-1, but having used Common Lisp for a while now I've changed my mind. Treating a function as a value is easy enough:

  (mapcar #'list list)

  (let ((x 2))
    (list 1 x 'x))

It's the finest manure to fertilize thought we can turn over with only a fork

It may be shit, but it's freedom-flavored shit. The best kind.

>beard length is gendered

you insensitive clod

https://www.gocomics.com/calvinandhobbes/1986/02/14

Ok, you had me for the first three sentences.

> 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.

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.

relevant: https://github.com/remacs/remacs#rust-heart-emacs although as of this message it says they've given up in favor of https://github.com/emacs-ng/emacs-ng#contributing which does mention Rust but seems to be ... a lot different from Emacs so I guess they're really going all-in on the "NG" part

for the non-tongue-in-cheek, also relevant: https://www.emacswiki.org/emacs/GuileEmacs#h5o-2

>> see jujutsu nowadays

I'm looking at pijul..

https://pijul.org/

When I saw “should be in rust” my instinct was to flame like nobody’s business, glad I kept reading. Lmao. Good slow burn.

Though, not to put too fine a point on it, I know it was in jest, but the core implementation language is the least of my concerns. As long as it is extremely portable, compiles fast, and runs on virtually anything, then whatever the core is, doesn’t matter much to me.

All sensible email clients have a 'thread view' for just this purpose, which effectively makes it a 'single conversation thread'.

I recently learned FSF does have a GL instance but it seems to be locked down to just "approved" emails and also only used for its CI capabilities: https://emba.gnu.org/emacs/emacs/-/pipelines

I agree, and I've been observing this for years. It's now becoming a generational problem - younger programmers know and understand PR model, they don't want to deal with mailing threads and patches. These days, young people are like: "You sent me what? an email? Are you joking?" People shouldn't be catering for the comfort of the maintainers, no matter how arguably mailing threads are techologically more superior, it should be the opposite.

I have been occasionally been hassled by Emacs package management for forty years.

A few years ago I very much shortened my .emacs file using the Straight package manager and I have been happier.

> 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 you'd recompile the whole editor.

elisp -> bytecode compilation in Emacs… predates humanity?

https://www.gnu.org/software/emacs/manual/html_node/elisp/By...

The entire stash of Emacs packages compiles into the byte code at the package installation time, anyway. Personally, I even byte-compile-file my ~/.emacs to eke out an imperceptible speed improvement at the startup time, which is slightless less than entirely useless but it warms my heart that I can do it.

Recent versions of Emacs can also compile Elisp into the native code:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Na...

> Better key handling and none c-x nonsense.

Perhaps you do not need Emacs then.

> I'd prefer to see lua; it just makes more sense.

To you. To me it wouldn't. If it was Lua, I'd still use Fennel. If it was Javascript, I'd do it in Clojurescript; If it was in C, I'd probably find a way to use Common Lisp or Jannet; If it was Python I'd probably use Hylang or something; if it for whatever reason used JVM (like IntelliJ) or .Net CLR, I'd do it in Clojure.

You see, once you actually grok Lisp, at some point you do become a true "polyglot programmer" - for me switching between different runtimes - JVM, Node, Browser, Native, Lua, etc., is as simple as picking up a different Lisp dialect. Even switching between JS and TS for most programmers is not as simple as for me jumping between different Lisp dialects.

I'm not some indentured servant of one particular programming language, your favorite bits of syntactic sugar and "design patterns" made for one particular PL don't amaze me, don't annoy me, don't make me feel bad or good, I simply don't care. I just want to build shit, and I want it to work. I'm sure if there's an actual God, and he had to explain the universe in written form, it would be in homoiconic scripture - anything, yes, just about anything can be explained in functions, neatly wrapped between parentheses, anything beyond that is fluff made by human pride, simplicity requires less not more.

> The config should automatically be a git repository and any change should generate a meaningful commit (thinking out loud).

git-auto-commit-mode exists, try it.

I used to do a lot of consulting work using Common Lisp on remote servers and would frequently need to set up tmux, Emacs, SBCL, Slime, etc. on remote servers to do my work. Keep good notes, and it gets much easier and faster.

LOL - Haven't seen that one in ages...

Also, there were other emacses that preceded GNU Emacs and were written from scratch: Bernard Greenberg's MULTICS Emacs, written in MacLisp [1], James Gosling's Unix Emacs, mostly written in C [2], and Daniel Weinreb's Zwei, written in Lisp Machine Lisp [3].

1.https://multicians.org/mepap.html

2.https://dl.acm.org/doi/10.1145/62402.62417

3.https://en.wikipedia.org/wiki/EINE_and_ZWEI

What are you talking about? Emacs has incredibly good window control. It is in fact so good, people decided to build window managers on top of Emacs - see EXWM. Yes, the customization is complex and very confusing for beginners, but the levels of control are all there.

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

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.

emacs-ng cites Deno, which speaks to your "more mainstream" as well as some of the sandboxing concerns offered by others https://github.com/emacs-ng/emacs-ng#denojavascript

You could also start at the bytecode level so that the specific language itself is less relevant.

It feels to me, people suggesting using anything other than Lisp haven't had sufficient, heartfelt experience with Lisps. Give me a Lisp any day, sure, Elisp might not be a best of Lisps, but it's a Lisp nonetheless, there's simply nothing better for evaluating things on the fly, there's no better language for rapid prototyping, for structural editing, for metaprogramming.

One has to experience the flow, the fluidity, the functional constructs of Lisp to truly appreciate its elegance and expressiveness. Lisp's code-as-data philosophy enables seamless metaprogramming, where code can be treated as data and manipulated with the same ease as data structures. This unlocks a level of abstraction and composability that is unmatched by most other languages. The functional nature of Lisp, combined with its homoiconicity, encourages a declarative and modular programming style, promoting code reuse and maintainability. Once one immerses themselves in the Lisp way of thinking, the flow of writing code becomes a harmonious dance, where complex problems are broken down into simple, composable functions that can be effortlessly combined and transformed. It's a paradigm that fosters creativity and empowers developers to build robust and extensible systems with remarkable ease.

Sure, Python, Lua, Javascript, etc. They all may seem more familiar, and yet they lack the profound simplicity and expressiveness that lies at the heart of Lisp. While these languages have their own merits and widespread adoption, they are ultimately constrained by their rigid syntax and imperative nature. Lisp, on the other hand, transcends these limitations with its minimal yet powerful syntax, allowing code to be treated as data and data as code seamlessly. It fosters an unparalleled level of metaprogramming capabilities, enabling developers to write code that writes code, unlocking a realm of abstractions and transformations that are challenging or impossible in other languages.

Yes, very challenging, see the examples of using Hyperfiddle/Electric, here's one: [SpreadSheesh! talk by Dennis Heihoff - YouTube](https://www.youtube.com/watch?v=nEt06LLQaBY)

When you say "It's one big X REPL... and it doesn't have to be Lisp", it's already conflicting because you need Lisp to have the proper REPL experience. Those non-homoiconic languages that promise a REPL don't actually provide the "real REPL" experience. Their interactive shells are more limited in comparison to the true REPL provided by Lisp dialects, where code and data are seamlessly interchangeable.

upd: darn, I guess I didn't scroll too far, all the people complaining about Lisp are at the bottom, downvoted and I guess angry because they don't understand why. It's like someone moving from China to US and complaining why everyone refuses to even try Mandarin, after all it's the most widely spoken language in the world, why wouldn't it make sense to use it instead?

Just use Acme under Plan9port. What you said it's the idea the plan9 guys had under to create a Unix 2.0 based 'Emacs' editor instead of vi and the pseudo graphical Sam.

> where you can interpret any language and have them with together.

You can have multiple different source blocks in a single Org-mode document. All in different languages, and they can be passing results between one another. e.g., you can run a piece of bash that runs curl, then send the results of it to Python block, where it calculates something, then to Javascript block that uses some npm package and and then send the results to a SQL block that queries a database and generates a report.

That's bash

Just use Acme. TCL, Perl, Go, awk... on sockets/files, a la Unix.

It's not just you, and it's especially painful on Windows, where working with lots of small files is already painfully slow under the best circumstances.

I bet you're talking about Mac. I hate coming back to Mac after using Emacs in Linux. It feels so sluggish. Even on my Android tablet Emacs works faster than on a M1 Mac.

I wrote some comparisons here

https://coredumped.dev/2023/08/09/text-showdown-gap-buffers-...

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.

Evil does that already and more. There are ex-commands that don't exists in Vim and you can even extend and add your own.

> Emacs is fine, but buggy as hell.

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.

    Emacs is fine, but buggy as hell.

Ship is fine, but leaks as hell.

I'd trade my dog to have Clojure-like maps and destructuring in Elisp. Comparing workflow with maps in Clojure and alist/plist in Elisp won't get any points to Elisp side.

None of the main selling points of emacs have anything to do with its shortcuts or using it in the terminal. Plenty of emacs users (including me) rarely or never use it in the terminal. It’s a GUI editor just like vscode is.

I think this misconception comes from the fact that (1) people often compare emacs and vim, and (2) vim is usually used in the terminal. But emacs and vim are really categorically different things so I think the “emacs vs. vim” meme kinda doesn’t make sense.

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.

I too use vim.

I hope not. Watching the Emacs ecosystem evolving over the years, I'd wish that most things were not default or built-in but came in packages, and Emacs was a tiny, extremely small core. Packages outside of the Emacs core develop faster, evolve better, foster communities around them, have greater flexibility of choice - where to host them, how to license them, how to structure them, etc. Evil-mode, Magit, Projectile, CIDER, etc., they are all great because they were developed outside of the Emacs' core. I can only imagine how Evil+plugins would've slowly decayed with endless email threads on the Emacs-devel mailing list, where RMS would've annoyed everyone asking "why are we trying to build Vim in Emacs instead of Microsoft Word, I've dreamed about WYSIWYG, and you guys are ruining it...".

Strategically thinking, after setting the shredder on fire it will be harder to shred the code of the future emacs clones! :D

That just means you have not reached the point of understanding the philosophy of Emacs. Comparing Emacs and Vim with a one-sided perspective like yours is like saying that motorcycles are better than trains. Sure, they both serve the purpose of reaching from point A to point B, but there's a lot more to it than just that. Similarly, Emacs is far more than just a text editor. Vim's model of navigation is an amazing, beautiful, powerful, and pragmatic idea. Have you ever used it anywhere else than Vim/Neovim? You see, the thing is, there's no such thing as a "vim-plugin", and I'm saying this with confidence of a die-hard vimmer. I've tried them all - different ones - IdeaVim for IntelliJ, Sublime Vim plugins, VSCode extensions, etc. All of them are pretty much filled with laughable deficiencies; they are not even shadows of the actual Neovim experience. With one notable exception, and that is the vim-implementation in Emacs. In Emacs, Evil-mode doesn't even feel like an extension, an afterthought; it feels like it's a baked-in, major feature of the editor. More than that, it can do certain things even better than you can do it in Neovim.

If someone had built a passenger plane with vertical take-off/landing capability, a mere accidental feature of the aircraft that nobody was even supposed to use, I would still respect the heck out of it because the mere presence of it would be proof of ingenious engineering. If you think that "VI is a superior editor than Emacs", I'm afraid you still have a shallow understanding of both.

> For those that downvote me, worth it.

Nay, quite the opposite; I scrolled down specifically looking for comments like these, because I knew they'd be here. Kind of comforting, really.

What constitutes "a good editor" in your mind?

Emacs has an amazingly nice editor, especially for writing in plain language. It even supports right-to-left languages and things like Sanskrit. There are frequent posts in /r/emacs about using it for writing. Many novelists use Emacs for writing, some of them are well-known names - Cory Doctorow, Neal Stephenson, Vernor Vinge, Charles Stross, et al.

There are a number of nice packages that help you with writing - spellchecking, thesaurus, dictionaries, translation, definition and etymology lookup, LLM integration, export capabilities, distraction-free modes, various text manipulation tools and more.

The joke that Emacs is an operating system that simply needs a decent editor has not aged well. It's not even funny in the slightest; it's laughable in the face of the joke teller, telling more about them than Emacs and its editing capabilities.

There's the Leo editor, if Python's what you want: https://leo-editor.github.io/leo-editor/

Dear Cooking Show, I really liked your recipe for the shrimp-avocado salad, and I tried to make it, but since I was out of avocados I just substituted them with potatoes. Also, it turns out I didn't have any shrimp, so I just used some hot dogs I found in my freezer. OMG, this recipe is amazing. You just made my day.

---

That's what using X instead of Lisp to make "a better Emacs" sounds like, okay? Emacs is a Lisp-machine, it's built on top of Lisp, it needs Lisp to be Emacs. Otherwise it wouldn't be Emacs. Like at all. Don't be stupid, stop saying stupid shit like "python instead of lisp"...

I agree.

Maybe it's just personal preference, since I think it's easier for me to think in python over lisp (which I've known for longer, but I still fumble through)

I do think python would make emacs more accessible to a wider audience.

Emacs can perfectly emulate Vim already and even do more than Neovim ever could.

You could use MS Word of Photoshop if you want, we couldn't care less.

We're not talking here about a mere text editor, we're discussing a Lisp machine with level of extensibility and programmability deeply ingrained into its design, something that Vim or Sublime or any other traditional text editor can never achieve.

If I were rewriting Emacs, I would not replace its language with Python, Lua, or Cobol.

I don't like those languages, and I have just as much right to say that as the people who don't like Lisp.

- Can you not put any veggies in the salad?

- What? Okay, so fruits, berries?

- No, no, no fruits either.

- Hmm... what about croutons, nuts, maybe sunflower seeds?

- No, just use meat. I like meat. Just make it with a bunch of meat pieces, alright?

- Well, that is not a salad...

> Not using lisp

Don't you folks realize the imbecility of such statements? Emacs is a Lisp machine that allows writing and loading custom extensions based on Lisp! This level of extensibility and programmability is so deeply ingrained into Emacs, specifically because it revolves around Lisp. Emacs wouldn't be possible without Lisp.

why the downvotes? This is a reasonable point of view.

I sometimes think using lisp for a language is a little like trying to implement comments within json data.

Actually, I love Emacs for its Lisp! Yes, Emacs Lisp is not the best Lisp out there, however, IMHO, it's miles ahead of VimScript. If I were really to rewrite Emacs, I'd use some modern Scheme.

Then it wouldn't be Emacs. You're thinking of whatever, it could be a real nice picture in you head, whatever that you're thinking of, is not Emacs. Something like Emacs is not possible without Lisp.

And? GIMP is too, much faster to start than Photoshop, yet there are a number of things for which sometimes you just need the heavy cavalry.

I was doing some API testing today, I pressed a key, then a snippet expansion system added something like this into my notes:

      #+begin_src http 
      GET http://localhost:5003/api/health
      #+end_src

I realized that I needed a token. It is stored in an env var - not very secure, but it's okay - I'm not testing the prod endpoint. I just had to change the header into this:

    #+begin_src http :var token=(shell-command-to-string "echo $MY_TOKEN")
    GET http://localhost:5003/api/health
    Authorization: Bearer ${token}
    #+end_src
    

I've tested some more endpoints, got some unfamiliar http error codes, so I just typed directly in my notes "RFC 2616", Emacs was smart enough to recognize what that was and it opened the RFC document, where I searched for the error code, read about it, refreshing my knowledge.

Then I found the Jira ticket number in my yesterday's notes, copied over to my notes of today - Org-mode has a nice way of organizing daily notes in so-called date-trees. It's just a plain string - "TDL-26478", and once again, Emacs was smart enough to know what that was, I was able to read the description of the Jira ticket, without switching to the browser, without opening any pages, right there, from where I was composing my notes.

And this is all within less than an hour. I was able to send http requests, analyze results, study relevant RFC document, work with Jira, all that while taking extensive notes, without opening a single web-page, without typing a single command in the terminal, all that done inside Emacs. Emacs basically within less than an hour in a single window was able to substitute for me - a note taking app like Obsidian or Notion; API client like Postman; Interactive computing platform like Jupyter; Project management client for Jira; RFC documentation site; Web-browser and the Terminal app. So tell, me which one of any of these activities do you normally do in Neovim? And btw, this is not even remotely "esoteric" stuff I do in Emacs. This is just an ordinary Tuesday for me.

What advantage would you get by rewriting it in Rust?

Don't use Math. Normal people don't like it, it looks weird. I wonder how many projects failed because they wanted to use a lot of math notation. Normal people: Visits a project website. Sees it has equations and formulas. Closes page immediately.

That's how it sounds to me. Dismissing Lisp solely based on its syntax (that you're unfamiliar with), is equally irrational as rejecting projects that incorporate mathematical notation.

I am proudly not-normal, in that case.

Parentheses scare away anyone who shouts "bro!" and fist-bumps each other, before they can insist "the first thing Emacs needs is a package manager, to hide code as much as possible from casual users" (missing half the point of Emacs).

And how would that make emacs better?