Don't get me wrong, I'm not planning on creating an Emacs killer, nor suggest anyone do that. But, hypothetically, what are some fundamental pitfalls of this foundational application?
Almost all the comments here are about things that really possible to do in current Emacs i.e. 'feature-requests' and not "fundamental pitfalls of this foundational application". For me, it would be just:
- Redesigned with concurrency in mind.
- Common Lisp, Scheme, or anything else other than Elisp. [Just the same way Neovim adapted Lua instead of VimScript]
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.
There have been several recreations of Emacs in Common Lisp over the years, including Hemlock, CEDAR, and Climacs. They never catch on, because they’re not compatible enough with the existing base of emacs lisp software. This also applies to Scheme, although it did get closer to compatibility once or twice.
This is also closely tied to why emacs hasn’t been made much more parallelized - fundamentally, the design of emacs is too close to “a giant ball of global state”, mirroring an early Lisp Machine. It’s a high hill to design around, and it will violate basic assumptions made by most medium-plus interesting elisp code.
Do not let this dissuade you from trying! It would be a great if difficult accomplishment!
I enjoy using Lem sometimes, but mostly use Emacs. Lem is a very cool idea, and with Roswell it is easy to install and manage.
All that said, it seems like Emacs has been improving rapidly the last few years: native compilation of Elisp, LSP support, good integrations with LLMs.
More than org-mode, it needs a Texinfo viewer. Once you can access SBCL's documentation (and internal docs), now you have an almost complete Common Lisp editor with the basic features from Emacs.
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.
I’m on the strong opinion that most highly configurable software should come with strongly opinionated defaults. “It’s infinitely configurable so you can do anything you want” is just… so annoying. You could implement an LLM using punchcards if you were mad enough. The thing that makes a tool effective is the fact that it constrains and specializes.
I'm against that. Some random user would use Org-Mode and it wouldn't need any IDE related extensions. Also, another programmer might just use Org-Babel and code in Common Lisp with org-babel and a REPL doing literary programming. Another one would use Emacs for IRC, Email and math with M-x calc and/or iMaxima and AucTex.
I'd make cursors be positioned within the document instead of on the screen. Currently, Emacs does not support off-screen cursors. If you attempt to scroll a cursor off screen, it will move within the document to stay on screen. This behavior is contrary to all modern text editors, and there is no good workaround. I once made a serious effort to start using Emacs, but ultimately stopped because of the annoying cursor behavior. (There were other annoyances, but none so fundamental and unfixable.)
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.
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.
ncurses lets you move the cursor to arbitrary positions, and also lets you hide it. And you can disable echo, so you can type without the cursor having any influence on what you see. This means you can treat the terminal cursor as though it's a software-rendered cursor in a GUI app and apply all the same rules. But nobody considered doing this when Emacs was first written (maybe it wasn't possible then), so the assumption that the cursor is always on screen is difficult to change.
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.
> 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.
Iam pretty sure you can customzize that if you want.
> scroll-preserve-screen-position is a variable defined in ‘C source code’.
> Its value is ‘keep’
> Original value was nil
> Controls if scroll commands move point to keep its screen position unchanged.
> A value of nil means point does not keep its screen position except
> at the scroll margin or window boundary respectively.
> A value of t means point keeps its screen position if the scroll
> command moved it vertically out of the window, e.g. when scrolling
> by full screens. If point is within ‘next-screen-context-lines’ lines
> from the edges of the window, point will typically not keep its screen
> position when doing commands like ‘scroll-up-command’/‘scroll-down-command’
> and the like.
Conversely, I curse heavily at Mac programs where I can page down or scroll for a while, only to have an arrow press jump way the heck back in the document.
When you scroll away you can jump back by hitting anything on your keyboard. Also you can stay where you are, by clicking anywhere. It is a useful feature, that enables you to scroll to your heart's content.
The exact behavior isn't hugely important (although I think off-screen cursors are a useful feature). What matters is consistency between applications. There's no realistic scenario where I do everything in Emacs, so Emacs has to behave in the same way as other applications. If not, I risk data loss or corruption because I might fail to notice the cursor ending up somewhere I didn't expect. This is especially likely to happen with a feature like off-screen cursors that I use only occasionally.
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.
One thing about Emacs, is it's not really just an editor anymore. Comparing it to other editors kind of misses the mark. It's more like an integrated Lisp development and runtime environment. It reminds me of Smalltalk environments, say Squeak or Pharo, albeit in a very text oriented way.
The world could probably make room for an integrated Lisp development environment that makes GUI programming more of a first class citizen. Maybe something like Medley Interlisp?
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.
And so? Emacs GUI already does tons of things that don't work in terminal:
- It can render different fontsets
- PDFs
- SVG and images
- Emojis and file icons
- Tooltips
- Drag&Drop and better mouse support (scrolling, selection, etc.)
I think it would be great to have a better GUI layer and native web-browser integration. Emacs' evolution doesn't have to be constrained by terminal limitations, and so far it doesn't seem that it was.
I don't care that much about the implementation, but I would like to see an emacs environment with:
- 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.
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?
If you have better numbers and comparisons for emacs keypress-to-pixel latency, etc. I'd be interested.
Note classic vi started up faster than vim.
Device makes little to no difference: Raspberry Pi 5, MacBook Pro M1, ThinkPad P1, etc. - emacs is clunky on all of them. I like emacs and it's my daily driver. But it isn't fast.
Emacs pauses are almost always due to some operation blocking in the main thread. It's pretty annoying and is mostly a consequence to a lot of things effectively being single-threaded. Stock emacs doesn't do this very often, but third party packages that might do expensive tasks often do
Receiving output from a process, as is done for example by shell mode and (I guess, but have not verified) compilation mode, is slow in Emacs because all output is run through comint-carriage-motion and ansi-color-filter-region (which does nothing but throw color information away IIRC) which are written in Elisp.
If you don't run the output through those 2 functions, then non-printing characters remain in the output that severely undermine legibility.
C programmers tend to develop the ability to glean information from the voluminous output of build processes as it goes whizzing by on a terminal, so they find compilation mode frustratingly slow. Or at least that is my guess as to what happens.
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).
The solution to "this text editor takes too long to start up" is poorly addressed by the solution to "just leave it running in the background all the time".
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,
> - 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?
> Sandboxing is used when the host is concerned about running programs that he doesn't trust.
Trust? Trusting criminals doesn't stop them from committing crime.
You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme.
You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.
Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?
Well, Emacs does ship with a browser (because of course it does, that kind of thing is what makes Emacs so amazing) and we all remember the XZ Utils near-backdoor, so I think that security measures would be useful for people who decide to use a less trustworthy archive like MELPA or who install extensions with package-vc.
A lot emacs usage today consists of running programs you shouldn't trust. And the rest of it is hard because you are either reviewing other people's libraries a lot, or simply not using other people's libraries, or updating infrequently.
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.
Scheme is smaller, has more static and less interactive philosophy. CL has most things you need straight out of the box. It's more like operating system than programming language. Exactly what Emacs wants to be.
elisp is more like CL than it is like Scheme; RMS was aware of CL when he was working on emacs, but was suspicious of some of its new features (like lexical binding).
> If you were rewriting Emacs from scratch, what would you do differently?
UI: Electron, of course.
Json to represent the edit buffer in RAM. Each utf8 code point base64 encoded, in a json array, it itself, as a blob, base64 encoded. Now, before you complain that that is gonna blow up the data too much, don’t forget that 1. “Ram is cheap” and 2. “gzipped base64 is about the same size as binary”. So, of course, we’ll gzip the data in RAM.
Plugins should be JavaScript, as should be self-evident. And you’ll need a few installations of python (both 2 and 3) and node.js (each in its own docker container, obviously) to glue it all together and provide reproduceability.
With some care and work, it’ll run even on a modest machine taking up merely 60GB of disk, 32GB of RAM, a 4090ti GPU, and 8 CPU cores.
Every key press should be passed through an LLM, to add some intelligence to the editor. The user will, of course, supply a ChatGPT api key when they register for their mandatory myNewEmacs.ai account that they’ll need to subscribe to the editor for only the cost of a few lattes a month.
It is 2024, after all. One must use modern tools and technologies.
Support prettier typography (if the user is not interacting with Emacs through a terminal, in which case of course the typography is up to the terminal-emulation app). If text in Emacs looked as pretty as text on the web does, it would be less of a struggle for me to stay focused on the Emacs text. (Text on the web was already much above average in pleasantness to look at and to read in the 1990s.)
Get rid of any keybinding or UI convention that is there because that is the way they did it the AI Lab in 1967. Make the UI as familiar to the average computer user as possible (but keep the general design of a large rectangle of text) by using mainstream conventions (which come mainly from the Mac and Windows) for how to respond to this or that keypress or to clicking or dragging with this or that mouse button.
Inside Emacs is a cross-platform toolkit (where the platforms are MacOS, other Unix derivatives, Windows and the terminal) I would split Emacs into 2 projects: a toolkit and an app that uses the toolkit. That way, if someone wants to create an "standalone" org-mode app, Magit app or Gemini browser designed to appeal to people who do not want to spend any time learning to use Emacs the app or "Emacs the generalized interface to information", they have a straightforward way to do so. (These "standalone" apps that are as easy to learn as any other GUI app will I hope help popularize the Emacs ecosystem.)
One thing I definitely would not change is I would not make Emacs dependent on or closely integrated with a browser engine.
> 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}).
Most of the text on the web for example is in a proportional-pitch typeface.
Does your Emacs usually use a proportional-pitch typeface? If so and you're on Linux, I'll install the font you are using.
I've tried using proportional typefaces in Emacs (on Mac), but there was something off, so I went back to monospaced. I could try again now that I have a Linux machine.
The text in my Emacs looks almost exactly like the text in my Gnome Terminal. (A slight difference in size is the only thing I notice. To be painfully precise, (window-system) evals to 'pgtk on my Emacs.)
The text in Gnome Terminal is not terrible, for sure, but text on the web is a nicer in my experience.
Instead of using ctrl and meta modifiers, use a leader key like escape or semicolon or comma or some such thing as the prefix key for key bindings. In fact, this desire for leader-key-based, non-modal text editing led me to write devil-mode for Emacs: <https://susam.github.io/devil/>.
I know many people like to remap Caps Lock to function as Ctrl. However that setup does not quite work for me. There is only one Caps Lock key on the left side of the keyboard. I need Ctrl on both sides of the keyboard, so that I can use the left Ctrl key while typing Ctrl+P but the right one while typing Ctrl+A.
There are other options as well, like remapping the Enter key to act as Ctrl when chorded or using sticky modifiers. I think using an ergonomic keyboard with two large Ctrl keys on both sides of the keyboard is probably the best solution. I've discussed some of these alternatives in more detail <https://susam.github.io/devil/#why>.
Instead of making it an additional Ctrl key, you can also make it a new separate modifier key with XKB[1]. I've found this very useful over the years for WM-related key bindings, leaving the other modifiers for applications.
Tangentially, I really loathe how Wayland has no alternative to this. I'm expected to configure keyboard layouts in every DE or WM I use, which is a much worse UX.
I was very disappointed that Apple gave up that fight.
They also at some point joined the PC world in moving the nubs on their keyboard from "d" and "k", where you were more likely to notice if your fingers are not in their proper place on the home row. Now if your right hand is offset slightly to the right, you won't feel anything, which is less immediately noticeable than if the nub were under the wrong finger.
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.
Readit News
- Redesigned with concurrency in mind.
- Common Lisp, Scheme, or anything else other than Elisp. [Just the same way Neovim adapted Lua instead of VimScript]
- More sane defaults for new users.
[0] : https://github.com/lem-project/lem
All that said, it seems like Emacs has been improving rapidly the last few years: native compilation of Elisp, LSP support, good integrations with LLMs.
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.
“To run the tutorial, start Emacs and type C-h t, that is, Ctrl-h followed by t.”[1]
[1] https://www.gnu.org/software/emacs/tour/
Isn't that cua-mode?
https://www.gnu.org/software/emacs/manual/html_node/emacs/CU...
> would be pretty fully configured and pre-loaded with the most common extensions/plug-ins/etc.
Doesn't it already do this? org-mode comes pre-installed for instance.
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.
Deleted Comment
Markers are used to mark a different point in the file and one can pop their location to a previous mark.
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.
Iam pretty sure you can customzize that if you want.
> scroll-preserve-screen-position is a variable defined in ‘C source code’.
> Its value is ‘keep’ > Original value was nil
> Controls if scroll commands move point to keep its screen position unchanged.
> A value of nil means point does not keep its screen position except > at the scroll margin or window boundary respectively.
> A value of t means point keeps its screen position if the scroll > command moved it vertically out of the window, e.g. when scrolling > by full screens. If point is within ‘next-screen-context-lines’ lines > from the edges of the window, point will typically not keep its screen > position when doing commands like ‘scroll-up-command’/‘scroll-down-command’ > and the like.
The world could probably make room for an integrated Lisp development environment that makes GUI programming more of a first class citizen. Maybe something like Medley Interlisp?
- It can render different fontsets
- PDFs
- SVG and images
- Emojis and file icons
- Tooltips
- Drag&Drop and better mouse support (scrolling, selection, etc.)
I think it would be great to have a better GUI layer and native web-browser integration. Emacs' evolution doesn't have to be constrained by terminal limitations, and so far it doesn't seem that it was.
- 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.
What kind of HW are you running emacs on where this isn't the case?
https://pavelfatin.com/typing-with-pleasure/
If you have better numbers and comparisons for emacs keypress-to-pixel latency, etc. I'd be interested.
Note classic vi started up faster than vim.
Device makes little to no difference: Raspberry Pi 5, MacBook Pro M1, ThinkPad P1, etc. - emacs is clunky on all of them. I like emacs and it's my daily driver. But it isn't fast.
see also:
"Computer latency: 1997-2017" https://danluu.com/input-lag/
"Measuring keyboard-to-photon latency with a light sensor" https://thume.ca/2020/05/20/making-a-latency-tester/
If you don't run the output through those 2 functions, then non-printing characters remain in the output that severely undermine legibility.
C programmers tend to develop the ability to glean information from the voluminous output of build processes as it goes whizzing by on a terminal, so they find compilation mode frustratingly slow. Or at least that is my guess as to what happens.
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
- Design a more modular architecture to make it easier to extend and maintain different components.
- Design a more robust plugin system for development and distribution of extensions.
- Implement better sandboxing and security measures for extensions.
- Better APIs for extension developers.
- better multi-threading support baked into the editor.
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?
Trust? Trusting criminals doesn't stop them from committing crime.
You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme.
You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.
Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?
[0] : https://github.com/lem-project/lem
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
UI: Electron, of course.
Json to represent the edit buffer in RAM. Each utf8 code point base64 encoded, in a json array, it itself, as a blob, base64 encoded. Now, before you complain that that is gonna blow up the data too much, don’t forget that 1. “Ram is cheap” and 2. “gzipped base64 is about the same size as binary”. So, of course, we’ll gzip the data in RAM.
Plugins should be JavaScript, as should be self-evident. And you’ll need a few installations of python (both 2 and 3) and node.js (each in its own docker container, obviously) to glue it all together and provide reproduceability.
With some care and work, it’ll run even on a modest machine taking up merely 60GB of disk, 32GB of RAM, a 4090ti GPU, and 8 CPU cores.
Every key press should be passed through an LLM, to add some intelligence to the editor. The user will, of course, supply a ChatGPT api key when they register for their mandatory myNewEmacs.ai account that they’ll need to subscribe to the editor for only the cost of a few lattes a month.
It is 2024, after all. One must use modern tools and technologies.
Get rid of any keybinding or UI convention that is there because that is the way they did it the AI Lab in 1967. Make the UI as familiar to the average computer user as possible (but keep the general design of a large rectangle of text) by using mainstream conventions (which come mainly from the Mac and Windows) for how to respond to this or that keypress or to clicking or dragging with this or that mouse button.
Inside Emacs is a cross-platform toolkit (where the platforms are MacOS, other Unix derivatives, Windows and the terminal) I would split Emacs into 2 projects: a toolkit and an app that uses the toolkit. That way, if someone wants to create an "standalone" org-mode app, Magit app or Gemini browser designed to appeal to people who do not want to spend any time learning to use Emacs the app or "Emacs the generalized interface to information", they have a straightforward way to do so. (These "standalone" apps that are as easy to learn as any other GUI app will I hope help popularize the Emacs ecosystem.)
One thing I definitely would not change is I would not make Emacs dependent on or closely integrated with a browser engine.
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}).
Does your Emacs usually use a proportional-pitch typeface? If so and you're on Linux, I'll install the font you are using.
I've tried using proportional typefaces in Emacs (on Mac), but there was something off, so I went back to monospaced. I could try again now that I have a Linux machine.
The text in my Emacs looks almost exactly like the text in my Gnome Terminal. (A slight difference in size is the only thing I notice. To be painfully precise, (window-system) evals to 'pgtk on my Emacs.)
The text in Gnome Terminal is not terrible, for sure, but text on the web is a nicer in my experience.
[1] https://en.m.wikipedia.org/wiki/Caps_Lock#Placement
There are other options as well, like remapping the Enter key to act as Ctrl when chorded or using sticky modifiers. I think using an ergonomic keyboard with two large Ctrl keys on both sides of the keyboard is probably the best solution. I've discussed some of these alternatives in more detail <https://susam.github.io/devil/#why>.
By the way, there are some vendors that still make Unix layout keyboards with the Ctrl key positioned where Caps Lock key usually is: <https://deskthority.net/wiki/Category:Keyboards_with_Unix_la...>.
Tangentially, I really loathe how Wayland has no alternative to this. I'm expected to configure keyboard layouts in every DE or WM I use, which is a much worse UX.
[1]: https://vincent.bernat.ch/en/extending-xkb#attaching-symbols...
Deleted Comment
They also at some point joined the PC world in moving the nubs on their keyboard from "d" and "k", where you were more likely to notice if your fingers are not in their proper place on the home row. Now if your right hand is offset slightly to the right, you won't feel anything, which is less immediately noticeable than if the nub were under the wrong finger.
Caps lock was rightfully relegated to bottom left.
That's indeed true! But the premise of this question explores the scenario: What if we did rewrite Emacs from scratch?