Emacs Is a Lispboard(en.andros.dev)
en.andros.dev
Emacs Is a Lispboard
https://en.andros.dev/blog/06bfd107/emacs-is-a-lispboard/
7 comments
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
[1] https://lem-project.github.io/
[2] https://github.com/lem-project/lem
What do you mean by "richer ecosystem"? Have you ever seen GitHub language stats - there's so much Elisp on GitHub alone, it's absolute bananas. The amount of Elisp in the wild probably surpasses the amount of Clojure, CL and Racket combined. And mind that it isn't "a general use" PL - it exists for one and single purpose.
Lem is great and I'm happy there's finally something out there to challenge Emacs' hegemony, yet pragmatically, unless someone builds a way to run Elisp in Lem, it's unlikely to overthrow Emacs anytime soon, and that's just not gonna happen.
Org-mode, Magit, and thousands of packages aren't just "Elisp code" - they depend on Emacs' specific buffer model, text properties, overlays, markers, the display engine, process handling, and countless quirks packages rely on (intentionally or not). A Lem Elisp interpreter that didn't also reimplement all of that faithfully would run trivial `.el` files and choke on anything real. At that point you've reimplemented Emacs inside Lem.
Elisp is not the biggest point here and Neovim proves that with pivoting to Lua; the crux is the runtime and the corpus, and reimplementing those is the actual mountain. That is real ecosystem for whatever reason you're choosing to simply ignore.
Lem is great and I'm happy there's finally something out there to challenge Emacs' hegemony, yet pragmatically, unless someone builds a way to run Elisp in Lem, it's unlikely to overthrow Emacs anytime soon, and that's just not gonna happen.
Org-mode, Magit, and thousands of packages aren't just "Elisp code" - they depend on Emacs' specific buffer model, text properties, overlays, markers, the display engine, process handling, and countless quirks packages rely on (intentionally or not). A Lem Elisp interpreter that didn't also reimplement all of that faithfully would run trivial `.el` files and choke on anything real. At that point you've reimplemented Emacs inside Lem.
Elisp is not the biggest point here and Neovim proves that with pivoting to Lua; the crux is the runtime and the corpus, and reimplementing those is the actual mountain. That is real ecosystem for whatever reason you're choosing to simply ignore.
Lem already has a clone of legit. And there's org-mode-alikes, as well.
There's very little I miss when I use lem, TBH.
There's very little I miss when I use lem, TBH.
That's plausible and isn't too hard to imagine. The value of Emacs is not the concrete implementation of it - let's be honest, GNU Emacs is not void of enormously annoying warts. The value of Emacs is the nice foundational Lisp layer - something Lem does provide.
One side of me wants to remain skeptical - knowing how much stuff there exists in Org-mode and Magit - piles and piles of different workflows thousands of users had to go through over the years - a bunch of well-trodden paths.
At the same time, I am well-acquainted with the power of Lisp and its communities. Give Lispers a powerful engine, and they'd take it to the moon and beyond. Lem's been steadily developing over the past few years and slowly been adding users, at least I keep hearing of curious people trying it. Meanwhile Org-mode's core feels almost stagnant, and it's one of the "killer apps" of Emacs. Lem might be on the brink of making things so appealing that it would be hard to refuse it. For some lispers that's already the case. I'm wholeheartedly welcome this challenge to Emacs' hegemony. I love Emacs and I hate Emacs, because sadly (or otherwise) I don't see any practical alternative for it - anyone who thinks nvim or vscode are even in the same room are clueless. Perhaps, the time to seriously consider Lem is almost (?), already (?) here.
One side of me wants to remain skeptical - knowing how much stuff there exists in Org-mode and Magit - piles and piles of different workflows thousands of users had to go through over the years - a bunch of well-trodden paths.
At the same time, I am well-acquainted with the power of Lisp and its communities. Give Lispers a powerful engine, and they'd take it to the moon and beyond. Lem's been steadily developing over the past few years and slowly been adding users, at least I keep hearing of curious people trying it. Meanwhile Org-mode's core feels almost stagnant, and it's one of the "killer apps" of Emacs. Lem might be on the brink of making things so appealing that it would be hard to refuse it. For some lispers that's already the case. I'm wholeheartedly welcome this challenge to Emacs' hegemony. I love Emacs and I hate Emacs, because sadly (or otherwise) I don't see any practical alternative for it - anyone who thinks nvim or vscode are even in the same room are clueless. Perhaps, the time to seriously consider Lem is almost (?), already (?) here.
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 to offer everything that already exists for Emacs.
In my opinion, the only way in which such a replacement would succeed would be if it would include an automatic translator from Elisp to CommonLisp scripts executable by it, with equivalent functionality.
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 to offer everything that already exists for Emacs.
In my opinion, the only way in which such a replacement would succeed would be if it would include an automatic translator from Elisp to CommonLisp scripts executable by it, with equivalent functionality.
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).
Lem can also render via ncurses, which works fairly fine if you don't need mouse support. It used to also have an SDL2 frontend, but it was deprecated for reasons I don't remember
The WebKit UI is actually snappier and more performant than the previous SDL2 one.
I don't think WebKit is slow at all. Browser bloat around it often is.
I don't think WebKit is slow at all. Browser bloat around it often is.
I am not sure if I would bet one way or another on who has the richer ecosystem here.. They are both great. I would probably wager elpa has more packages in general than quicklisp, but maybe not necessarily richer/higher quality.
"Common Lisp Emacs" has been attempted a few times. Lem seems like the best effort yet, and I was really excited about it until they decided to adopt a webview renderer.
I've got vscode for that.
I've got vscode for that.
It supports ncurses too. And if someone else wanted to maintain the SDL2 version or such, they'd be happy. The issue's just a lack of engineering effort and more people complaining than assisting. :/
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.
Because you need Lisp. That's the actual "power of Emacs". Emacs is a Lisp-interpreter with a built-in text editor. Everything stems from that. Anyone challenging "the choice" of Lisp as the configuration language for an editor, saying things like: "Why? If X is better - faster, more modern, more popular...", etc., have misunderstanding of what makes Lisp so uniquely powerful.
A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.
Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.
A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.
Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.
> to implement anything similar to Emacs, you'd need a homoiconic language
I've got that. It took 6 years but I developed a comprehensive homoiconic layer for Javascript
I've got that. It took 6 years but I developed a comprehensive homoiconic layer for Javascript
How does that work? Homoiconicity is a property of the language, not something you can develop as a layer.
JS was already pretty close. Babel allows a fantastic degree of power in code transformation, it just doesn't preserve blank space.
If I were to use my preferred terminology I would simply call these transform-your-own-code formats "embeddings", and there can be many embeddings for a single language.
If I were to use my preferred terminology I would simply call these transform-your-own-code formats "embeddings", and there can be many embeddings for a single language.
> Babel allows a fantastic degree of power in code transformation
That's still not homoiconicity. It reminds me old Stuart Sierra's presentation from Clojure/conj¹. Around 6 minute mark: "Adding eval to a language, even successfully, does not count as homoiconicity"... "and you didn't even succeed at that..."
---
¹ https://www.youtube.com/watch?v=o7zyGMcav3c
That's still not homoiconicity. It reminds me old Stuart Sierra's presentation from Clojure/conj¹. Around 6 minute mark: "Adding eval to a language, even successfully, does not count as homoiconicity"... "and you didn't even succeed at that..."
---
¹ https://www.youtube.com/watch?v=o7zyGMcav3c
I'm sorry, but that's not homoiconicity. I'm not trying to devalue your work (if you're talking about BABLR/CSTML), but you really cannot bolt homoiconicity onto a non-homoiconic language with a layer, because the defining trait is the absence of a layer.
It doesn't look like your real goal was homoiconicity at all, but rather "stay in JS semantics, keep the JS ecosystem, and build structural editing over any language". Homoiconicity is a word you grabbed to borrow from Emacs's fame, but not a requirement you're were ever trying to satisfy. If it was the actual requirement, there are dozens of options that exist already - Squint, cherry, Clojurescript, Scittle, Fennel-to-JS, even Gleam - any of them gives you code-as-data cheaply.
It doesn't look like your real goal was homoiconicity at all, but rather "stay in JS semantics, keep the JS ecosystem, and build structural editing over any language". Homoiconicity is a word you grabbed to borrow from Emacs's fame, but not a requirement you're were ever trying to satisfy. If it was the actual requirement, there are dozens of options that exist already - Squint, cherry, Clojurescript, Scittle, Fennel-to-JS, even Gleam - any of them gives you code-as-data cheaply.
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 let JS code modify the browser itself. If I suddenly decide I'd like Firefox's menu completely rearranged, I don't think JS will give it to me.
Also, Emacs windows vs tabs. Think of having each tab be a non-overlapping window within the browser window.
Finally, most browsers don't let JS code modify the browser itself. If I suddenly decide I'd like Firefox's menu completely rearranged, I don't think JS will give it to me.
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 to customize that HTML-and-JS OS if it was running in the browser as you have to customize Emacs I think...
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 to customize that HTML-and-JS OS if it was running in the browser as you have to customize Emacs I think...
> 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).
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).
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
Basically, the problem is that the Web browser doesn't give enough control to developers to be used as an application platform. Simple things like key bindings are impossible for example (because there are some key bindings that the browser will not let you modify).
Another problem is integration with other desktop applications and system utilities. The browser intentionally removes and restricts this functionality because the browser's model of the users is that users are incompetent bumbling idiots who must be protected from bad choices at the cost of being able to perform useful actions if necessary. Emacs has some safeguards of that sort, but they are intentionally made easy to disable (eg. loading directory-local code).
Emacs itself serves as a communication interface for other programs and uses operating system interfaces to the same effect. It's trivial to run a program from Emacs and feed its output to another program, while displaying the result in Emacs. In the browser, you'd have to arrange for a custom protocol, a server that listens to requests from that protocol, and write wrappers around every utility you want to run so that they can wrap their outputs into messages of that protocol... essentially re-implementing IPC system abilities in browser (but a lot less efficiently).
Another problem is integration with other desktop applications and system utilities. The browser intentionally removes and restricts this functionality because the browser's model of the users is that users are incompetent bumbling idiots who must be protected from bad choices at the cost of being able to perform useful actions if necessary. Emacs has some safeguards of that sort, but they are intentionally made easy to disable (eg. loading directory-local code).
Emacs itself serves as a communication interface for other programs and uses operating system interfaces to the same effect. It's trivial to run a program from Emacs and feed its output to another program, while displaying the result in Emacs. In the browser, you'd have to arrange for a custom protocol, a server that listens to requests from that protocol, and write wrappers around every utility you want to run so that they can wrap their outputs into messages of that protocol... essentially re-implementing IPC system abilities in browser (but a lot less efficiently).
> so what is the problem?
That browsers/web tech is moving in the opposite way and blocking various emacs-esque usecases.
That browsers/web tech is moving in the opposite way and blocking various emacs-esque usecases.
There's nobody more interested than me. Which use cases? Blocking how?
> 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.
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.
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
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
They told me the future would have horrors beyond my comprehension.
But I understand this particular horror. I might even agree... :D
But I understand this particular horror. I might even agree... :D
Nearly 40 years of stuff.
People iterating on a problem space over time is the best way we have found to improve things.
The JS ecosystem is not that old and also attempts to solve hundreds of unrelated problems like running software without peoples consent.
People iterating on a problem space over time is the best way we have found to improve things.
The JS ecosystem is not that old and also attempts to solve hundreds of unrelated problems like running software without peoples consent.
As much as I don't like all the choices they've made, the choices have been the result of iterating on the problem space over time.
And... yeah the consent thing is messy. There's a kind of implicit consent in knowing that a user that does not consent can block scripts. But then it can quickly become coerced consent if there's some IRL reason you need to use the page and it absolutely does not work without JS.
That said, I'm a JS-webapp UI guy. Partly that's just what I've built my career on, largely because it was the new field emerging as I was coming up. I could learn things quickly and convert what I learned into a salary. But the second reason is that I'm disillusioned with HTML as the wire format for the web. If you choose to render HTML on your server, you're centralizing costs in a way that will eventually force you towards an extractive relationship with your users. Not only are you centralizing the cost of rendering and transmitting the HTML, but you're also centralizing the cost of building and maintaining the UI layer.
This is (partly) because HTML failed at being a semantic language. There was a brief flicker of hope with XML and XSLT -- for a hot second you could write a compact semantic document and send it over the wire. No longer...
And... yeah the consent thing is messy. There's a kind of implicit consent in knowing that a user that does not consent can block scripts. But then it can quickly become coerced consent if there's some IRL reason you need to use the page and it absolutely does not work without JS.
That said, I'm a JS-webapp UI guy. Partly that's just what I've built my career on, largely because it was the new field emerging as I was coming up. I could learn things quickly and convert what I learned into a salary. But the second reason is that I'm disillusioned with HTML as the wire format for the web. If you choose to render HTML on your server, you're centralizing costs in a way that will eventually force you towards an extractive relationship with your users. Not only are you centralizing the cost of rendering and transmitting the HTML, but you're also centralizing the cost of building and maintaining the UI layer.
This is (partly) because HTML failed at being a semantic language. There was a brief flicker of hope with XML and XSLT -- for a hot second you could write a compact semantic document and send it over the wire. No longer...
> 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 relatively old and stable, it feels like the wheel's getting reinvented over and over again and "this will be a good enough pattern for the next decade" hasn't ever really shaken out, unlike Lisp or even Python.
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 relatively old and stable, it feels like the wheel's getting reinvented over and over again and "this will be a good enough pattern for the next decade" hasn't ever really shaken out, unlike Lisp or even Python.
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...
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...
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.
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.
Oh for sure. I'm not trying to make a case against Emacs or Elisp or anything. Mature tech is highly, highly valuable. I just wanted to know if JS could do it. Could it, can it host a whole unix-y, emacs-y OS?
No, the power of the browser belongs in emacs. You're composing the wrong direction!
Anyway aren't you just describing vscode?
Anyway aren't you just describing vscode?
I think I'm composing in the right direction! Terminal protocols are 50 years old, have some wild backwards incompatibilities, and are not accessibility-friendly. Funny enough CSTML functions both like a terminal protocol and like a replacement for HTML and XML
Maybe python can't do it, but I would love to extend my editor (and even browser) using python.
My core idea, CSTML, isn't implementation-language-specific: https://docs.bablr.org/guides/cstml
What it could at least let you do is view JS code using more "Pythonic" syntax rendering. The semantics would still be JS, but you could get rid of the curly braces while you were reading it if you just preferred semantic indentation, for example
What it could at least let you do is view JS code using more "Pythonic" syntax rendering. The semantics would still be JS, but you could get rid of the curly braces while you were reading it if you just preferred semantic indentation, for example
> Suppose I want to work in a single place for all my contexts, both personal and professional.
This has always been my problem with adopting Emacs or Obsidian or any other app that purports to do this. Who are y'all working for that you can bring professional stuff onto the same system as personal stuff? I don't want my personal emails on my work computer, and my boss would be rather upset if I brought work emails onto my personal computer. I'd love one of these do everything apps that lets me tag and sync just stuff that ought to be synced.
This has always been my problem with adopting Emacs or Obsidian or any other app that purports to do this. Who are y'all working for that you can bring professional stuff onto the same system as personal stuff? I don't want my personal emails on my work computer, and my boss would be rather upset if I brought work emails onto my personal computer. I'd love one of these do everything apps that lets me tag and sync just stuff that ought to be synced.
I think his secondary point is to show the potential. His primary point is likely that if you set this all up for home use, you can use mostly the same config to use it at work. This way, when you go home or go to work, you're dealing with the same environment and workflows.
Maybe he is a freelancer or a business owner and not an employee. If you’re one of the former, there’s often little separation between work and personal. I only truly enforce separation when I’m an employee, with different devices for each context.
Many people that do this are almost certainly freelance contractors in some facility?
Probably, though, many are just using personal as not strictly personal, but the kind of personal things you might do while at a desk job.
Probably, though, many are just using personal as not strictly personal, but the kind of personal things you might do while at a desk job.
I assume it was not to use same profile but the same environment of all text related tasks. Like I write blogs and research papers in org mode, and then simply export the necessary file format. I can perform text operations easily in mail, i can have elisp snippets generate mail for me depending on the sender, I can use calc to add numbers inside the buffer, I can have latex previews.
> This has always been my problem with adopting Emacs or Obsidian
That's an orthogonal problem. It's almost trivial to set up Org-mode so all your personal notes are always encrypted on disk.
That's an orthogonal problem. It's almost trivial to set up Org-mode so all your personal notes are always encrypted on disk.
You don't have to combine work and personal stuff in Emacs. You can for example set it up to just connect to work email and work jira and work slack and work clankers etc.
GNU Emacs is probably the easiest way to capture the spirit of working on the Lisp machines. Interlisp is an ongoing project that takes you even further down that road.
It's a matter of philosophy; would you rather have multiple small apps that do only one job or one "super app" that does it all?
Ironically, starting from the former, I've now turned my tmux into the latter with so many utility apps integrated into it. But now I can see the benefits of each approach. Maintaining "super apps" is more challenging due to the coupling of so many pieces to each other.
Ironically, starting from the former, I've now turned my tmux into the latter with so many utility apps integrated into it. But now I can see the benefits of each approach. Maintaining "super apps" is more challenging due to the coupling of so many pieces to each other.
If the "super app" is modular - like Emacs is - you basically get the best of both worlds.
And building a consistent good experience from isolated tools is even harder. The problem is just hard and I think good criteria with the super app approach is the way to go.
I really like Spacemacs. It's discoverable, extendable, quite consistent.
I really like Spacemacs. It's discoverable, extendable, quite consistent.
> And building a consistent good experience from isolated tools is even harder.
Yes, I agree, which is why my tmux slowly devours my numerous small utility apps into itself! I haven't tried Spacemacs yet, too Vim-pilled at the moment..
Yes, I agree, which is why my tmux slowly devours my numerous small utility apps into itself! I haven't tried Spacemacs yet, too Vim-pilled at the moment..
> I haven't tried Spacemacs yet, too Vim-pilled at the moment..
You do know that Spacemacs defaults to Vim bindings, right?
You do know that Spacemacs defaults to Vim bindings, right?
Can someone define "lispboard" for me? The article calls the browser a lispboard, which breaks every guess at a definition I have.
The author defines it:
> Like an electronics breadboard, a board where every module you plug in shares a bus with all the others, except here the modules are written in Lisp.
The bit about the browser seems to simply be a strained metaphor: "The browser is a rented Lispboard, with a landlord. Emacs is the only one you can own."
> Like an electronics breadboard, a board where every module you plug in shares a bus with all the others, except here the modules are written in Lisp.
The bit about the browser seems to simply be a strained metaphor: "The browser is a rented Lispboard, with a landlord. Emacs is the only one you can own."
Thanks! I missed that.
If we take a browser, and add things to make it a super app, we would basically get an extensible electron app, right?
Maybe, why not?
Maybe, why not?
Unlike the OP I hated the scratch buffer for running Elisp, so I created a REPL for Elisp that behaved more (in my naive eyes) as a real language. I was very excited when RMS emailed me to ask to include it in Emacs. Last I checked (a few years ago now) it was still there as M-x ielm (Inferior Emacs Lisp Mode).