Live data from Hacker News

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

media.emacsconf.org

31–40 of 272 posts

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

#31

Earlier quoted context omitted.

But I mean, that's not Emacs fault?

It very well could be. Attempting to either adapt yourself to emacs, or emacs to you, can take a long time, and may also fail. Not to mention that, as much as I love emacs and other free software, bugs in your tools can absolutely destroy a day. The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.

> The last time I tried emacs, a bug in the golang major mode that hung emacs in an infinite loop ruined a few days before I moved (back) to another editor.

This can happen just as easily by installing a buggy plugin in any other IDE. I love IntelliJ, but have definitely lost time trying to figure out how to make something work or configure it to my liking.

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

#33
post #3

(from the slides) >I learned Emacs in September, 1983 >It is now November, 2019 >...that’s over thirty six years! >An amazingly long time. Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it. I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental im…

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.

This is true for me too.

I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors.

Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.

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

#34
post #22

Earlier quoted context omitted.

Different editors have different patterns of usage. I find I roughly speaking never duplicate lines, so why would this be a problem?

I constantly find myself duplicate lines in vim (shift+y). You've never had to edit a line that's really similar to another? Or when debugging, I don't want to change the old code, so I copy the line, comment it out, and work with the duplicated line. You've never had to do that?

Well, everyone edits things in different ways.

The Emacs way of solving a workflow problem is instructing Emacs how to solve it for you. For instance, you mention:

1. Copy the line the cursor (point) is on;

2. Insert the copied line below/above point;

3. Commenting out the line you copied;

By the sound of things you do 1 and 2 with a command in Vim and the 3rd option with another command. In Emacs, I would simply program a function to do all 3 and bind it to a key.

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

#35

I'm new to Emacs, but enjoying it very much. Just got mu4e working with Gmail XOAUTH2 (for a G Suite account that the administrators have implemented their own "delightful login experience"). Would there be any interest in reading a writeup?

Hell yeah.

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

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

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

#37

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

I don't think it's that hard to do C-a, C-k then C-y as many times as you want.

If you want to bind it to a key you could record that as a macro for e.g., but I find that sequence is simple enough that I don't think hard about it

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

#38

I'm new to Emacs, but enjoying it very much. Just got mu4e working with Gmail XOAUTH2 (for a G Suite account that the administrators have implemented their own "delightful login experience"). Would there be any interest in reading a writeup?

Yes please!

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

#39

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.

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

#40
post #3

(from the slides) >I learned Emacs in September, 1983 >It is now November, 2019 >...that’s over thirty six years! >An amazingly long time. Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it. I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental im…

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 didn't know something, you needed to pick a book and read or find someone who knew. Nowadays, with a few hours on the net, you can build enough of a working knowledge of a tech to at least know if it is worth the investment.

Post reply on HN