The GNU Emacs website does a better sales job...which is interesting because unlike this product, GNU does not even need to sell anything. When looking through the website I see Windows 95-ish screenshots, pages that say they have not been updated in over five years, and little description of what it does beyond saying it's like EMACS. No clue at all about why I should use this rather than one of the other free-beer editors out there. And now I read these comments and see it costs $250? Why??
Sorry, but that's just nonsense. If you want to actually sell something, I would expect to have at least a summary of main selling points right there, at the front page.
Expecting the potential buyer to dig through the manual to even learn what the software actually is beyond the "emacs like editor" is ridiculous. For me it just means it is yet another editor for obscure OSes (OS/2 ?), one of thousands on the market, and that I am not going to consider spending money on it when the authors can't be even bothered to tell me why should I do so. The product could be technically superior than everything else and the best thing since sliced bread, but it means little if you don't tell people about it. That's marketing 101.
Compare with e.g. SublimeText website - the key stuff is right there, even animated (!):
https://www.sublimetext.com/
Unfortunately, many project websites (both open source and commercial) are like that - front page filled with jargon and random stuff but you won't find a short paragraph summarizing what the software actually is for and its main features for people not already familiar with it.
Perhaps its authors want to achieve other objectives than just sell something, or think it's more appropriate for their users and target public.
There's certainly the possibility that they aren't really sure how selling things on the Internet works. However, I'm willing to entertain the possibility that the guys who've been selling this for 32 years know what works for them better than someone who just found out about their editor.
And frankly, design aside, I like Epsilon's website a lot more than SublimeText's. The front page doesn't offer any useful information about the "key stuff" for a programmer's editor (is it properly extensible, through an extension language? is it easy to interface with other programs? maybe has some added goodies, like a hex editing mode?).
Besides, it's entirely devoid of any useful information besides these 7 features and 6 animations. There seems to be no way for me to find out if ST has any features for e.g. remote editing or VCS integration other than downloading the evaluation version. Where's the manual? Where's at least a longer list of supported features?
I equally don't understand the fixation for animation. It takes less time to find the Epsilon manual on their website and skim it than it takes to watch the six (confusing, since there's no on-screen keyboard!) animations that take up the whole screen. I understand its value as an enhanced form of illustration, but I'd appreciate it more if it would enhance the written, precise information, rather than replace it.
> or think it's more appropriate for their users and target public.
I wonder who would that be. Mind you, programmers who shop for an editor are usually very knowledgeable about what they want. They know how to extend Eclipse or Emacs or Atom or VS Code or whatever they have ever laid their hands on.
I'm a 20+ year daily gnu/x emacs user and purchased a copy of Epsilon in July after demoing it for a couple weeks. Since then I've been coding in Epsilon daily (Linux/C++):
What I love about it:
1) it's VERY fast,
2) the documentation is phenomenal,
3) the defaults are sane, and the configurable options are well thought out,
4) rock-solid stable.
It's a beautiful piece of software and I've really enjoyed using it. No regrets on the purchase. To me it was worth the $250.
For some reason, I find it gratifying that this operation has been in business (more or less) for 32 years.
I can feel a strong sense of pride in the application he's built and still seeing it out there. Whatever few orders he gets is essentially keeping the site running and providing online support to those few still using his wares.
Each order gets you copies for Windows, Linux, Mac OS X, FreeBSD, OS/2 and DOS versions. Must be fun to have a long-standing project that you can go to that keeps you in touch with both newer and older OSes too.
The order form has this line "Note: As of 19 February 2016, CDs are temporarily out of stock. If you need a CD please email us for estimated availability.", which might imply that someone bought themselves a CD copy of this editor back in February.
Sometimes programmers need to look at unusual files: binary files, very big files, odd data files. Epsilon was designed without the limits of other editors, so it can handle these kinds of jobs, as well as ordinary files. For example, with Epsilon, lines can be as long as you like.
This text editor gets it. Such a contrast to some of the editors we have today where anything over a few megabytes is an edge case not worth fixing.
Really? I loaded a 1.2GB ISO in the demo and it used… 1.2GB of RAM. (At least it worked though, coughAtomcough.) And more importantly it has no unicode support whatsoever as far as I can tell (any non-ASCII characters I typed showed up as ?).
Wouldn't a hex editor be a better choice for binary files and odd data files? Are there benefits besides the ability to handle large files and long lines?
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 previous headlines? Is this just thing everybody sees? Or am I just really lucky picking my threads?
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.
I need to seriously rethink my Emacs configuration. I thought I had a lot of packages and elisp scripts loaded at startup, but I don't think I ever hit the 5-second mark. Emacs starting up a whole minute? What great packages am I missing?
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.
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.
What are you running it on? Tens of seconds... I remember that, from back when it was rumored that EMACS was an acronym for "Eight Megabytes And Constantly Swapping". 8 MB of RAM haven't been anything to brag about for a while, though, nor has emacs started in tens of seconds up to a minute.
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.
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.
It depends on how much you've got loaded. Most serious emacs users have a vast corpus of elisp loading on boot. Nowadays, some people will load the elisp lazily, so the files are only evaluated of you use their functions.
This is also why emacsclient exists: To try to amortize the startup cost.
In Epsilon 2.0 (1985) for MS-DOS, you could Cntl-X Cntl-M to get a buffer that had a real, live shell in it, where you could start up background compiles and such, and still be able to edit your other buffers live. This was a miracle! (DOS could barely run a single process, with certainly no preemptive scheduling; and even if you dreamed of multi-tasking, there was a maximum of 640k of memory, with nothing virtual about it).
I think "ϵpsilon" was my first programmer's editor, although I think I had previously written programs in EDT, Turbo Pascal, Turbo C++, QBASIC, GW-BASIC, ZBASIC, IBM Basic, Applesoft Basic, WordStar, and a thing called Video Scribe for HDOS. It was so much better than nearly all of the alternatives, even though I didn't use its IDE features.
It was super helpful to me to have used ϵpsilon when I got my first Unix account in 1993, because I already knew how to use Emacs, almost. Some of the basic keybindings (like exiting and changing windows) were different enough to be an obstacle.
And then I never looked back. From then on I used my 286 to run Procomm+ and Vernon Buerg's LIST.COM, not to write programs on. Sorry, ϵpsilon. Emacs is an entire universe.
(Since then I've also programmed in vim, IDEA, Eclipse, some prototype editors I've written, Arduino, XCode, Notepad, OpenSCAD, and browsers, mostly in order to collaborate with other people and occasionally because they are better integrated with one or another more or less shitty system than Emacs is. But Emacs is pretty much the most convenient way to program for me.)
Been using Epsilon daily since 1989. I've been disillusioned lately that it's not been updated for quite some time.
The developer is still quite responsive though, and even though I use it less than I used to, I still use it every day.
I was hoping to see a native Mac version rather than the version that depends on X.
+1 for better Mac support. I don't know if the author has any inclination to do an update, but I would definitely re-buy the editor if the Mac version didn't depend on X.
I used epsilon for all my programming work until I discovered vi in '93. It ran on dos, and OS/2. United had something similar in uemacs.
I used EEL the extension language to write a log of all I did to help refreshing my memory when I filled by time sheet. It was a great editor with a built in shell, windowing and whatnot.
Both on DOS and OS/2 I ran the MKS Toolkit to emulate a Unix environment and it fit right in. Happy user. No idea it was still on sale.
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 well.
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.
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. C-implemented functions (“subrs” in Elisp terminology), Elisp functions, Scheme procedures, etc. all compile to the same “procedure” data type, which may appear in Elisp symbols’ function-slots, be bound to Scheme variables, and are otherwise first-class objects in both environments which can be funcalled or applied explicitly or by the language’s normal syntactic way of calling functions. Similarly, other data types are unified between the languages; Elisp integers and exact Scheme integers, inexact Scheme numbers and Elisp floats, Elisp cons cells and Scheme pairs, symbols, etc. are the same data type across the languages. (Strings are an exception though; see below.) Therefore one can generally use a library written in another language as if it were written in the same language."
And looks like there is some progress still: [2]
Here is the current TODO list [3], if someone wants to help.
> 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.
> 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.
Lugaru is from the french word 'Loup-Garou' which means Werewolf. I wonder where he got the idea to name the software company as such? Also it speaks volumes that no one has yet commented on appearance of the website, I guess the target audience is not the 'get the latest hip named thing' kinda crowd.
'Sometimes people ask what our company name, Lugaru, means. It's actually a phonetic spelling of the French word for werewolf, "loup-garou". One day in 1984, after finally turning off the computers and noticing the sun had come up, we decided this might be an appropriate name for our new company.'
Very happy to see someone keep an editor going as a commercial product for so many years. I think this is a good example of 'craft'. There are a few gems out there that once you stumble over them, they become part of your toolbox and are just so much better than anything else for the work that you do, that you stick with them. This looks to me to be an example of that.
Not all IDEs suit all people. Apart from feature set one also has to consider style and operations. Im most happy when i find the features+style+operations match to the job at hand. And that is why i turn to Notepad++ when i have to ferret around in files of different types, awk when i have to mess with text/log files. I turn to VS only when i have to code something in C#, use PyCharm for python things.
Bottom line when an IDE 'just clicks' for you then its a wonderfully productive tool.
Because of all the positive comments I decided to try the editor. For all of you evangalizing this editor, why do keybindings like "F9, Ctrl-X U" make sense for common tasks like undo?
Press F9, release and then quickly press ctrl-x, release and then press u. Even during my short time with emacs did I not hurt my fingers this much
Actually, the primary binding is 'C-/', with 'C-x u' and 'C-_' as alaises. The 'C-x u' alias exists because it's easier for new users to remember and the 'C-_' alias exists because that's what some terminals send when you press 'C-/'.
Makes a good set of training wheels, sure. I used it for a couple of years.
I did end up with undo still on C-z after turning off cua-mode, because I use graphical frames and never want to suspend anyway. But it's not really a help: the C-/ C-? pair is much more convenient, and for nontrivial undoing I'm navigating a state tree anyway.
I almost want to buy a copy just to give the guy kudos for keeping with it for all these years. Pretty impressive array of platforms and features for something with that old a history!
Speaking of bygone editors, I still have (very) fond memories of using QEdit (later TSE (The Semware Editor)) in my DOS-centric early '90s larval hacking days.
Looks like they still sell it for $45 a pop, I don't think the website (http://www.semware.com) has changed much in the intervening 20 years though. :)
I've been using Epsilon for 25+ years. It's great, and well worth the money I have spent on the updates over the past few decades. It's my go-to editor. I can get along in vanilla Emacs, but Epsilon is a lot friendlier on a Windows box.
There's not much I would change on the Windows version (better multiple monitor support might be interesting0. I would pay dear money for better MacOS support.
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?
Leaving aside the "signed by Apple" angle, I find it ironic in modern companies that many of them spend a lot of money finding people to work for them, then they spend money paying those people, and then they spend more money making it as hard as humanly possible for those people to do their jobs.
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.
> Otherwise please use the original title, unless it is misleading or linkbait.
The long-standing policy is to represent the submitted content as accurately as possible and let readers pick out what's interesting to them, not what the submitter found interesting. The comment thread is the place to express one's opinion on the content.
strongly agree with this. there's a difference between editorialising and having a title that tells you why the link was posted in the first place (and the fact that it's "a programmer's editor" is not it)
Also, the demo is extremely snappy. Shame it doesn't seem to have vi emulation (unless I missed it?) or org-mode, both of which are killer features of emacs for me.
as text editor extension languages go, i really liked aurora's [old dos-era editor with an emacs-like core + soft layer architecture]. it was pascal-like, and really pleasant to work with.
Epsilon is great. Let me offer a whole-hearted recommendation. It's a secret weapon, an unfair advantage we have, those of us in the know.
I was so happy to come upon it as a sadly ex-Symbolics-ZMacs user (and ex-MIT-TECO-Emacs user) when first confronted with a 286 system, and I have have been using it ever since. I buy a few copies every few years, typically for team members who wonder what's that magic I keep using. At my present company, I fought (and won) a three-month battle with the Software Standards Committee to be allowed to install it.
As a Windows developer I routinely do all editing in Epsilon, switching to Visual Studio only to compile and debug. To draft this very message, I switched away from my web browser to Epsilon. Steven Doerfler provides great customer service on the very rare occasion that I need to turn to him.
If you have any emacs in your soul, buy Epsilon. Now.
Well, the first N specific things that come to mind have already been expressed pretty well by previous comments here (including your own "snappier"). The next 10*N things are already expressed pretty well in the 2009-format-but-still-valid-content marketroid material on lugaru.com. As it happens, I haven't found a need to explore a universe of community extensions because right out of the "box" Epsilon does nearly everything I need, and my few personal extensions take care of the rest. Beyond that, I no longer care to engage in yet another emacs religious war, and emacs does not need any bad-mouthing from me.
I can understand and respect that you're reluctant to write an endorsement of Epsilon and/or a comparison with Emacs. But I'd like to let you know that while starting to read your comment I was looking forward to just that, and now find myself a bit disappointed that you're not sharing some reasons for your enthusiasm.
I was a big fan of Epsilon back in the days when it was an alternative to WordStar and I think I still own an original (paid) copy on floppy disks, but I'm not familiar enough (any more) with its feature set to meaningfully answer the question of what qualifies it above Emacs.
Personally, I'm considering paying $250 just for the nostalgia value. And I love fast editors with an uncluttered surface. The ability to edit arbitrarily long lines and binaries is certainly a plus. But I would appreciate, if you'd reconsider, hearing more arguments to knock me off the fence.
