4 ms·

Actually, there's a hidden motive behind not targeting Clojure: the eventual plan is to allow Elisp-like mutability so it can be used to build an Emacs-like edi

Actually, there's a hidden motive behind not targeting Clojure: the eventual plan is to allow Elisp-like mutability so it can be used to build an Emacs-like editor. I chose OCaml because of the relatively mature OCaml-LLVM bindings. A self-hosting compiler is a lot of work: it'll require Rhine-LLVM bindings first.

pjmlp 12y ago
Faire enough. Thanks for jumping in.
swah 12y ago
Fast, modern and portable to the 3 platforms like Sublime, and extensible like Emacs, could compete with Atom and LightTable.
- artagnon 12y ago
  One of the major problems with Emacs is that it's hard to isolate, debug, and rollback Elisp fragments; the only way to fix many problems is to restart Emacs. I still haven't figured out how to solve this problem with Rhine: keep (limited) history for all variables? How do we keep track of the effect of specific function callchains?
  - swah 12y ago
    I wish I can write my own editor someday to learn about those things ;)
sgrove 12y ago
Why do you need mutability for that? Doesn't LT's approach give the same flexibility without the need for mutation everywhere? Or is it mainly a concern of performance?
- artagnon 12y ago
  I didn't quite understand how LT works. I have the following tasks in mind: 1. Set indent-tabs-mode in all modes which use that variable. So, if I install a hs-mode, the indent-tabs-mode in my .emacs should be the one that it picks up. 2. Add multiple independent hooks to c-mode-hook from different modes. 3. Change the global keymap in different modes, as and when they are loaded. Isn't mutable variables the most obvious way to solve these problems?
  - bjeanes 12y ago
    > Isn't mutable variables the most obvious way to solve these problems? Yes, but the mutation can be entirely limited to the reference. The data structures do not have to be mutable. It's a trade-off, of course, because you can't pass somebody just part of a data structure (like a sub-map) and have them mutate it there, but I think Clojure has shown that in practice this isn't really much of a loss.
DennisP 12y ago
So you're building an Emacs-like editor on an Elisp-like language. What are you hoping to do differently than Emacs? (Not being snarky, languages and text editors are both interesting projects and worth experimenting with, and combining the two is especially interesting to me.)
- ANTSANTS 12y ago
  A new editor that copied emacs' good Lisp support and insane customizability via hooks for everything but had an interface that was approachable for regular desktop users (tabs instead of buffers, good CUA-style keybinds out of the box, no surprising weirdness like nonlinear undo, etc) is about the single most important thing anyone could do to increase the popularity of the Lisp family. Right now, if you want to write Lisp, your choices are: emacs, which is utterly unapproachable for newcomers, and will always be uncomfortable to use for people that grew up with "modern" desktop GUIs, because it and most of its userbase predate established interface standards and they like it that way. DrRacket, which is a step in the right direction but is Racket-specific, bloated, slow, and somewhat buggy. LispWorks, which is proprietary and prohibitively expensive unless you sign up for and are allowed to use the crippleware version. Given those choices, it's not surprising that most people just give up on Lisp and use languages that you could comfortably program in Notepad if you had to.

pjmlp 12y ago

Faire enough. Thanks for jumping in.

swah 12y ago

Fast, modern and portable to the 3 platforms like Sublime, and extensible like Emacs, could compete with Atom and LightTable.

artagnon 12y ago
One of the major problems with Emacs is that it's hard to isolate, debug, and rollback Elisp fragments; the only way to fix many problems is to restart Emacs. I still haven't figured out how to solve this problem with Rhine: keep (limited) history for all variables? How do we keep track of the effect of specific function callchains?
- swah 12y ago
  I wish I can write my own editor someday to learn about those things ;)

sgrove 12y ago

Why do you need mutability for that? Doesn't LT's approach give the same flexibility without the need for mutation everywhere? Or is it mainly a concern of performance?

artagnon 12y ago
I didn't quite understand how LT works. I have the following tasks in mind: 1. Set indent-tabs-mode in all modes which use that variable. So, if I install a hs-mode, the indent-tabs-mode in my .emacs should be the one that it picks up. 2. Add multiple independent hooks to c-mode-hook from different modes. 3. Change the global keymap in different modes, as and when they are loaded. Isn't mutable variables the most obvious way to solve these problems?
- bjeanes 12y ago
  > Isn't mutable variables the most obvious way to solve these problems? Yes, but the mutation can be entirely limited to the reference. The data structures do not have to be mutable. It's a trade-off, of course, because you can't pass somebody just part of a data structure (like a sub-map) and have them mutate it there, but I think Clojure has shown that in practice this isn't really much of a loss.

DennisP 12y ago

So you're building an Emacs-like editor on an Elisp-like language. What are you hoping to do differently than Emacs? (Not being snarky, languages and text editors are both interesting projects and worth experimenting with, and combining the two is especially interesting to me.)

ANTSANTS 12y ago
A new editor that copied emacs' good Lisp support and insane customizability via hooks for everything but had an interface that was approachable for regular desktop users (tabs instead of buffers, good CUA-style keybinds out of the box, no surprising weirdness like nonlinear undo, etc) is about the single most important thing anyone could do to increase the popularity of the Lisp family. Right now, if you want to write Lisp, your choices are: emacs, which is utterly unapproachable for newcomers, and will always be uncomfortable to use for people that grew up with "modern" desktop GUIs, because it and most of its userbase predate established interface standards and they like it that way. DrRacket, which is a step in the right direction but is Racket-specific, bloated, slow, and somewhat buggy. LispWorks, which is proprietary and prohibitively expensive unless you sign up for and are allowed to use the crippleware version. Given those choices, it's not surprising that most people just give up on Lisp and use languages that you could comfortably program in Notepad if you had to.