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…
Emacs: The Editor for the Next Forty Years [video]
211–220 of 272 posts
Re: Emacs: The Editor for the Next Forty Years [video]
#212I 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.
Re: Emacs: The Editor for the Next Forty Years [video]
#213There 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…
Re: Emacs: The Editor for the Next Forty Years [video]
#214Earlier 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…
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]
#215Re: Emacs: The Editor for the Next Forty Years [video]
#216Earlier 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…
Re: Emacs: The Editor for the Next Forty Years [video]
#217Emacs (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.
Re: Emacs: The Editor for the Next Forty Years [video]
#218I 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?
Re: Emacs: The Editor for the Next Forty Years [video]
#219Earlier 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.
Re: Emacs: The Editor for the Next Forty Years [video]
#220Earlier 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.
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.