Hacker News Reader

Comment by justinsingh | Hacker News Reader

Just an anecdote about the older site. I was in a comp sci class at school a year ago. My classmate next to me asked what editor I use because it was a Beginning C++ class, and I said emacs. He went to the website which looked incredibly outdated to the expectations of new programmers, and just felt uncomfortable giving it a try. He opted for an editor with a more modern website.

So with the new website, which looks good, maybe emacs will seem more accessible and worth giving a try to new programmers who cross paths with it. At the same time, maybe that sense of accessibility is misleading given the learning curve of emacs that isn't exactly beginner-friendly. Nonetheless, I like the site!

View on HN

Personally it has never mattered to me how many people adopt Emacs because it has enough users to ensure development forever. I know for a fact that if the Emacs developers weren't doing a bang up job, which they are, then I would immediately allocate some of my time to help. Emacs is emblematic of the community aspect of software development that rms usually brings up when talking about free software, and I think it's a subtle notion that separates Emacs from a typical "open source" project. Projects that are as they say "Open Source" tend to be commercially oriented more than community oriented. Whether or not Emacs is a large or small community does not really matter to me, the software is pretty much stable enough that the future is bright even if everyone on the developer mailing list dropped dead.

I don't mean to complain about "open source" software nor do I claim that the way that Emacs is being developed is better than any other. What I mean to say is that Emacs is an old application and I found it on its old crusty website, decided to dedicate a bunch of time on learning macros, because that's simply the kind of person I am. Whether or not Emacs had a great website would not be the factor that swayed me, and frankly I'm not in the business of trying to sway people as an Emacs fan. Use what you want. I know I'm getting the best development environment for me, because I know me, and I've made Emacs mine.

I think this is a good lesson to people whose projects aren't Emacs' size yet.

Of course Emacs can get away with it, but this sets a good example of what a nice, simple website can look like for your project.

Don't spend too much time on the website, of course (the core project is what's important), but first impressions affect adoption, right?

It may not be that they are commercially oriented, but that they have adopted startup-like mentalities regarding "growth".

This in turn leads to all kinds of changes to appear more fashionable and appealing to the masses.

Frankly i think thats a fools errand. Seems to me that when it comes to fashionable in relation to computing, we are dealing with a Giffen Good (or perhaps even a Veblen Good). Meaning that to be a fashionable computing platform, it has to be an expensive one.

But in the process you end up with something similar to New Public Management for FOSS projects. Trying to evangelize and drum up attention as if they were pitching a for profit product, much like NPM tries to put market forces into public services.

  I know for a fact that if the Emacs developers weren't
  doing a bang up job, which they are, then I would
  immediately allocate some of my time to help.

Development is going great IMHO. However, the bug count is steadily increasing. Any time invested into emacs is well spent.

https://lars.ingebrigtsen.no/2016/05/03/emacs-bug-trends/

Same author also wrote a nice, short intro on how to get started with Emacs bug hunting: https://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-de...

Hey, it's not called the Editor for Middle Aged Computer Scientists for no reason!

What is the benefit for an existing CS student to switch to Emacs who is already comfortable with using IDEs like Visual Studio, Eclipse or IntellijIDEA?

If you're working with something else than C#, Java or the like (i.e. languages that benefit hugely from features offered by IDEs (or that require IDEs to write in them and stay sane - if you're not feeling charitable)), then yes - benefits of speed, flexibility and efficiency. That's without even bringing up the topic of org-mode... :).

Can you give me some example of efficiency? I've always thought IDEs are more efficient, i.e. intellij IDEA indexes everything and provides superior auto-completion.

Too much clicking in the IDE, though I guess this complaint goes more towards Eclipse than IDEA :).

But Emacs (and Vim) offer you superior text editing, if you can be bothered to learn it. Semantic navigation, convenient incremental search, semantic editing, keyboard macros, etc. etd. - you can do much more in fewer keystrokes, which is important in keeping yourself in the flow. In Emacs, you get all the benefits of highly optimized keyboard navigation and editing for every task you'd like to do - writing code, managing files, inserting simple and complex code templates, managing projects, complex work with Git repositories, etc. - and it's all consistent - you can do the same regex incremental search in e.g. your commit logs as you do in your source files.

My overall personal impression about Emacs is that it's the most efficient environment optimized for anything text-related out there (especially if you switch to vim keybindings for text editing and navigation, which are arguably smarter).

I'm using emacs for a year now but I'm reallt bad at it, I wish there was a text like your comment with the words linked to specific webpages or videos which explain how to install everything you need for that word and show how to use it. I would link:

"Semantic navigation", "incremental search", "semantic editing", "keyboard macros", "optimized keyboard navigation", "inserting simple and complex code templates", "managing projects", "complex work with Git repositories", "regex incremental search"

Something I learned way to late was to use the build in features for learning about functions and variables.

C-h f : find help for functions C-h v : find help for variables C-h k : Get help for a key-combination

If you have helm mode installed it's often very easy to find the functions you are looking for.

For your ordinary average everyday normal well-supported language, stick with the IDE.

But suppose you're working with some random language that nobody's ever heard of. It's some tool-, product- or site-specific thing. If you're very lucky, there's some ropey Scintilla-based text edit widget that lets you work with one file at a time. If you're not, there's quite literally fuck all. When you search on Google, there's 0 useful results (until you get to page 9, and there's 1 single post from somebody, on some random forum for general blarney, ranting about how they're doing some contract work and using this stupid language and it's terrible because there's no tools and they're stuck using notepad and their life sucks).

If you've got an IDE, now you're sort of stuck. Maybe you can find a language it supports that's a bit like, and then you've got syntax highlighting - sort of - and autoindent - maybe. But you have to do code browsing by grep, effectively, and you've got 0 in the way of code completion.

With emacs on the other hand you can relatively easily code up some language-specific support for syntax highlighting (takes 5 minutes) and autoindent (5 minutes for something basic, maybe 1-2 hours if you want to get fancy). Add some imenu regexps (5 minutes) and you've got code browsing from within a file. Put your imenu regexps into Exuberant Ctags (15 minutes), and you've got cross-file code browsing. Code completion... well... yeah... it's not perfect, but if you squint a bit, dabbrev (2 minutes if you need to tweak your syntax categories) is fine.

I've never failed to turn a time/effort/hassle profit from doing this.

> indexes everything

So should your text editor (and/or it's companion programs)

> and provides superior auto-completion.

See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project[1])

Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)).

But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing.

I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing:

"7 Habits For Effective Text Editing 2.0": https://www.youtube.com/watch?v=p6K4iIMlouI

"Seven habits of effective text editing": http://www.moolenaar.net/habits.html

I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like 70% of the benefit of a true IDE, like a Smalltalk System coupled with a Object Database, or something simpler like a complete Forth system.

For better or worse, all current popular programming systems (that I'm aware of) has the hopeless abstraction of program text organized in file system files in folders (often coupled with half-integrated resource files, be they xml-layout, binary images, fonts or other stuff).

So no IDE can be effective, because the central abstraction remains only half-structured text, and you can only get that far with strapping semantic analysis on top. So as long as you're (forced to) working with text, programs that enable text editing and transformation will have an edge.

I don't think there's a wall between the two: you might want to use something like [1], or vim-mode in IDEA or something -- but if you want one effective tool to work with: Documentation, a handful of mark-up languages, a data language (like SQL), and a handful of programming languages (eg: assembler, C/C++, python), patch-files and perhaps writing email -- then I think text editors are going to be a good investment.

I do think that text editors (for writing code) is a kind of local maxima - but if we want to stick with traditional files and file systems (probably a terrible idea), they do help facilitate tools that have somewhat loose coupling (between editing, debugging, high-lighting, re-factoring, formatting) and I think that helps keep systems portable (you can take a similar set of C++ files and preform a similar set of transformation (with completely different tools) on Linux and Windows and end up with (different) binaries that preform a similar function.

Another great video that I think demonstrates text editing as different from "just" an IDE, is Russ Cox' short intro on ACME:

"A Tour of the Acme Editor": https://www.youtube.com/watch?v=dP1xVpMPn8M

In short, I suppose text editors are a superior user interface for interacting with text-like structures in general. The relative benefit for programmers depends a bit on what kind of system you work with: I'd prefer a simple, less verbose language, like Kotlin coupled with a plain editor, to an IDE coupled with more traditional Java (esp: Java 5) -- I firmly believe auto-generated code is a dark pattern: if it can be automated, it should be moved to a run-time or a library so that it can be maintained in one place, rather than leaving dead and possible buggy code in dark corners of a large code-base.

[1] http://eclim.org/

You're probably right about the autocompletion. I've never been able to get it to work particularly well in emacs (although I'm probably due another attempt). If you're focused on a particular target with a good IDE (i.e. Visual Studio, something by IntelliJ and probably nothing else) then they can be a good tool to use.

Among other things, I'm current developing some code for an Atmel chip. The environment for this is Atmel Studio (VisualStudio based), which has excellent Intellisense based autocomplete/navigation etc.. The thing is, I keep finding myself using emacs. Apart from the obvious 'force of habit' reasons for this, I think there are two factors:

1) Even with the autocomplete I still code faster in emacs. The various features like being able to load up multiple files at once on split windows, better facilities for swapping code around (I could go on) mean that it just goes faster. I still use the IDE for bits and pieces - it's particularly convenient for when I'm using unfamiliar parts ofthe hardware libraries - but I keep going back to emacs.

2) Developing for the Atmel is only ONE of the devices I'm targeting at the moment. I've got another ARM device (using Keil), a whole host of Python bits and pieces, a Windows GUI app. Being able to write the code for all of these in one place is unmatchable. Particularly as they interrelate and share code. It even helps the style look the same (where appropriate). A well configured emacs gives you a great development environment for anything.

For me, when I use an IDE I feel like I'm learning/using the IDE, not the language it self. I found that I was somewhat dependent on the IDE. Then I switched to vim and started learning how to actually build projects from the ground up.

I've noticed that a lot of people who use IDEs can't use anything else. Want to build an Android app? There are people who can not build an Android app without eclipse.

After learning Vim I was able to use it just like an IDE and I felt like I had a better understanding of how the projects I was building actually work.

The benefit is customization to your needs to make your unique workflow faster. There is a reason people spend tweaking their ".emacs.d" configurations - it just makes them so much faster. For example, I use a light theme in office because I have a glossy monitor and I prefer a dark theme otherwise, so I wrote a few lines of elisp to choose the light/dark theme based on the time of day and day of week. Try doing that in other editors / IDEs / etc. :) Of course, I'm quoting a trivial example here, but this is a glimpse to what is possible.

In a job setting, don't. Integration is more important at first. Emacs is a way of life. You got a lisp, with beautiful libraries (binary parser, ~bnf parsers, hashtables, trees) that allow you to parse, interact, render data as you see fit at the tip of your fingers.

Lisp systems are dynamic, you can extend/modify them on the fly. It's a bit ugly but for a personal experience it beats Eclipse plugins by far. Most IDEs are fixed and complicated to modify. The way they understand UI and UX are also often subpar (magit is way more effective than most IDE versionning interfaces I've seen).

Emacs ain't perfect (~fragile shell integration, old culture => weird defaults), but its value offset its warts.

ps: Oh, and I forgot, you also have a symbolic calculator. Always handy.

Vim is noted as the finest text editor. Emacs isn't a text editor, it's a superpower.

As someone who is most definitely on the Emacs side of the Emacs vs. vi debate, I agree with that statement.

In 20 or 40 years, emacs will still exist, as will the hooks and tools you've integrated and built up to support it.

VS, Eclipse, and IntellijIDEA very likely won't.

And I say that as someone who doesn't use Emacs much -- I'd learned it at one point and used it pretty heavily for a job, with a very nice set of modes for a proprietary software tool I was using at the time, but made the critical career error of working for an idiot boss who didn't believe any software other than what the vendor provided was necessary on corporate servers.

So yes, I use vim.

But I've learned ... at least a dozen editors and development environments which are either dead or proprietary and not availa ble to me. Time which I could have devoted to learning persistent tools and extending them.

That's among the strongest arguments in favour of using Free Software tools generally, from a technical PoV. Your knowledge tends to remain relevant far, far longer.

>In 20 or 40 years, emacs will still exist, as will the hooks and tools you've integrated and built up to support it.

> VS, Eclipse, and IntellijIDEA very likely won't.

Why do you think so ?

Intellij and Eclipse are both open source. I suspect they will be around as well. The companies supporting them may go out of business, but there are enough users for it at the moment that someone will be able to keep maintaining it or build new businesses around it.

Emacs is a very general and fundamental tool. It's "do one thing well" is "organise textual interactions, via lisp". And that ranges from editing to shell to numerous programming environments to email to web....

I'm actually thinking of picking up Emacs again as a preferred option to a browser.

Eclipse and Intellij may be open source (and I'm sufficiently unfamiliar with them that I'd blown that fact, thanks for the correction), but they're far narrower in scope. That itself tends to be a strike against. Even broadly-used tools -- say, Perl -- can be, pardon the term, eclipsed by others.

Mind to: learning multiple ways isn't a Bad Thing. But being highly mindful of what tends to survive and what doesn't is itself useful.

Emacs dates from glass TTYs, and has survived to mobile devices. I've seen enough of other tools to note the quirks of their own tech origins and how this has or hasn't limited them over the years.

So: consider mine a somewhat informed, somewhat uninformed opinion. Though I'd still strongly recommend Emacs as a durable, extensible, and exceedingly useful skill.

There is a difference between brand/product name and product itself. As @dredmorbius mentioned in a sibling comment, IDEs by definition do not "do one thing well" - various tools are integrated with varying degrees of tightness. Take old VS project, old Eclipse workspace and they have to be first converted to a new format. How can one be sure that there is 1:1 mapping between old and new formats? Having worked on VS6 does not guarantee that old tips&tricks will be valid in VS2016 or VS2030. Imagine if they decided to switch from VC to clang - it is integral part of VS and cannot be dismissed. Even though I'm not emacs user I'm pretty confident that overwhelming majority of what I learn today about the tool will be valid 20 years later.

Having worked on VS6 does not guarantee that old tips&tricks will be valid in VS2016 or VS2030.

They do if those tips&tricks include basic editing functions, which is what you're talking about if you're comparing it to vi/emacs.

My "tips and tricks" include how to read email and RSS/ATOM feeds in Emacs, which I do using Gnus.

In fact, reading email and RSS/ATOM in Gnus is also a tip/trick, since it was originally written (in 1987) for Usenet.

I'm not at all saying that others should use Emacs for their email. I'm pointing out that Emacs customisation can involve far more than "basic editing functions", and that these customisations can continue working for decades.

Point is, if you use emacs and vi, you're stuck doing basic editing functions in a different way than the rest of the world. We see vi users adapt to this by trying to cram vi plugins into everything, and emacs users by trying to cram everything into emacs.

Not stuck, empowered

After witnessing many of these discussions, it's just FUD. Just because Emacs is older doesn't mean that IntelliJ or Eclipse aren't likely to follow you until retirement. Java hit critical mass a long time ago and both IDEs have mass adoption and are also OSS, as you mentioned.

The POV presented in that comment is basically a sales pitch. It's too standardized and common not to be (it pops up in most of these threads).

There is an interesting rule from biological evolution of rates of extinction with species age that I'd thought of in relation to this. Essentially: they're constant. That is, a species is as likely ro go extinct when old as young: there is no increased survival probability with age.

Leigh Van Valen's Law of Extinction, related to the Red Queen Hypothesis.

https://en.wikipedia.org/wiki/Red_Queen_hypothesis

I don't know how well this translates to areas such as software, but it does give me pause.

Nassim Taleb disagrees with you https://mises.org/library/how-time-and-uncertainty-can-make-...

Eclipse, maybe not. But IntellijIDEA, I doubt that it will stay if Jetbrains goes away. They do not fully open source their IDE.

VS, Eclipse, and IntellijIDEA very likely won't.

Well, I hope they won't. But I'm sure their many common UI conventions will. Those conventions are shared between hundreds of thousands of apps already.

In 20 or 40 years, the Emacs UI will still rule only in a single program (and if we're unlucky maybe a few other tools still, like the readline library!).

As for vi, I'm sure some people will still be installing vi plugins everywhere to get 1/10th as smooth an experience as everyone else, and telling themselves they're more productive for it. Already these UI conventions developed for a line editor have outlived much of the generation that has ever used a line editor, so I'm sure it can go on for another 40 years!

> VS, Eclipse, and IntellijIDEA very likely won't.

VS was first released in 1997; Eclipse in 2001; and IntelliJ in 2001 as well. I wouldn't take that bet.

There's a subtle benefit that I haven't seen any of the other comments describe: the UI is made up of text, and I don't mean that in some curmudgeonly "things were better back in the day" way. I mean that all of the commands you use for navigating and manipulating text, moving between frames and windows and so on all use one consistent interface. With magit, I can be editing a file, hit Ctrl-C, g, then do some git manipulations and switch back to my work with a much smaller mental context switch.

And because all of the modes share that emacs feel (except for the vi-emulation, I guess), that knowledge is transferable across every language you work on, instead of learning a new (possibly proprietary) IDE for each new language.

Completely agree. I often got frustrated that the "modern" featureful IDEs don't allow me to incremental/regexp search in drop-down menu items nor to use set-mark-command + kill-ring-save keystrokes within dialog messages.

Disclaimer: I have only used vim and emacs, so I really don't know what an IDE can do.

Things I wish I knew about emacs earlier in life:

Emacs benifit plan volume 1:

* You will finally love the ui/ux for `info` pages

* macros (save and repeat a sequence of commands, commands can be applied to anything)

* registers (save locations in buffers, save text for later pasting)

* Frames (M-x speedbar for starters)

* modes (which to use and how to configure?!)

* built in documentation is awesome!

* what does this sequence of buttons do is only a `Ctr-h k <sequence of buttons>` away

* Mostly solid remote editing (tramp mode is no match for rsync on large files, luckily, RMS and friend have afforded us our freedom and we can configure this to our liking.)

* Freedom (as already identified by many people here but not by the word 'Freedom'. Also Freedom causes longevity. I have no source on this)

* Why is Freedom not number one on my silly list? If this were ORG mode I could bump it up to the top quickly.

* Excellent (multi-language (multi-language)) support. This is a recursive joke and the base case for me at least is English Bash. Emacs is language agnostic and language aware

* You will never have to write a 'throw-away' shell script ever again because emacs macros are that good. Still like shell scripting, incorporate shell commands in your macro.

* Carpel tunnel syndrom (cts) is a real thing, but, IMO, poor posture is more likely to give you health problems than cts. In reality, with Ctrl-R reverse search and Ctrl-S forward search, you can basically cycle through every command you have ever typed.

* Default key bindings in bash are emacs based and I actually enjoy the emacs bindings more than the vi ones despite spending lots of time in vim

Last reason: It's fun to play with a "real time display editor" and realize that emacs is an endless journey on the road to freedom in your ability to manipulate computation, however it may be expressed in years to come.

> Carpel tunnel syndrom (cts) is a real thing, but, IMO, poor posture is more likely to give you health problems than cts

Also, use sticky keys (https://en.wikipedia.org/wiki/Sticky_keys)

I use all software with sticky keys enabled and I can't go back to a state without sticky keys. I wonder why others also don't use it. Stick with it for two or three full days and I am certain that you will love not having to press shift to capitalise text or how easy it is to press the Ctrl keyboard shortcuts in general. Not to talk about how easy it makes Emacs usage.

For exampe, to paste the URLs above, I pressed Shift with my left pinky and pressed Insert with right pinky one after the other, easier than contorting (it feels so now, after using sticky keys for some time, earlier it was okay) hand to press Ctrl-V. Also, to open and close brackets is real easy, tap Shift then press 9.

>I recommend trying out sticky keys if your OS supports it, because your hands really feels better. It takes a while to switch mindset e.g. from M-x to M x (pressing one after the other), but it’s worth it. No less effective and less stress in the hands. - https://www.emacswiki.org/emacs/StickyModifiers

In Windows I place the sticky key icon in taskbar where I can see it instead of placing it inside the tray so that I can see the state of keys so as to avoid any confusion.

You'll love KeyChord (https://www.emacswiki.org/emacs/KeyChord).

Keychords are a bit of a pain in the ass if you type quickly and want to have mnemonic shortcuts.

Yes they are nice. I always become indecisive when it comes to assigning keys with keychord.

Also, Sticky keys are system-wide as it is an OS provided feature. It makes life very easy, for example, to select text, just click where you want to start selecting and go to end of your selection, tap shift and click mouse, selected. I wish more people give it a chance.

No genuine ones. There are some extremely few ones, but they're all related to "some people use emacs and it's good for you to fit in with them" (for instance, I recall a proof assistant some years ago which was painful to use without the associated emacs mode).

Any advantage gained from the interface are small enough that they're not worth introducing another mental mode for. Any time you sit down at a keyboard and have to mentally remap ("copy works differently here", "shortcuts are different here", "that thing you do all the time must be done in a very different way here"), it's mental capacity out the window. When you do a task, you want your interface to be as similar as possible to the interfaces you're used to when doing related tasks.

Emacs could have become the common, core interface for working on a computer (unlike vi, I'd say) - but it didn't. The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.

> Any time you sit down at a keyboard and have to mentally remap ("copy works differently here", "shortcuts are different here", "that thing you do all the time must be done in a very different way here"), it's mental capacity out the window.

That's true, which is why I use only Linux, only StumpWM, only emacs. Using anything else slows me down and gets in my way.

> The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.

There's nothing to master, because the languages those tools offer aren't expressive enough to require any mastering. They're two steps above pointing and grunting, while emacs is poetry.

I'm an emacs evangelist and I'll use Eclipse or IntelliJ for Java. I have half a mind to just use a windows VM for visual studio because I think it's a great Python IDE.

But then there's everything else.

I've looked a great deal for a decent javascript IDE and I have yet to find one outside of Emacs. For a lot of languages I end up using in short spurts, I appreciate having a text editor that can do what I need it to do, and can do it consistently regardless of what I throw at it.

If I have boilerplate that I need to set up, building a yasnippet template is a piece of cake. If I need syntax highlighting, it's almost guaranteed that someone has gone down that road and has a mode already set up. If I need to migrate to a new machine, I pull in my .emacs from my git repo.

Little things that might be a challenge - like opening a file over SSH or needing kerberos authentication in order to edit a file - are challenges that have long since been dealt with.

There were two videos that brought me back to Emacs after years of using other editors - one was about python development in Emacs when I was looking for a python IDE, the other was a video about org-mode.

It took me two weeks of forcing myself to use Emacs before the muscle memory came back and I started preferring Emacs over vi again.

I wouldn't be too concerned about whether or not you should migrate to it. Use what you know. When you have a need for the power of emacs, you can safely ignore it the first five or ten times it pops up.

Eventually, you'll wander into a video how-to like I did and turn to the dark side. Or not.

The biggest benefit of using Emacs is easily fixing and altering its behavior to meet your wants ... crafting your editor.

Haven't seen that one before, but well, congratulations for making me feel old. ;).

As a middle aged computer scientist and emacs evangelist, I had to laugh pretty hard at this one. I hadn't actually heard that one before.

:-)

This was already true back when I started using Emacs in my teens. Now that I'm middle-aged myself...

I read Middle Aged as in medieval, and saw lots of alchemist scribing lisp on parchments.

Generally Not Used Except by Middle Aged Computer Scientists.

Today I had to use non emacs windows editors for an hour. All of them a subset of what I'd like. I grabbed a copy of emacs for windows build. My blood pressure lowered as I saw the splash screen. Freedom and extensibility. It's impossible to fully appreciate right away. But having an appealing website is always good.

>the learning curve of emacs that isn't exactly beginner-friendly

I started to learn emacs in 2006 after a friend show it to me in it's no-window version in a OS X Teminal. We were at the time art students and most of us didn't have programing education. Some people were playing a bit of advanced flash or Max (proprietary Pure Data sound processing), but most of us were doing performing art, sculpture, sound or painting.

Honestly, I have been so motivated by what I discovered, that, the learning curve hasn't been so bad. The folkloric keyboard shortcuts were easy to memorize and the software never failed me. I stopped using Text Edit and the horrible .rtf format and I learned that plaintext was surely more appropriate to write poetry. And wait what is it? Markdown?

I started to open mp3s in text mode and grep into videos. It was really exciting. It was possible to open incredibly huge files in text mode, and the computer was still usable. Wait... Why common browsers slow the machine down when you try to open Gmail then?

I discovered a land of wonder full of funny animals, meaningful laws texts (I mean GNU license) and documentation to read until the end of your life.

In 2008 I ordered GNU Emacs Manual 16th edition with a tee shirt, the reference card is still on my desk.

This piece of software is usable, accessible, documented, and it is still possible to use it 30 years after it's creation. Let's be honest: what is the aim of having a fast-learning-curve if you learn tools that you won't use in 2 years. If the tool is a bit hard to learn but we'll designed, it maybe worth the effort.

Talk about judging a book by its cover. Did he say anything specific about the source of his discomfort? If I'm looking for a text editor, I'm not sure how it matters whether or not its web site is full of images, fonts and colorful reactive javascript modern HTML. All I need is a download link.

> All I need is a download link.

A download link is less useful if you want to find out about an editor vs just trying it (especially with Emacs when you first open the program, the killer features are not immediately apparent).

The old site showed a change log, which seems much for like a site for current users than a site for new users.

At least for me the change log is one of the first items I read when looking to try new software.

It often tells quite a lot about how involved the developers are, what direction the project is heading to, or how mature it is overall.

Prettiness signals professionalism and competence.

I'm not sure the new design is a good thing because using Emacs is like entering another world. If newbies have the impression that it's just another editor like all the others with fancy websites they will be quickly disappointed. On the other hand, if they are looking for something that challenges their understanding of what an editor, or software for that matter, should be then they may be motivated to overcome more hurdles such as an archaic homepage.

>He went to the website which looked incredibly outdated to the expectations of new programmers, and just felt uncomfortable giving it a try. He opted for an editor with a more modern website.

Sounds like a personal problem to me, I love most of the GNU projects' pages. Simple, readable, low-bandwidth, to the point.

https://web.archive.org/web/20160101125451/https://www.gnu.o... for ex

That's fairly shallow to base a decision to use an OS on.

All kidding aside though, it seriously is. It's not a bad piece of software.

Reply on news.ycombinator.com