Hacker News Reader

>Being a very powerful personal computing environment and kinda fun to use, to me emacs still falls short in the ways that, for instance, UNIX command line interface with its simple single-purpose utilities never did.

Amusingly, I'm the opposite. Emacs to me is more consistent than the UNIX command line interface, and I feel Emacs satisfies the Unix philosophy better than the command line itself does.

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

When people write "applications" on top of Emacs, they frequently come with APIs that let people utilize individual features. Part of the reason org-mode is so successful is its ability to leverage features from many other applications built on top of Emacs (mail, links, calendar, image viewing, etc).

Except for the few core Unix tools, most console applications in Unix do not provide as much flexibility through the command line interface. Nor do they come with APIs that let others build upon them.

To someone not well versed with Emacs, what I'm saying may sound crazy, as for many people, the extent Unix tools do provide these switches/APIs is very satisfactory. But it's not even close compared to Emacs.

This is why when I started my job and we work purely on Windows machines, I had no problem. I installed Emacs for Windows, and had access to much that I used to in Linux.

If you don't use Emacs, what do you use?

Visual Studio? What if you are on a Mac? Xcode?, what about linux? Code blocks?

And then what about email and tasks? Gmail? Outlook? Wunderlist?

And notes? Google Keep? Evernote?, wait, no Onenote!, but then they dont have a linux client.

What about file management? Total commander on a PC?, Forklift on a mac? and mc on Ubuntu?

What about sharing settings and shortcuts between all these across multiple OSs?

I use Emacs for all this and it works the same on every OS.

It's a portable OS/Lisp Machine.

I think that's pretty crummy you're getting downvoted for this kind of remark.

I myself tend to agree with you, as a former Emacs user of maybe 10, 15 years. For the things I used to use Emacs for (C, make files, only crude version control integration, etc) I'm sure it'd still do fine. What I found, though, is that my workflow and habits changed, and Emacs couldn't keep up. Or rather, there are good-looking, easy-to-use tools that support my workflow out of the box, and having to spend a day futzing with my editor just to get the same workflow functionality lost its luster a long time ago. Visual Studio Code, for example, it does great intellisense and Git integration without having to do a thing. And I don't really mind having to use the mouse more, because, frankly speaking, I type a lot less than I think these days; I just spend less time on the mechanical act of typing lines of code than I used to, so keeping my hands on the keyboard is less important than it used to be for me.

So for me, Emacs is, as you said, a historical artifact. The tools I use today simply work better for how I work, and even though Emacs could be molded in just about any direction, I no longer feel like it's worth the trade-off. Tools like VSC are good enough, right now.

Well, what about when you want to refactor Java, or get syntax highlighting on Scheme code, or want autocompletion in your Python?

I'd rather learn one tool once, than re-learn text editing every time my requirements change.

Hey, that's great, I'm glad that works for you. I'd rather pick the best tool for the job, and learn it, than try to make was was for me a mediocre tool less mediocre.

If I were, for example, editing Java at any great amount, I'd probably look to one of those popular Java editors (I've heard good things about, I think it's called, IntelliJ?). I'd wager money it's more finely tuned for working in Java than Emacs will ever be, just because there's people who want to keep making money to write it.

And so on.

Like I said, if I were still just writing code like I used to, in an earlier stage of my career, I'd probably be satisfied with Emacs. I moved on, though, and do different things. When faced with a choice of learning new, good tools and trying to hold onto my old mediocre tools, well, I'll pick the learnin'. I think I've ended up more productive, anyway.

...And I think the phrase "mediocre" is where we disagree. Java is perhaps the worst example, but there are languages whose emacs modes are simply unbeatable. The lisps, in particular, but there are others. And if the tools aren't good enough, they can be improved.

Give a man an IDE, and he'll have the tools that IDE provides. Give a man Emacs, and he'll have whatever tools he wishes.

OTOH, you may well have ended up more productive for the kind of work you do. Your tools, your choice. I am willing to respect your decision.

Showing respect for the subjective deserves, well, respect. But it is the insight into the objective that is interesting, and I think that it should be recognized as a law of Nature that if something (or someone, for that matter) is trying to be good at everything, it (or they) is bound to be not very good at anything in particular. I am not seeing, for instance, how emacs can come even close to what IntelliJ has to offer to Java developers - short of having a faithful IntelliJ clone written in elisp, of course.

Ouch. I did my best... I shall try harder next time.

My point was that while Emacs certainly isn't as capable as IntelliJ is at the moment, It's possible to build those features upon IntelliJ. An attempt to build Emacs's featureset on IntelliJ, OTOH, would crash and burn.

Emacs doesn't try to be good at everything - not in the conventional sense, because Emacs is a platform. There's a lot of software built atop it, but they're all really good at one thing: Paredit isn't Org, which isn't Geiser, which isn't Flycheck, which isn't etags.

FWIW, I've thought this whole exchange was both useful and respectful, even though we obviously disagree. :)

IntelliJ is a good example, because you're right, you could extend Emacs to have a looks-and-works-exactly-like-IntelliJ mode. But now you've got two jobs, writing your Java and developing and polishing up your editor in elisp.

Or, for my current favorite editor, Visual Studio Code, immediately upon launching it you get intellisense via Omnisharp, really decent git integration, all the integration you'd need with dotnet core, and a ton of convenient stuff like search/replace across the whole project, refactoring that works well for C# project, etc.

Could this all be reproduced in elisp? Absolutely, I have no doubt. Has anyone put together a package to do so? Nope, though of course there are disparate packages to solve/simplify/address these things. Will anyone create one package? Nah. Will anyone bring it up to the level of polish that VSC provides out of the box? Definitely not.

Much as I like Emacs, and I really did, when I started trying out new modern editors I felt like I'd been living in a cave.

Actually, just writing this all out has made me realize that the biggest dealbreaker for me is the lack of polish. Seeing what a modern dev experience is like, I couldn't go back.

Thanks.

Yeah, I don't mind the lack of polish as much as you do. And I primarily work in scheme and lisp, where there's not much out there that can beat emacs (apparently, there are a few that people swear by. If you have a couple grand on hand, you can try them). The write/eval/test loop is so short and clean. And there's integrated documentation and tab completion.

...I think you're forgetting something about Emacs: It's not just an environment (I for one don't browse my mail in Emacs: I can't get the emacs mail clients to work), it's also a text editor with unbeatable extensibility. To this day, there is not a text editor I know of that is both as extensible, and has had that feature utilized as throughly. In many editors, extensibility is actually an afterthought (cough cough vim cough cough). There is integration with almost every language and tool that exists, and a few that don't anymore.

That is what makes it an amazing programming environment.

I use a pretty vanilla Emacs. The only customizations I do are:

- removing clutter (zapping toolbars, splash screens and the ilk)

- making very small tweaks to keyboard bindings so that it works more like Epsilon

I don't think that any of the Emacs improvements made over the last decade or more have done anything to my quality of life in Emacs. Rather, each release is more "what do I have to turn off this time?"

Fortunately, getting to bare-bones Emacs is not hard; with commercial editors it's often much harder to undo the damage of gratuitous "marketing checkbox" features. [I'm looking at you, Visual Studio 2013...]

Why would you use a vanilla emacs? Paredit, js2, magit, there are so many excellent extensions that can improve your workflow. If you're using lisp/scheme, SLIME/Geiser is indispensible.

I mostly work in C-like languages (and Python). Vanilla Emacs is just about all I need. I don't treat it as many people seem to use it, namely "enter Emacs once, then use it as an environment for hours."

Also, I learned Emacs in 1979, and it's pretty much wired into my muscle memory. Getting things back to an I-don't-have-to-think-about-it state is important, and whiz-bang features just get in the way most of the time.

Ah. Okay, that makes sense.

+100 for 'what do i turn off this time'

every release there is more and more 'sexiness' that breaks useful functionality. i can't even comprehend what someone did to gud.

it used to be that you opened up a tgz and it would nicely display a dired mode of the contents. not for a long time.

and c indenting used to just work- now it seems to be confused by looking for patterns that exist by convention, not as any part of the language specification...so indenting just doesn't work a lot of the time

and for some reason someone with truly awful taste gets to choose the color schemes for highlighting (font-lock). i used to be able to just turn it off...but that becomes increasingly difficult

for a 30 years emacs user, it just keeps getting worse all the time

Font-lock is pretty easy to turn off. But then, the first thing I did when I installed Emacs was change the colorscheme to solarized dark, something I would reccomend to anybody.

As for the rest... I have no idea. There are a variety of C indent styles, and most are fairly standard (K&R, GNU, Linux, etc.), so I'm puzzled as to why it doesn't work, especially considering that CC mode has to also support C++ and Java, and so can't get too specific. If it really does suck that badly though, I'd hunt around for an alternate package.

There are nice tools like "which-key" which massively reduce the work of remembering shortcuts. They are, incidentally, only shortcuts. The menus work as well.

That's a great tool. Thanks.

Don't let the age of emacs fool you into thinking it is somehow less relevant. Simple and good ideas are usually old. Compare the complexity of writing a "plugin" in Visual Studio or Eclipse. Similarly the command-line is here to stay.

There are packages such as "which-key" that can help by providing popup choices.

Command line lacks reflectivity and extensibility [1] that emacs can provide.

That said I've seen some people being more efficient in command line than I've ever been even with the most effective emacs extensions so ..

ps[1]: also higher level and consistency, I like to live in atoms, integers and lists and not regexp and file land

Shells and /_/nix philosophy are a 4th generation query and data munging language with seamless extensibility.

Emacs is an perhaps the most ambitious implementation of a layer above shells and /_/nix philosophy.

The problem I have with Emacs is the surface area feels infinitly large and some features can be buggy.

I choose to use both.

At risk of coming off as flippant or mean, I think you completely missed the point. It is a productive and stable editor environment which runs in various ways across all major computer platforms. It has a veritable mountain of established extension code, modes for performing tasks outside of software development, and portable configuration. The keybindings are considerably more consistent than the alternatives, and if you don't remember them you can always use the in-built searchable help system, or try to tab complete it in the M-x prompt.

These things are not 'historical', they are the things which have been so permanent that after thirty years they are still useful.