Live data from Hacker News

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

media.emacsconf.org

111–120 of 272 posts

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

#111

Earlier quoted context omitted.

The main reason I quit Emacs was the lack of context and semantically aware code completion and re-factoring tools. Such tools are invaluable productivity boosts for me. I have never gotten that to work in Emacs to a satisfactory degree.

OTOH hlmost many modern IDEs can't even open two copies of the same file and display it side by side or record arbitrarily complex macros and play them back any number of times.

Don't know about the second, but displaying two copies of the same file side by side is pretty common in my experience, e.g.:

PyCharm: Yes

VS Code: Yes

Eclipse: Yes

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

#112

I am considering buying Intellij IDEA ultimate. Been testing pycharm Pro, and docker integration for specific OS settings, remote debugging, refactoring tools such as method extraction, package conversion, and terraform integration is a breeze. Any way I could set such an environment up in emacs?

i think it's fair that for big projects, you'll be fine with the IDE. I spend my days in emacs, Intelli-J/Rider, and VSCode...

I don't do a lot of code editing in emacs, except for usually dotfiles and other single file operations. I do do a lot of code reading in it, though. Rip-grepping through multiple projects, opening the interesting looking files in Emacs....and then when I think i have what I want, I'll usually open the parent project in VSCode or Rider to do some editing.

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

#113

Emacs - the editor that STILL doesn't have a simple way to duplicate the current line?

I think the germane point about Emacs here is that some people like writing Lisp and some people hate it. If you hate it Emacs is likely not going to be your best environment, and that’s fine. I really like writing Lisp so Emacs has a simple way of doing anything I want, but it’s not for everyone.

I don't hate or like lisp. It's just another programming language which does the job.

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

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

Emacs is almost infinitely tweakable, but it's also very stable, so your tweaks tend to have long-term value. This seems to go against the grain of most nontechnical software, like Firefox or Microsoft Windows, where there is no stable UI and new versions typically break customizations with no recourse.

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

#115
post #96
post #72

Earlier quoted context omitted.

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…

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.

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

#117
post #2

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…

My .emacs on this machine is almost literally this:

  (custom-set-variables
   '(indent-tabs-mode nil)
   '(inhibit-startup-screen t)
   '(menu-bar-mode nil)
   '(show-paren-mode t)
   '(tool-bar-mode nil))
On my home computer I have somewhat more involved .emacs, but apart from the above (and huge list of totally random variables picked up by customize-save-customized since 2003) it consists of long-irrelevant compatibility hacks and somewhat complex logic for creating correctly sized frames on additional X displays (which I stopped really using when I got 4k monitor)

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

#118
post #103
post #2

Oh Emacs. A graybeard I respect got me to try it about 5 years ago. I used to walk by his machine and think "wow, in a movie about a hacker, this is what their computer screen would look like". I also thought Magit was pretty damn cool because it made interacting with Git extremely intuitive (once you're comfortable with Emacs). In the years since first picking up Emacs, I have probably spent 100 hours or more config…

I've been using Emacs for 40 years. My .emacs file is 59 lines long. Most of the customizations turn off features have been added (menu bars and so forth), or that disable "helpful brain damage" that simply got in the way. I've spent 2-3 hours over the last decade tweaking things.

Same. It's a bit like Dvorak. Yes, in theory you could make your life 10% better by carefully customizing, but there's also great value in just sticking with the default for the most part. You can sit down anywhere and everything just works.

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

#119

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

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

#120

Earlier quoted context omitted.

The main reason I quit Emacs was the lack of context and semantically aware code completion and re-factoring tools. Such tools are invaluable productivity boosts for me. I have never gotten that to work in Emacs to a satisfactory degree.

OTOH hlmost many modern IDEs can't even open two copies of the same file and display it side by side or record arbitrarily complex macros and play them back any number of times.

Completion and refactoring are much more important than these.

When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually.

When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool.

Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.

Post reply on HN