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

Epsilon Programmer's Editor

lugaru.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Epsilon Programmer's Editor

#71

Post by wtbob »

xvilka wrote: post #64

I hope Emacs guys will finish the GuileEmacs[1] project. They listed 3 main advantages: "The first immediate advantage is that Elisp will execute faster, because Guile uses a compiler tower with many optimization passes and ultimately compiles to Guile VM bytecode, which is more efficient than current Elisp bytecode. In the future, Guile is likely to implement some forms of native JIT as well as AOT compilation as we…

> I hope Emacs guys will finish the GuileEmacs[1] project.

I really really hope they don't and use Common Lisp to achieve the same end. Running emacs in a Common Lisp like SBCL implementation means that it will be natively compiled, with an extremely intelligent compiler.

> A second advantage is that it will be easier to implement some additional language features for Elisp which the Guile compiler tower and VM are capable of, like a full numeric tower (infinite-sized integers, exact rational numbers, imaginary numbers, etc.), record types (like an improved defstruct), CLOS-like OOP, an FFI, composable continuations, a module system, hygienic macros, multiple-value returns, and threads.

Common Lisp has infinite-sized integers, exact rational numbers and imaginary numbers. It has DEFSTRUCT. It has CLOS (obviously). Every Unix Lisp I'm aware of has an FFI. Continuations are actually a problem when it comes to e.g. UNWIND-PROTECT. Common Lisp has packages and an excellent module system in ASDF3. It has hygienic macro libraries, and natively supports the more-powerful DEFMACRO. It supports multiple-value returns. BORDEAUX-THREADS is an excellent portable thread library.

> A third advantage is all Guile APIs/libraries becoming available to Elisp code, no matter what language they’re implemented in, because different languages on the Guile VM can inter-operate quite well, especially if they’re both a Lisp.

Common Lisp has many excellent libraries available via Quicklisp.

Scheme is IMHO a broken language: distinguishing NIL and #f; only have one namespace; continuations; not allowing (cdr nil); not having a native object system; not having a rich type and class library; not having read macros. It was an interesting experiment, but the effort spent on Schemes would have been better spent improving Lisp.

Lisp is far closer to elisp, and is a better language to boot.

Re: Epsilon Programmer's Editor

#72

Post by KirinDave »

kragen wrote: post #30
KirinDave wrote: post #29

The OSX deployment not being a "verified developer" shuts down anyone in an enterprise environment. That's too bad, I wanted to try it at work.

That's interesting, and fairly dystopian — you're not allowed to run any software on your computer that isn't signed by Apple? Can you install, say, VirtualBox?

Yes. But of course, I'd rather not use a virtualization layer on OSX. It simply doesn't work well.

Ultimately, "Verified developers" is a good idea for corporate machines. It doesn't stop attacks, but it raises the cost of attacks. That's really what security is about these days.

Re: Epsilon Programmer's Editor

#73

Post by GFK_of_xmaspast »

qwertyuiop924 wrote: post #69
sooheon wrote: post #50

Earlier quoted context omitted.

Only use emacs, not epsilon, but someone above mentioned that it can handle long lines. Emacs, despite being a good editor, is not performant in such cases.

You can do some optmizations to Emacs line handling. emacs -nw can help, I think. But by the time you've really hit Emacs' limit, you should have split your line anyway. And there is always nano, for the truly desparate.

How does "-nw" help with long lines?

Re: Epsilon Programmer's Editor

#74

Post by qwertyuiop924 »

GFK_of_xmaspast wrote: post #73
qwertyuiop924 wrote: post #69

Earlier quoted context omitted.

You can do some optmizations to Emacs line handling. emacs -nw can help, I think. But by the time you've really hit Emacs' limit, you should have split your line anyway. And there is always nano, for the truly desparate.

How does "-nw" help with long lines?

Apparently, one of the scans is for glyph height. In -nw, your font's monospaced. If emacs is smart enough to drop the check, it should be slightly faster.

Re: Epsilon Programmer's Editor

#75

Post by michaelcampbell »

ww520 wrote: post #39
qwertyuiop924 wrote: post #32

I'll stick with Emacs for now. $250 is a bit heavy for those of us with little disposable income. In addition, I fail to see the advantage of this over Emacs: Emacs already has pretty much all of Epsilon's features, and a larger community. Furthermore, I highly doubt that its extensibility features are as extensive. It's kinda cool, though. Sidenote: why do I always see the HN headlines up to a day ahead in the previ…

Epsilon is very fast, like coming up in a second. Emacs takes tens of seconds up to a minute. You start Emacs and hope to never shut it down. With epsilon you can start it on a file quickly and move on.

> Emacs takes tens of seconds up to a minute

Not in 10+ years has this been true, at least for me.

> You start Emacs and hope to never shut it down.

It's not hope for me. I start emacs when the machine starts and quite literally never shut it down. Not because I don't want to start it up, but because without it running, I don't get work done.

I even generally have a copy running in an (again) always-on tmux session, for when I login to a box via ssh.

I feel this "big bloaty" anti-emacs argument really lost its legs ~1989; I'm not sure why people cling to it unless they have a vested interest elsewhere.

Re: Epsilon Programmer's Editor

#76

Post by jpfr »

wtbob wrote: post #71
xvilka wrote: post #64

I hope Emacs guys will finish the GuileEmacs[1] project. They listed 3 main advantages: "The first immediate advantage is that Elisp will execute faster, because Guile uses a compiler tower with many optimization passes and ultimately compiles to Guile VM bytecode, which is more efficient than current Elisp bytecode. In the future, Guile is likely to implement some forms of native JIT as well as AOT compilation as we…

> I hope Emacs guys will finish the GuileEmacs[1] project. I really really hope they don't and use Common Lisp to achieve the same end. Running emacs in a Common Lisp like SBCL implementation means that it will be natively compiled, with an extremely intelligent compiler. > A second advantage is that it will be easier to implement some additional language features for Elisp which the Guile compiler tower and VM are c…

The idea of GuileEmacs is not to move away from the elisp language. The idea is to use an elisp implementation based on the Guile virtual machine.

Elisp will not go away. So any arguments for lisp and against scheme are void in this context.

Re: Epsilon Programmer's Editor

#77

Post by qwertyuiop924 »

michaelcampbell wrote: post #75
ww520 wrote: post #39

Earlier quoted context omitted.

Epsilon is very fast, like coming up in a second. Emacs takes tens of seconds up to a minute. You start Emacs and hope to never shut it down. With epsilon you can start it on a file quickly and move on.

> Emacs takes tens of seconds up to a minute Not in 10+ years has this been true, at least for me. > You start Emacs and hope to never shut it down. It's not hope for me. I start emacs when the machine starts and quite literally never shut it down. Not because I don't want to start it up, but because without it running, I don't get work done. I even generally have a copy running in an (again) always-on tmux session,…

An always on tmux session? That seems kinda hacky, given emacsclient exists for exactly this reason...

Re: Epsilon Programmer's Editor

#78

Post by michaelcampbell »

qwertyuiop924 wrote: post #77
michaelcampbell wrote: post #75

Earlier quoted context omitted.

> Emacs takes tens of seconds up to a minute Not in 10+ years has this been true, at least for me. > You start Emacs and hope to never shut it down. It's not hope for me. I start emacs when the machine starts and quite literally never shut it down. Not because I don't want to start it up, but because without it running, I don't get work done. I even generally have a copy running in an (again) always-on tmux session,…

An always on tmux session? That seems kinda hacky, given emacsclient exists for exactly this reason...

Maybe I'm not using it right then, but I log in and out of these boxes several times a day from several different remote locations and just `tmux a` when I do.

How does emacsclient protect me from ssh disconnects? I thought all it did was use an existing emacs instance.

Re: Epsilon Programmer's Editor

#79

Post by wtbob »

jpfr wrote: post #76
wtbob wrote: post #71

Earlier quoted context omitted.

> I hope Emacs guys will finish the GuileEmacs[1] project. I really really hope they don't and use Common Lisp to achieve the same end. Running emacs in a Common Lisp like SBCL implementation means that it will be natively compiled, with an extremely intelligent compiler. > A second advantage is that it will be easier to implement some additional language features for Elisp which the Guile compiler tower and VM are c…

The idea of GuileEmacs is not to move away from the elisp language. The idea is to use an elisp implementation based on the Guile virtual machine. Elisp will not go away. So any arguments for lisp and against scheme are void in this context.

> The idea of GuileEmacs is not to move away from the elisp language. The idea is to use an elisp implementation based on the Guile virtual machine.

> Elisp will not go away. So any arguments for lisp and against scheme are void in this context.

If the goal is not to mingle elisp & Scheme, then what's the point of using the Guile VM? Why not just implement an interpreter for elisp in Lisp?

There is absolutely no reason to mingle Scheme with elisp. Scheme's not a bad language for those places it's well-suited, but production software is not one of those places. For that there is Common Lisp.

Re: Epsilon Programmer's Editor

#80

Post by qwertyuiop924 »

michaelcampbell wrote: post #78
qwertyuiop924 wrote: post #77

Earlier quoted context omitted.

An always on tmux session? That seems kinda hacky, given emacsclient exists for exactly this reason...

Maybe I'm not using it right then, but I log in and out of these boxes several times a day from several different remote locations and just `tmux a` when I do. How does emacsclient protect me from ssh disconnects? I thought all it did was use an existing emacs instance.

IIRC, that's exactly how it protects you: if your ssh drops, your buffer won't close. check the docs, though. I'm not 100% sure.
Post reply on HN