Live data from Hacker News

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

media.emacsconf.org

211–220 of 272 posts

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

#211

Earlier quoted context omitted.

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…

The sad part is that text based representations of programs are holding back programmer productivity by raising the bar for these refactoring tools unreasonably. If programs were represented and edited directly as syntax trees, 80 to 90 percent of the complexity of refactoring tools would go away.

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

#212

I hope you excuse me for a shameless plug, but it seems like a relevant enough thread to share my podcast about Emacs: https://emacscast.org/ While it might seem strange to discuss a text editor in the audio format, I've been getting positive feedback on this project as I try to talk more about underlying philosophy and mindset, not specific details or settings.

My feedback for you is you need to give listeners a reason to keep listening to your podcast right away, you simply can not go on a meandering personal discussion about yourself for the first 10 minutes of a podcast and expect to retain my attention.

Sheesh, give a person a chance. I'll give their podcast a listen based on the episode titles alone.

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

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

I largely agree, though to be fair, I did spend quite a bit of time tweaking my config and learning elisp during the first two years. At the time I was a PhD student and could afford it, but today? not sure. It was quite an investment of time but since I spend my days mostly processing text (code and prose) it paid off spectacularly well. Side note: Emacs is massively underappreciated as a tool for writing prose. So many wonderful tools that make writing more effective and pleasant.

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

#214
post #196

Earlier quoted context omitted.

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 nowad…

No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs. Personally I use emacs over vscode due to following reasons, 1. it does not waste CPU cycle in rendering html, we have browsers for it. 2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles, 3. and last but not the least does one thing very well whic…

It doesn't do any kind of graphical tooling.

IDEs also don't waste CPU cycles displaying HTML.

C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.

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

#216
post #196

Earlier quoted context omitted.

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 nowad…

No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs. Personally I use emacs over vscode due to following reasons, 1. it does not waste CPU cycle in rendering html, we have browsers for it. 2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles, 3. and last but not the least does one thing very well whic…

What you list here basically means you prefer terminal to GUI, not specific to emacs. Swap emacs for vim and most still apply. :)

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

#217
post #50

Emacs (and may be Vim) - Not sure, but seems like it got support for all the programming languages under sun. Thanks to all those awesome people who put effort over the years.

My killer feature is when you want to streamline your workflow. Adding a new test runner on VSCode for your favourite language? Possible but takes a lot of effort to get right. Adding one in emacs? I can inspect the source code or my language bindings and add/change the command it’s running. In a few dozen lines of elisp I can add shortcuts to all my daily tasks and even combine them. Search for an error message I get in my tests on Honeybadger? Check. Run code snippets in org mode against my local machine and export the whole document as PDF or markdown to our wiki? Saves me a few minutes here and there

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

#218
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 takes mental effort. Imagine your coworker asks you which version of your app is running on staging and if the latest modification runs without throwing an error. Sure, alt-tab to your terminal and 5 commands later you’re in your app‘s repl to answer that but by then you had to switch your context. Opening your custom helm search for your servers which then displays a new window with your docker instances on staging plus pressing enter to dial into a repl session there is not only convenient, it reduces mental effort

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

#219
post #181
post #40

Earlier quoted context omitted.

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.

In the 80s and early 90s most people didn't have internet.

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

#220

Earlier quoted context omitted.

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…

The sad part is that text based representations of programs are holding back programmer productivity by raising the bar for these refactoring tools unreasonably. If programs were represented and edited directly as syntax trees, 80 to 90 percent of the complexity of refactoring tools would go away.

On the other hand, when writing new code it is quite efficient to simply type, supported with proper completion.

It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree.

So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes.

An efficient text editor with completion + powerful refactoring. This is the winning combination.

Post reply on HN