Live data from Hacker News

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

media.emacsconf.org

181–190 of 272 posts

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

#181
post #40

Earlier quoted context omitted.

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…

Massive increase in personal computer power (cloud or physical). Internet and resources like stack overflow. Back in the days, I remember the isolation. First from the domain, we could only run part of the application or use unnaturally tiny dataset meaning that the application behaviour in prod was an abstract concept. Hell, we could not even build the app at all on large application. Second from knowledge. If you d…

>Back in the days, I remember the isolation.

There were newsgroups, basically SO on comp.* subgroups.

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

#182

Earlier quoted context omitted.

I think users of VI or emacs has different ways of defining "good" here. Personally, I would never use VS Code, or any other chromium editor.

Is this due to some notion of it being slow? VSCode is fast, native-fast. With a fantastic plugin ecosystem I've been a full-time Vim user for the past decade (now NeoVim) but I've seriously considered switching, VSCode with vim mode turned on is truly fantastic, it's just not portable enough for my needs.

> VSCode is fast, native-fast.

Not when starting up…

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

#183
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…

> Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration.

Hear hear. I've been using Emacs since the late 70s when my int file was a compiled TECO library that other people also used.

Nowadays my init file is only a few dozen lines and when I log into some random machine (with no init file) most things simply work without surprising me.

It is highly customizable but it doesn't mean it must be customized.

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

#184
post #95

Earlier quoted context omitted.

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.

I used IntelliJ for a couple of years and it was quite painful compared to the lispm. The only advantage is that the machines are faster.

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

#185
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…

"Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration." This is true, to an extent. I have not touched my current Emacs configuration in about 6 months now, but it took years of tweaking and probably hundreds of hours to get it to a state where Emacs was mostly the way I wanted it... though it'll never really be complete, as there are still a lot of things I'd…

> So, overall, it has the potential to be a great time suck

The most important productivity step is to launch your editor.

Unfortunately if every time you launch your editor, you get distracted by the editor itself... Well, your init.el will be well maintained. :)

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

#186
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.

tramp mode really helps span environments.

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

#187
post #96

Earlier quoted context omitted.

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…

I switched from emacs to Pycharm for python development, out of frustration with what most packaged tools was getting me, relative to what PyCharm did with no effort and little frustration at all. Too many half-maintained packages, put together, fighting incompatibilities. However, LSP really may change that.

LSP will definitely change that.

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

#188

Earlier quoted context omitted.

Same here. I've tried getting into Emacs for a couple days but gave up. It would mean a lot of effort just to achieve a similar proficiency, for little gain(better syntax highlighting, a few small features). I think the deeper you're already in one of the ecosystems the harder it becomes to switch and the returns diminish further. In my case I'm very comfortable with Vim combined with a tiling window manager and term…

Emacs has recently been seeing a lot of growth from vim users who are migrating to emacs "distros" (like spacemacs and doom) that are pre-configured with emacs' vim-emulation. I found this video[0] a pretty interesting perspective from a die-hard vim user who switched. [0]: https://www.youtube.com/watch?v=JWD1Fpdd4Pc

I've tried those already. Evil, Spacemacs, Doom. All except Doom have a misbehaving Escape key, Spacemacs needs as long to start up as one of the Electron-based editors.

In the end it comes down to this: I don't need Emacs. I've tried to find a feature that I really want and that's worth it to switch for(yes, I also tried org mode). But I'm comfortable with my Vim setup, I don't need an email client or web browser in the text editor.

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

#189

I've noticed that (almost?) any talk about any editor in the last few years: emacs, vim, sublime, atom etc always brings up how good VS Code is. It's a huge endorsement of VS code.

I'm a diehard Emacs (+evil) user, and I tried VS Code for a few months. It really is quite good. Here are the few detractors that brought me back to Emacs as my primary editor.

Lousy macro support from the Vim emulator. Evil is still leaps-and-bounds above anything else (possibly Vim itself).

Flexibility of split windows. I like to view multiple files side-by-side. From my experience, Emacs and Vim have the best support for split panes; whereas VS Code and JetBrains editors have the worst.

VS Code has nothing like Magit. In my time with VS Code, I would keep Emacs open in another space for git.

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

#190
post #148

Earlier quoted context omitted.

Hmm. I think it plays really well with macOS's windowing system. What am I missing?

I use emacs in my OSX Terminal windows without issue. When I've tried using it in Windows with vagrant ubuntu vm's, it does wonky things on screen redraws and clears but does not redraw - probably something fixable but I could not figure it out and just moved to Visual Studio Code for now on Windows. I speculate it's a Windows specific issue for running in a command prompt, for instance there's weird key combo for us…

Just to clarify this: You tried to use emacs on Windows in Ubuntu VMs and are asking it to compare to native performance of tools like VS Code? Have you considered running a native Emacs build too and see if that performs better?
Post reply on HN