Live data from Hacker News

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

media.emacsconf.org

171–180 of 272 posts

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

#171

If Emacs is to be "the" editor for the next forty years, I really hope it can better combat random hangs. As someone who uses Emacs as a daily driver and loves it to death for its extensibility paradigm it's painful when it maxes out the CPU, I have to restart and have no idea what it could have been. But then again scripting languages don't really have these interruption features by design. I'm developing something…

(setq-default garbage-collection-messages t) ??

Right - that's what I need from my text editor!

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

#172

Earlier quoted context omitted.

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.

Well, that wouldn't be much different from the pervasive habit of many authors of YouTube videos to stick their own faces in the frame in one or the other ridiculous fashion. This is unsurprising, because it is self-advertisement that is the true goal of such podcasts and videos.

I routinely follow one podcast (Software Engineering Daily) and one You Tube channel (3blue1brown). Neither fit your characterisation. Perhaps you should consider being a little more selective in your consumption of YouTube :)

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

#173

Earlier quoted context omitted.

The more I use Clojure at work, the more I tolerate the elisp side of things. I've written a couple little major modes (though not to any great standard of quality) and elisp is indeed pretty crap, but usually adequate. I think the ideal Emacs lisp successor would be a Clojure derivative, with the buffer represented as a persistent trie datastructure like other things are in Clojure. Maybe the buffers could be disjoi…

> Maybe the buffers could be disjointed from the presentation a bit, and we could have strictly AST-driven major modes Yes, good point, agree that would be a very positive direction. > elisp is indeed pretty crap Ah, I've been enjoying it a lot recently :) But I don't have an excuse to write clojure and I certainly recognize that that's a much more sophisticated thing. What are your biggest criticisms of elisp? Mine…

My main gripe with elisp is the default to dynamic binding, which is in most systems almost never what you want. In Emacs, the dynamic bindings are used for more productive reasons than in generalized programs, but they should still be a conscious choice.

When it comes to threads, the elisp datastructures are inadequate because they are mutable. It is possible to write functioning threaded programs with shared mutable state, but for the most part, it is going to introduce the kinds of bugs that people solve one of per week on a six figure salary.

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

#174

Earlier quoted context omitted.

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.

Well, that wouldn't be much different from the pervasive habit of many authors of YouTube videos to stick their own faces in the frame in one or the other ridiculous fashion. This is unsurprising, because it is self-advertisement that is the true goal of such podcasts and videos.

I'd be more inclined to believe that has more to do with ScreenFlow's (a popular screencasting program) defaults rather than people's inherent narcissism.

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

#175

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.

Thank you, I think this is fair.

I assume you've started listening to the latest episode: it was released after a long break and I guess in my mind it was geared towards existing listeners, with whom I've developed a relationship of sorts. Based on their feedback, it made sense to meander and focus on personal feelings and experience. I find it hard to balance between being insider-friendly and being attractive to new audiences. Perhaps, one of the earlier episodes could be better suited, but all of them contain personal stories.

Your comment was quite a sharp revelation tbh, it got me thinking. For now, I chose to define my project as a weird, personal journal rather than anything else, and try to further evolve the relationship with its existing listeners.

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

#176
post #151

Earlier quoted context omitted.

I love writing Lisp and do it for a living, but I can’t even remember the last time I had to write a single line of elisp to use Emacs (unless you count things like adding or removing a layer in my .spacemacs file as writing Lisp).

Really? Emacs is the opposite for me, I've used it for 15 years and really only recommend it to those for whom writing a little bit of emacs lisp sounds like fun. You write lisp for a living, sounds like in Emacs, so I assume you use paredit-mode. Don't you have to do little things like ensure that paredit-mode is turned on in your mode hook for clojure or common lisp or whatever?

I have changed the values of dotspacemacs-smartparens-strict-mode and dotspacemacs-smart-closing-parenthesis from the default nil to t in my .spacemacs file. As far as I can remember, that's the only paredit-ish customisations I have done. And by the way, I use smartparens everywhere, not just in Lisp modes.

Generally, the Spacemacs defaults work really well for me, and for many others. Elisp hacking was more relevant in the past. These days, with Spacemacs and other similar community efforts that deliver sane and well thought out settings, not much tinkering is required.

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

#177
post #176

Earlier quoted context omitted.

Really? Emacs is the opposite for me, I've used it for 15 years and really only recommend it to those for whom writing a little bit of emacs lisp sounds like fun. You write lisp for a living, sounds like in Emacs, so I assume you use paredit-mode. Don't you have to do little things like ensure that paredit-mode is turned on in your mode hook for clojure or common lisp or whatever?

I have changed the values of dotspacemacs-smartparens-strict-mode and dotspacemacs-smart-closing-parenthesis from the default nil to t in my .spacemacs file. As far as I can remember, that's the only paredit-ish customisations I have done. And by the way, I use smartparens everywhere, not just in Lisp modes. Generally, the Spacemacs defaults work really well for me, and for many others. Elisp hacking was more relevan…

OK, I feel like I'm missing something with smartparens. I do the same as you -- but I use paredit everywhere, not just in lisp modes. When I've tried smartparens it seemed much less attractive (powerful?) than paredit.

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

#178
post #160
post #83

Earlier quoted context omitted.

What are some old fails that need fixed?

Are you an emacs hacker and have the knowledge/power to fix the problems that prevent it from catching up to, say, a mediocre editor like Kdevelop? https://news.ycombinator.com/item?id=17178246

No, I'm just a guy who's pretty content with emacs and wants to know what others perceive to be the major failings

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

#179
post #71

Earlier quoted context omitted.

The point is that "duplicating a line" is a very fundamental building block to other operations, and it should be supported natively. For instance, lets say you have to do several different function calls with only minor differences, you might write it out once and then duplicate a few times, then go in and edit them. "Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is…

> "Writing a function for the full change" is simply not a tenable thing to do. "Duplicate a line" is fundamental in the same way that "go to start of line" or "indent this line one more tabstop" is. So write a function for "duplicate line" and use it from now on. It's very easy to do. Just as it's easy to write function for a full edit. A general algorithm to get one started: 1) Execute the edit you want to reuse. 2…

I love view-lossage. How often do You use C-x which shows elisp for what ya just did? Eg, switch buffer then try it.

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

#180
post #148

Earlier quoted context omitted.

The most core inards of Emacs are subject to bitrot. It doesn't play well with any Windowing system. And as an editor it is quite slow/sluggish.

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 using cut and paste to/from the Windows/command prompt that is unnecessary when going back and forth from OSX/Terminal.

Also when using ssh to a web server over my slow connection I can run emacs but it's obviously redrawing the screen when I change the buffer, vi is much more responsive.

Post reply on HN