Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs Is a Lispboard

en.andros.dev

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Emacs Is a Lispboard

#31

Post by anthk »

adrian_b wrote: post #7
xvilka wrote: post #3

Something like Lem[1][2] could go even further because of the richer CommonLisp ecosystem compared to Elisp one. [1] https://lem-project.github.io/ [2] https://github.com/lem-project/lem

Having CommonLisp as the extension language would indeed be a great improvement over Elisp. However, I am suspicious about the dependency of Lem on Webkit, which for me is rather associated with inefficiency and low performance than with the instant reactions that I expect from programming text editors, terminal emulators and tiled window managers. The main problem is that it is very difficult for any replacement of…

Emacs has cl-lib and most CL users can get into Emacs in seconds (if they are not already proficient enough, most of them btw).

Re: Emacs Is a Lispboard

#32

Post by BeetleB »

conartist6 wrote: post #30
BeetleB wrote: post #27

Earlier quoted context omitted.

Because to replicate the power of Emacs, you'd need to throw away a lot of privacy/security in the browser. You'd need to let one tab read the contents of another by default . A change to make your mail reading better may break your banking app (yes, that's a reality with Emacs). Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window. Finally, most browsers don't l…

If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be. The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. The customizability in both cases is really coming from an "OS" being implemented in user-controlled scriptspace. You'd have just as much ability t…

> If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be.

I can interpret your original query two ways:

1. Why can't we replicate Emacs like power in the browser?

2. Why can't we replicate Emacs like power in the browser using existing web sites as apps?

I was answering 2 above. If your mail application is Gmail, then non Google tabs can't read your emails and vice versa.

If you meant it from the perspective of 1, then you can get much further. You'd have to write a generic mail app in JS that can connect via IMAP, etc.

The other headache you'll have to deal with is not having easy access to the disk. Can you easily implement a file manager in JS and run it from the browser? Or access the processes on your computer (e.g. say you want to write a "top" tool for the browser)?

Essentially, the Emacs ecosystem has lots and lots of useful Elisp packages written over the decades. The browser doesn't. And the ones that exist are self contained (i.e. you don't find a JS TODO app that is meant to integrate with someone else's JS Mail app).

And browsers don't have an easy way to install a JS app. How would you do it? Bookmarklet?

As for customizing the browser via JS - yes, you're technically correct. The difference is that much of Emacs is designed to be modifiable via Elisp, whereas that's not the case in most browsers.

So to answer your question, it is technically feasible. You just need a better browser and a lot more people writing client side JS apps.

Re: Emacs Is a Lispboard

#33

Post by taeric »

getpokedagain wrote: post #19
tonyarkles wrote: post #17

Earlier quoted context omitted.

> The JS ecosystem is not that old I hate to tell ya this... LiveScript was renamed to JavaScript in 1995, and the first ECMAScript standard was published in 1997. So not 40 years old, but 31 years old. NodeJS (liberating JavaScript from the browser) was first released in 2009... so again, not 40 years old, but old enough to have a drivers license. I agree with you on the other side though: despite the language being…

I think I need to update my sales pitch for the passage of time. Emacs is probably closer to 50 now.

Also notable that the way changes are introduced to the different languages is so different that this is just hard to really look at. Notably, elisp of today is not dramatically different from elisp of 20 years ago. JavaScript? Basically a brand new language after ES6+.

Re: Emacs Is a Lispboard

#34

Post by throwaway27448 »

conartist6 wrote: post #8
xvilka wrote: post #3

Something like Lem[1][2] could go even further because of the richer CommonLisp ecosystem compared to Elisp one. [1] https://lem-project.github.io/ [2] https://github.com/lem-project/lem

I chose the JS ecosystem. Why does the power of Emacs not belong in the browser? These days JS is a powerful enough FP language to do it.

No, the power of the browser belongs in emacs. You're composing the wrong direction!

Anyway aren't you just describing vscode?

Re: Emacs Is a Lispboard

#35

Post by crabbone »

conartist6 wrote: post #30
BeetleB wrote: post #27

Earlier quoted context omitted.

Because to replicate the power of Emacs, you'd need to throw away a lot of privacy/security in the browser. You'd need to let one tab read the contents of another by default . A change to make your mail reading better may break your banking app (yes, that's a reality with Emacs). Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window. Finally, most browsers don't l…

If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be. The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. The customizability in both cases is really coming from an "OS" being implemented in user-controlled scriptspace. You'd have just as much ability t…

> The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code.

You misunderstood the problem. Remember when Firefox' GUI was made of XUL and that was indeed accessible from JavaScript (before they abandoned add-ons in favor of Google's extensions). Then you had add-ons like Firebug or KeySnail that could indeed take control of the browser's "chrome" (i.e. the visual elements that don't belong to the HTML page, s.a. tabs, menus, address bar, buttons around it).

If you don't remember... life was a lot better back then. I've built a tool for interactively highlighting selected DOM elements in the page from a dedicated toolbar for example (this was before the developer tools). You could completely remap all browser keys. You could call external editor to edit the text in text areas or text inputs. You could call programs on the local filesystem (there used to be an FTP add-on that did that).

Re: Emacs Is a Lispboard

#36

Post by conartist6 »

BeetleB wrote: post #32
conartist6 wrote: post #30

Earlier quoted context omitted.

If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be. The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. The customizability in both cases is really coming from an "OS" being implemented in user-controlled scriptspace. You'd have just as much ability t…

> If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be. I can interpret your original query two ways: 1. Why can't we replicate Emacs like power in the browser? 2. Why can't we replicate Emacs like power in the browser using existing web sites as apps ? I was answering 2 above. If your mail application is Gmail, th…

Ah, yeah, I was answering 1.

Access to disk is... not great, I agree, but I'm not terribly worried about it. My plan is to eliminate the checked out file tree and plug the version control straight into the core data structure of the editor. I just hash the nodes of the underlying concrete syntax tree, which is my Emacs-y homoiconic data structure.

The downside is that the ecosystem for this product starts out empty. It's a whole new set of protocols, data structures, and APIs. Even so, the JS ecosystem does contain quite a lot of code that I think will be of value

Re: Emacs Is a Lispboard

#37

Post by conartist6 »

crabbone wrote: post #35
conartist6 wrote: post #30

Earlier quoted context omitted.

If I have two editor tabs open as two browser tabs they should already be able to talk if they're from the same origin, which different editor tabs would be. The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. The customizability in both cases is really coming from an "OS" being implemented in user-controlled scriptspace. You'd have just as much ability t…

> The JS code won't be able to modify the browser itself, but neither can ELisp modify the actual Emacs binary code. You misunderstood the problem. Remember when Firefox' GUI was made of XUL and that was indeed accessible from JavaScript (before they abandoned add-ons in favor of Google's extensions). Then you had add-ons like Firebug or KeySnail that could indeed take control of the browser's "chrome" (i.e. the visu…

Wait, so what is the problem? For me the biggest problem is that CSRF makes it unnecessarily difficult to write a "browser within a browser", which would otherwise not be all that hard

Re: Emacs Is a Lispboard

#38

Post by conartist6 »

taeric wrote: post #33
getpokedagain wrote: post #19

Earlier quoted context omitted.

I think I need to update my sales pitch for the passage of time. Emacs is probably closer to 50 now.

Also notable that the way changes are introduced to the different languages is so different that this is just hard to really look at. Notably, elisp of today is not dramatically different from elisp of 20 years ago. JavaScript? Basically a brand new language after ES6+.

ES6 was released 16 years ago. I'm building on top of ES6 like it's rock solid, and so far I haven't been disappointed. After ES6 the langdev process changed materially, and it now rewards introducing language features that are, in my view, half-baked. I have had to take over parts of the work of the standards committee to be able to do this project at all.

I had to reinvent iteration to get both perf and abstraction at the same time: https://docs.bablr.org/architecture/spacetime

I also had to create records and deep freezing: https://es.discourse.group/t/proposal-records-a-new-one/2546...

Re: Emacs Is a Lispboard

#39

Post by taeric »

conartist6 wrote: post #38
taeric wrote: post #33

Earlier quoted context omitted.

Also notable that the way changes are introduced to the different languages is so different that this is just hard to really look at. Notably, elisp of today is not dramatically different from elisp of 20 years ago. JavaScript? Basically a brand new language after ES6+.

ES6 was released 16 years ago. I'm building on top of ES6 like it's rock solid, and so far I haven't been disappointed. After ES6 the langdev process changed materially, and it now rewards introducing language features that are, in my view, half-baked. I have had to take over parts of the work of the standards committee to be able to do this project at all. I had to reinvent iteration to get both perf and abstraction…

Right, but that about halves the age of JavaScript as noted in this thread.

I fully agree that it is reaching a more stable place now than it was 5 or 10 years ago. It is still nowhere near as old as elisp.

Post reply on HN