Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

media.emacsconf.org

Post reply on HN
Print view View original

191–200 of 272 posts

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

#191

Post by theCodeStig »

gchamonlive wrote: post #62

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?

JetBrains editors are superbly good at refactoring, IMO that's their one only advantage.

Consider working primarily in an editor with LSP support (such as Emacs) and use JetBrains on the side solely for refactoring. Wean yourself off of JetBrains, as LSP improves.

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

#192

Post by sooheon »

na85 wrote: post #83
slightwinder wrote: post #70

Earlier quoted context omitted.

There may be much going on with emacs, but so far it fails to move ahead. The project is just improving the old strenghts, but not fixing the old fails. And as time moves, they start to hurt more and more and more until they break.

What are some old fails that need fixed?

One thing I notice: too many things cause unresponsiveness. 8 cores in my laptop and I can't install a package in the background, and semantic parsing interrupts typing. There doesn't seem to be any concurrency at all, things I do every day like eval'ing forms to REPL cause stutters.

I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.

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

#193

Post by banachtarski »

nandkeypull wrote: post #10

Emacs has really undergone a renaissance in the past decade - magit, LSP, ivy, spacemacs, doom emacs - there have been so many novel new packages and frameworks written by elisp hackers. For such an old editor, the development scene feels incredibly alive.

I'd agree that LSP has been a huge boon to the ecosystem. Spacemacs I feel has had the opposite effect. It hasn't had an "official" release since Jan 2018, and there are TONS of lame and fixed bugs that persist in the mainline. I actively recommend people NOT to use spacemacs because of how broken the release process is. It really feels like the maintainer(s) simply does not have the time to devote and it has vastly outgrown what I think is reasonable.

After quitting spacemacs, it was refreshing. I do not believe a "meta package" system is correct. Each individual maintainer should be able to update and release their plugins with an independent cadence. Imagine if VSCode extension releases were all gated by a single point of failure... Nobody would use it (and rightfully so).

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

#194

Post by alephx »

stevenwoo wrote: post #180
eddieh wrote: 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…

Hey I suggest you try installing it on WSL (Windows Subsystem for Linux). I tried it just last week to do some hacking different from my usual C#/Visual Studio development and was pleasantly surprised it mostly worked out of the box. To render more nicely I had to install X Window for Windows (can't remember the exact name of the library) but it was pretty much a very good experience. Only limitation I can think is you should not access linux files from Windows, but the other way around has no problem.

Also (may be different from your use case), using tramp-mode has mostly eliminated the need to run the emacs inside the server, I run it locally and fetches files using ssh.

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

#195

Post by sooheon »

ant6n wrote: post #150
chapium wrote: post #139

Earlier quoted context omitted.

I don't get where that is broken.

On other operating systems, alt+tab goes to through the list of least recently used windows. So when working between two windows, one hotkey switches between them. On Mac, that's not possible if the two windows are part of the same app (or also when windows are distributed across multiple work spaces).

Being able to switch between apps, windows, and tabs is different from just windows and tabs. I prefer the former because the hierarchy allows you to find arbitrary things with fewer keypresses overall (as opposed to mashing alt-tab through a long flat list).

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

#196

Post by pjmlp »

jwr wrote: 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…

Emacs for me was always a poor replacement for my Borland and SlickEdit developer experience.

Actually during my UNIX phase, I rather used XEmacs, as it provided much more friendly tooling than Emacs.

Nowadays Emacs really fails short from what Java and .NET environments offer out of the box, specially in graphical tooling. Including mixed language development with C++.

It is also interesting that James Gosling nowadays prefers IDEs as any UNIX editor, as stated in several interviews.

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

#197

Post by mgsb »

dleslie wrote: post #72
jwr wrote: 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 had a similar experience with Emacs LSP earlier, but I revisited last week and things have significantly improved for C/C++. lsp-mode and ccls work great, even with cross-compiling. Just two small use-package additions to init.el and "it just works". I will also say I tried VSCode this week using the same compile_commands.json, and it is impressive.

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

#198

Post by pjmlp »

mickeyp wrote: 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.

I used XEmacs during about 10 years, after a teacher in the classroom notice how poorly we were using it, and instead of spending an hour talking about programming in Pascal, it spent the hour teaching Emacs tips and tricks.

However, it is no match for modern IDEs tooling.

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

#199

Post by taeric »

worldsayshi wrote: post #79
lorenzhs wrote: post #64

Earlier quoted context omitted.

Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.

I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.

Thanks for that link. I confess I have my own prejudices against LSP. This view just strengthened it some.

Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.

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

#200

Post by DoingIsLearning »

petilon wrote: post #61

I have been using Emacs for about 20 years, and I love that you can use it on Windows and Linux and character mode and GUI. Love the programmability and the keyboard shortcuts. Where it sucks though is programming language smarts such as "intellisense" completion. Even something basic such as syntax coloring doesn't work reliably--depends on the mode implementation and most of them are buggy. I get by in other editor…

I am not sure what languages you are working with but have you tried Language Support Protocol lsp-mode?

https://langserver.org/

Post reply on HN