Live data from Hacker News

Emacs: The Editor for the Next Forty Years [video]

media.emacsconf.org

91–100 of 272 posts

Re: Emacs: The Editor for the Next Forty Years [video]

#91

Earlier quoted context omitted.

It very well could be. Attempting to either adapt yourself to emacs, or emacs to you, can take a long time, and may also fail. Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.

> The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor. This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.

It can. The thing I like about some of the other IDEs though is that it doesn't tear down the entire process; the plugins are sandboxed. Is this possible in Emacs? I'd be shocked if the answer is no. But most major modes I've personally interacted with are not.

Re: Emacs: The Editor for the Next Forty Years [video]

#92
On the note in the video about irc, I think there is room to update irc but keep it going. Right now as an in between I'm leaning towards a mumble/irc setup. The only other two things that really catch my eye are matrix and mattermost (which has a jitsi integration).

I hate the trend to proprietary chat apps so much. After years of ventrillo and teamspeak, around 2009 I discovered mumble and was using it for years, but in the last ~1year or so everyone started switching to freaking Discord and it drives me crazy.

Re: Emacs: The Editor for the Next Forty Years [video]

#93
post #68
post #48

Emacs turns disjoint environments, languages, and activities into a (mostly) streamlined system of workflows and idioms. Explaining just how powerful that is to people who don't use Emacs is difficult. People need to sit with you for an hour or so and watch you work to truly appreciate just what that means.

There's a certain class of programmers tool that requires constant tweaking, like a road bike used in the city - and typically the users suffer from OCD or stockholm syndrome, because they won't stop evangelizing. I thought emacs was one of THOSE types of tools and the initial experience does nothing to disabuse that. On my 4th or 5th attempt to start using emacs I finally decided to get over the hump even if it took…

Curious, can you identify what anything specific that changed the your thinking that it was THAT type of tool?

Re: Emacs: The Editor for the Next Forty Years [video]

#94
post #8

So the slides say... > Concurrency safety isn’t an accident. So far,only Rust has a good story on concurrency thanks to its type system. Is that really true? I've really enjoyed concurrency in D. http://jordi.inversethought.com/blog/advent-of-d/#day18 How much better can it be? And yes, D's concurrency is also based around types.

> How much better can it be? Rust guarantees that a data-race is a compilation error. D.. does not guarantee anything.. a data-race won't even give you a run-time error.. So... since going from D to Rust is going from zero to all guarantees, I think it is fair to say that Rust is technically infinitely better. FWIW this is not D's fault, most safe mainstream languages do not guarantee the absence of data-races (e.g.…

There's a lot more to correct concurrency than data races, although they are a big factor. I think it's more fare to say that going from D to Rust is going from zero to some guarantees. Still technically infinitely better.

Re: Emacs: The Editor for the Next Forty Years [video]

#95
post #3

(from the slides) >I learned Emacs in September, 1983 >It is now November, 2019 >...that’s over thirty six years! >An amazingly long time. Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it. I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental im…

No, productivity has increased massively, but not due to better editors or IDEs. Those have shown only marginal improvements, if any. (Is any modern environment more productive than a Lisp Machine or Smalltalk?) But some of the main productivity drivers are distributed version control systems, dependency management libraries, and sites like GitHub for sharing code and libraries. Being able to automatically generate a…

Have you ever used ReSharper or IntelliJ IDEA for any real work? I think not.

Re: Emacs: The Editor for the Next Forty Years [video]

#96
post #72
post #5

There are lines in my Emacs config files that are older than some of the programmers I work with, so I can relate. Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result. I do not know of a better environment for multi-language program…

And it will only get better once it understands LSP, better than it does now. It's a pale copy of VSCode's incredible LSP implementation: for a user, simply clicking the button to install the extension automagically configures a fully functional language environment; even for C++. Most of the time. When last I tried to get decent C++ support working with Emacs, about a year ago, it was still a mess of compiling rtags…

I've been using Emacs' lsp-mode (https://github.com/emacs-lsp/lsp-mode) for professional Python development for months now and it's been a great experience. It requires a little more work than I'd like to get it working with virtual environments (making sure the LSP server process is running in your venv, mainly), but I would argue that's a problem with the Python ecosystem, not lsp-mode itself.

And for statically typed languages (I've tried Rust and Go) the lsp-mode experience is flawless and works out of the box.

Re: Emacs: The Editor for the Next Forty Years [video]

#97
post #74
post #47

I really started to get lost when he started talking about never wanting to leave his text editor, wanting to read his emails in Emacs, browse the web in Emacs, have slack and discord in Emacs, etc. Serious question: Why? Is it that hard to alt+tab? Especially, why would you want such distracting features inside your editor, while you are trying to focus and work?

It helps if you reframe your question. Emacs facilitates working outside of silos. If you're using Outlook for e-mail, for example, there are some built-in mini-silos you can interoperate with (decent calendaring, decent contacts database, fairly simplistic task management, etc.), but if you want to take notes about an e-mail you received, you might end up alt-tabbing to OneNote and then pasting some text, then writi…

And, I would add, in an entirely keyboard-driven way. I appreciate, as an Emacs user, how much I can get done without using the mouse.

Re: Emacs: The Editor for the Next Forty Years [video]

#99
post #80

I've been writing Clojure lately but I'm a greybeard (literally) Vi/Vim user. vim-fireplace is nice but I can't help wonder if I'm losing something by not using Emacs. At the same time, Clojure is so wonderfully different from the other languages I know that I don't feel like I have the cycles to learn a new editor at the same time I'm learning a new language. Then again, maybe that's the best time to learn Emacs?

I've never used Fireplace, so I can't speak to the comparison. But CIDER (the Emacs Clojure IDE) is an utter joy to use - I can't recommend it enough. If you do try it out, I would be interested to hear how it compares to Fireplace.

Re: Emacs: The Editor for the Next Forty Years [video]

#100
post #98

I changed Emacs for Sublime and now VScode - my main reason to change IIRC was that my fingers/wrist hurt from using chords so much :(

How does Sublime or VSCode help with that? Emacs has evil mode which enables a vi style interface.
Post reply on HN