Emacs support of non-fixed width fonts is also pretty bad. My language Urdu is basically impossible to write on Emacs - or at least it was 5 years ago when I struggled with it a lot.

The HarfBuzz font engine should help.

What trouble were you having with specifically?

Clarification: HarfBuzz is available in Emacs as of the recent 27.1 release.

As a masochist who prefers a variable-pitch default font in Emacs,

  (defun fixed-pitch-mode (&optional arg)
    (interactive (list (or current-prefix-arg 'toggle)))
    (buffer-face-mode-invoke 'fixed-pitch (or arg t) nil))

is a handy "escape hatch", usable as both a key binding and a major mode hook.

You should give it another try. My native script is also hard to render as fixed-width. But the latest Emacs seems to be doing well.

Some time in the late '90s a friend and i sat down and tried to design a UI framework that could cover lots of styles. We started with GUI and line-mode terminal, but hoped to add curses and the web (1.0 of course, so using forms, not JavaScript). I didn't know about block-mode terminals at the time.

GUIs and line-mode terminals are radically different, so you have to think of a language of UI primitives that are high-level enough to have a natural implementation in each style.

This is hard! For starters, a GUI is inherently spatial, whereas a command line is more temporal. If you want to specify a sandwich, say, then in a GUI, you might have three select boxes next to each other for the bread, filling, and dressing, and a submit button, whereas on a command line, you need to prompt three times, and perhaps offer options for going back and changing the selection. Or offer internal commands for viewing the lists and making a selection, for a more shell-like interface.

From what i remember, our API ended up looking a lot like web forms - the application presents a series of questions, each with a prompt and a structure for the answer (free text, select one from a list, etc). The GUI implementation then put together a (very ugly) GUI with a elements for each question, the command line implementation asked each question in turn.

We never got as far as trying to display rich information. That could have been a whole different set of problems.

I've seen line-mode apps before provide fill-in forms by giving each field a number, and then you type in the number of the field you want to edit, and then you type in a new value. You want to supply an option to redisplay the whole form on demand. (For an actual hardcopy terminal, you only want to redisplay the whole form when asked, to avoid wasting paper and print time; for a softcopy terminal in line-mode, you can redisplay the whole form much more often.)

Interesting ... has anybody tried a browser based (which is what I presume you mean by HTML) front end for emacs?

EDIT - just to be clear, I'm talking about emacsclient, talking to a emacs server. Not an actual full blown emacs implementation that's just stupid.

I meant old-school pure HTML forms, not a HTML5 app with JavaScript+Canvas (or even wasm+Canvas). With the later, you could in principle compile GNU Emacs to JavaScript or wasm, using e.g. emscripten. (I don't know if anyone has succeeded in that yet, but I think it would be in principle achievable.)

Old-school pure HTML forms actually has a lot conceptually in common with block mode terminals such as IBM 3270. The server sends the client a fill-in-form, the user fills it in, the client sends it back to the server in one block. Most of the logic exists on the server (although some basic very basic validations may execute on the client). So, I was actually talking about serving up a classic pure HTML form app over HTTP as a UI style.

No, I am specifically not talking about this. I'm actually not sure at this point what you mean - I have a vision of somebody communicating with an emacs backend via forms?

I'm just talking about a thin client, such as you typically use when you have emacs running as a server. You only have to manage text and windowing, and capturing user commands and communicating with the back end. These are the kind of things browsers are good at.

Well, think of a 3270 editor, such as ISPF EDIT on MVS or XEDIT on VM/CMS. Now imagine using that editor through a 3270-to-HTML gateway. That's what I was really talking about. But, you could actually implement a similar style of interaction in pure HTML, without the 3270 layer. Indeed, a lot of classic server-side web apps, even if they weren't text editors, worked with that UI style.

Of course, Emacs doesn't support 3270. But that was my point – that there are UI styles which Emacs doesn't support. They might not be useful UI styles, especially in 2020. But historically they were important, and any suggestion that Emacs is some kind of magic which supports all UI styles isn't really true, although maybe it supports all contemporarily practically relevant UI styles.

Cloudmacs basically puts tty emacs in your browser:

https://github.com/karlicoss/cloudmacs

I've ran emacs in cocalc's terminal emulator in the browser, non-ironically doing real work.

It works pretty well.

With the new Chrome filesystem API it should be possible to make a full browser implementation.

Let's just hope they don't have annoying GDPR and other popups when you're trying to edit a file.

There must be someone working on Emacs in Electron as we speak. I found some gist that's 2 years old: https://gist.github.com/chrisdone/f874ac1c872c004d6ce9e3cb20...

You shouldn't even have to need filesystem API if you're just using it as an emacs client connecting to an emacs server.

Your remark about GDPR is kind of strange ... not sure what that would have to do with anything ... GDPR applies to people and organisations, not their tools.

The requirement to advertise "we use cookies" and spam you with popups when you visit a site is frustrating for highly technical users.

OP is saying that Emacs-as-website would be frustrating if it had those popups.

You don’t have to do that unless you’re hosting a public site ... and even so if it’s a private session and you’d logged in this wouldn’t be required. Logging in is seen as a tacit acknowledgment that you consent to being tracked, cause how would I have. A personal session otherwise.

The cookies warning is all about notifying the casual reader who might otherwise believe they were passively browsing static content.

> Logging in is seen as a tacit acknowledgment that you consent to being tracked

Logging in means you get a single cookie (a login/session cookie), that cookie is necessary and thus a functional cookie that you can't say no to. All other cookies (and basically every form of tracking) still isn't allowed without consent.

Some people really hate GDPR. It has crushed the AdTech industry in Europe - I'm not sad about that but I do hope those people found other employment fast.

There was a thriving industry harvesting and processing personal details about people. I think if the true extent of it were known most people would warmly embrace GDPR. But some people have lost a lot of money and they are pissed, but again I kind of feel there is a lot unscrupulousness involved so it's hard to feel sympathy.

To a lesser extent, there are people that are concerned about "all the extra work" this entails, and the cost it adds to their bottom line. But this stuff is important nowadays. You really should be taking care of it.

There is some scaremongering about small firms being blown out of the water for noncompliance, but really, unless you're doing something you shouldn't be doing you should be fine. The terms of GDPR though still not completely clearly specified are flexible and reasonable. The main thing is now, that you can't say you weren't aware of it.

Let's hope the filesystem API does require user permission and that anyone building such a service follows the law.

You know that GDPR doesn't require pop ups unless the service is doing something that isn't otherwise lawful?