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) ??
Emacs: The Editor for the Next Forty Years [video]
171–180 of 272 posts
Re: Emacs: The Editor for the Next Forty Years [video]
#172Earlier 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.
Re: Emacs: The Editor for the Next Forty Years [video]
#173Earlier 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…
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]
#174Earlier 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.
Re: Emacs: The Editor for the Next Forty Years [video]
#175I 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.
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]
#176Earlier 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?
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]
#177Earlier 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…
Re: Emacs: The Editor for the Next Forty Years [video]
#178Earlier 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
Re: Emacs: The Editor for the Next Forty Years [video]
#179Earlier 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…
Re: Emacs: The Editor for the Next Forty Years [video]
#180Earlier 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?
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.