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.
Pardon me if you're ahead of me on this, but it sounds like you might be using a proportional typeface as the default or fixed-pitch face. You should get nice-looking proportional type if you set the variable-pitch face to your desired typeface and enter variable-pitch-mode in the buffer. E.g.,
I use IBM Plex Sans (proportional) as my default Emacs font, with variable-pitch as a no-op (i.e., defined as "(variable-pitch ((t nil)))" in custom.el), and use IBM Plex Mono as fixed-pitch.
Tips for using a variable pitch font as the default:
0. Choose default fixed and variable pitch fonts with identical baseline-to-baseline heights for a given size; this makes everything described below work better (e.g., this is true for all fonts in the IBM Plex family across all platforms I regularly run GUI Emacs on [Linux, Mac, Windows]).
1. Define a fixed-pitch-mode by copy-pasting the built-in variable-pitch-mode and making the obvious changes (both are trivial applications of buffer-face-mode).
2. Add fixed-pitch-mode to hooks for modes that don't play nicely with variable-pitch fonts (calc, dired, hexl, magit, terminal and shell modes, etc.), or where you just prefer fixed-pitch modes (hint: define your fixed-pitch-mode in a package so you can use use-package's ":hook ((foo-mode bar-mode … baz-mode) . function)" syntax to manage this).
3. Some modes that pop up windows (frames in Emacs parlance) within editing buffers require extensions (e.g., company-posframe-mode for company-mode) to work properly in variable pitch buffers.
4. Last, but certainly not least: assign a convenient key binding to toggle fixed-pitch-mode. I can't emphasize this enough! In fact, I've found that variable pitch is fantastic for coding in most languages if and only if fixed pitch can be quickly toggled on and off with a keystroke, iff this setting is per file rather than global (and iff both fonts have identical line heights, but this is a feature of font families rather than editors).
For this reason alone, I'd argue that Emacs supports variable pitch fonts better than most text editors.
I use IBM Plex across the board and I was trying to understand the font issue because I do not have it. I default to fixed-pitch mode for everything, and use variable pitch for UI elements.
Thanks for the info, but the result of that is not any better than the result of what I had already done. (I wrote a command that put an overlay on the buffer to change the typeface.)
It's not as good text on the web IMHO. Typography is very complicated, and I think the people who did the typographical details of Chrome and Firefox were very skilled, is my guess.
I used to use proportional pitch fonts for telega.el and certain document buffers, but I stopped because I find that with Jetbrains Mono (for me personally) there isn't any benefit even for longer text. I'd rather have everything be uniform.
Emacs is perfectly capable of rendering other fonts, too, though.
I have never tried but I assume you can do as well as a browser. But I would never use VSCode for writing generic notes. There is so much distracting mess in it.
I did setup Obsidian for a friend to write in Urdu, and that worked almost perfectly modulo some minor stuff.
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.