4 ms·

> Should I be learning how to debug elisp better to understand how the commands interact with my environment? Hell yeah, you should. I just don't understand ho

> Should I be learning how to debug elisp better to understand how the commands interact with my environment? Hell yeah, you should. I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. They would complain how "fickle" Emacs is, without even realizing that they are literally operating a living, breathing, dynamic and malleable system. If there's a car that allows you to assemble some parts onto it and turn it into a submarine while you're still driving it, of course it would require you at least the knowledge of basic troubleshooting and the acceptance that shit may break at any point. You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere. These days I don't even try to strive for a "clean" config - it's modular enough and I can relatively easily navigate through it. Whenever I face a problem, I just add some elisp. When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often.

macintux 1y ago
> I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. The second half of your message is interesting. The first half is needlessly condescending.
- iLemming 1y ago
  > is needlessly condescending. While this may sound condesending, I believe it's understandable where the snub is coming from. VSCode doesn't need evangelism - it has become the de facto standard that every programmer is expected to know. Emacs occupies a different position entirely, and when curious newcomers encounter comments like "I used Emacs for 15 years before switching to...", they draw conclusions that may not reflect the full picture. Upon closer examination, these long-time "experts" often reveal they barely engaged with Emacs beyond basic editing - they've never published packages (which is actually far simpler than creating VSCode extensions), never written custom functions, never even added a simple advice for their own needs. This isn't truly "using Emacs"; it's merely dabbling in it. Unlike conventional tools where years translate to expertise along a predictable curve, Emacs rewards deep engagement over mere time served. When someone who spent years passively using Emacs criticizes it publicly, they inadvertently discourage potential users who might have discovered something transformative. The damage is disproportionate: criticizing VSCode barely makes a dent in its massive user base, but dismissing Emacs can deter the very people who would thrive in its ecosystem - those willing to invest in understanding a tool that becomes an extension of their thinking rather than just another tool. Therefore, of course I would be confrontational. I honestly have not ever seen an accurate, honest, factual review of Emacs criticism and comparison with other tools in the same space, because simply there isn't any other tool that operates at the same level. Critics compare surface features while missing that Emacs is essentially a different category of software altogether.
  - massysett 1y ago
    I think this sort of comment turns people off from Emacs. Most people don’t want to become experts in the editor. The editor is a means to an end: writing code, writing text, etc. This comment suggests to the new user: if I don’t program Emacs and publish packages in it, I’m not really using it, I’m just dabbling in it. But I don’t want to program the editor, so I shouldn’t use it at all. I also don’t think the comments you criticize discourage users who would have discovered something transformative. Someone interested in programming their editor isn’t discouraged by someone who complains that Emacs is missing some modern prettiness, or that it’s not popular. There is plenty of Emacs evangelism that will hook those receptive to it. I would like to balance out your comment by saying: it is just fine to, as you would say, dabble in Emacs. Don’t write advice. Don’t publish packages. Use customize. Don’t write a .emacs. Use the pull-down menus. It is still a delightfully powerful and well-documented editor even if you do none of the “expert” things. The developers have added so many of these features precisely so Emacs is easier to learn and use, and don’t let commenters who call you a dilettante convince you that if you’re not an Emacs Lisp maestro, you shouldn’t bother with Emacs.
    - iLemming 1y ago
      To start, I disagree. If it takes a person to turn away from a tool just because some random human tool said something online, maybe they are not ready, on what level - emotional, spiritual, mental, moral - I'll leave them to decide. I'm not saying "don't dabble in Emacs", dable all you want. Just use the damn tool - it's not that hard. To use the tool you just need to use the fucking tool with the intent to fucking use it. When someone says something like "I used Emacs for a decade as just a text editor" to me it sounds like: "I had this smartphone for the past two years and used it only to make calls. Not even video - I never bothered to figure out how that works..." Emacs is a Lisp-based event-loop, with an embedded editor in it. This is of course a "simplification", but that will do. What do you do with a Lisp interpreter? You feed Lisp programs into it. Try writing some Lisp, it's not that hard. Swallow you hubris, swallow your pride - whichever you prefer and stop blaming parenthesis, bad weather, ThePrimeagen's mustache, sanctions or AI. With AI tools these days it may even feel like playing a video game. You don't need to be "an expert" there are no "experts" in Emacs, there's no "career ladder," progression system, no ranks and shoulder straps, I don't know anyone who gets paid even just a little bit more for simply being good in Emacs - I certainly don't. Use it or not - just don't think of being "a newbie" or becoming "an expert" you either enjoy it or not, whichever it is - it's fine. And by the way, I personally think I would've loved to witness my kind of evangelism back when I was still a tool, just much younger.
Karrot_Kream 1y ago
> Hell yeah, you should. I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. Yes I'm familiar with apropos, macros/extensions, advising, indirect buffers, and a lot of stuff. I've just never debugged elisp mostly because I haven't had a hard time just iterating on elisp to make it work and have never bothered debugging packages I've installed. I've put off learning edebug because for the most part I've used the "Lisp debugging" part of my brain on SBCL and Common Lisp. It's just one of those "do I really need to shave this yak?" kind of things and until now it's been no. Sounds like edebug is the next elisp frontier for me, thanks. (Btw your comment is a bit condescending sounding but I actually love reading your emacs comments on HN because your enthusiasm for emacs is great.) > You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere. Yes absolutely this though. I've been having a lot of fun with gptel and in general I have all sorts of fun bindings that do exactly what I want to do. There's a reason I don't want to give up emacs and it's this ability to write elisp and wrangle text. > When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often. I'll be honest, my interest in dealing with this kind of thing greatly varies based on what's going on in my life at the time. Sometimes I'll be locked in and go on a deep binge to optimize my environments. Other times I find it very painful. Maintaining an emacs config has always been quite annoying but I put up with it because the power and customizability of the whole thing is unparalleled. (The fact that an editor like Cursor is a proprietary fork of an open codebase that restricts you to the team's vision is, uh, honestly pretty silly to me. Like why? I can write code can't I? Guess that means I need to maintain configuration but I'd rather do that than use Cursor any day.)
- iLemming 1y ago
  > Maintaining an emacs config has always been quite annoying I dunno, I feel it stopped being like that for me long ago. Perhaps I'm just a "tinkerer" and maybe I never even minded improving my setup. But like I said, at some point, my workflow has become purely "goal-oriented" - whenever I see a problem, I either: - Make a todo list item and forget about it until next time - Or start writing some Elisp (if the problem is simple enough) Let me share some practical examples of each. One day I got annoyed that it was taking me more than a minute to search for my own comment on HN, around some interesting conversations. I made a todo list item. Then at some point I wrote a function, then later I published a package. I can't even tell you how effing nice it feels now - takes me seconds to find relevant stuff. The other day I was reading a pdf, while taking notes. pdf-tools has this nice feature called pdf-view-themed-minor-mode - it adjusts the colors of the document to the colors of your theme, nicely blending the pdf into your editor. I use it all the time. I also use a package called circadian.el - using Emacs' built-in solar calendar, it adjusts the color theme based on the time of day. So, my color theme changes automatically, but it doesn't get automatically reflected in pdf documents I previously had opened. Not a biggie, I still can do it manually, yet it took me a few minutes to concoct an advising function that runs after (load-theme) and sets the colors in every pdf. Of course, why do something manually that the computer is supposed to figure out without your assistance? Now, neither pdf-tools maintainers, nor the author of circadian.el know about my customizations. If any of them make some changes that break my beautiful zen fidgets, why would I even get mad about it? I'll try to fix it, and if it takes me longer than three minutes, I'll just remove it altogether and go back to toggling it manually - not a biggie, never was. That has become my philosophy that probably extends beyond Emacs - my terminal, my browser, my WM, etc. The world is never meant to be perfect for everyone. But you can make it perfect just for you. I learned that it's better to apply ideas that enable you to build your perfect world, than someone else's perception of what _your_ ideal world should be. That's why for an individual programmer, choosing FOSS tools almost always yields better results in the long run. In a team setting that may be a bit difficult, but if you get inventive enough, you can always find workarounds. This is what Emacs taught me that no other tool ever did - the instinct to never settle for the status quo. Whenever something bothers me, I either discover workarounds on the spot or make it a todo item.

macintux 1y ago

> I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. The second half of your message is interesting. The first half is needlessly condescending.

iLemming 1y ago
> is needlessly condescending. While this may sound condesending, I believe it's understandable where the snub is coming from. VSCode doesn't need evangelism - it has become the de facto standard that every programmer is expected to know. Emacs occupies a different position entirely, and when curious newcomers encounter comments like "I used Emacs for 15 years before switching to...", they draw conclusions that may not reflect the full picture. Upon closer examination, these long-time "experts" often reveal they barely engaged with Emacs beyond basic editing - they've never published packages (which is actually far simpler than creating VSCode extensions), never written custom functions, never even added a simple advice for their own needs. This isn't truly "using Emacs"; it's merely dabbling in it. Unlike conventional tools where years translate to expertise along a predictable curve, Emacs rewards deep engagement over mere time served. When someone who spent years passively using Emacs criticizes it publicly, they inadvertently discourage potential users who might have discovered something transformative. The damage is disproportionate: criticizing VSCode barely makes a dent in its massive user base, but dismissing Emacs can deter the very people who would thrive in its ecosystem - those willing to invest in understanding a tool that becomes an extension of their thinking rather than just another tool. Therefore, of course I would be confrontational. I honestly have not ever seen an accurate, honest, factual review of Emacs criticism and comparison with other tools in the same space, because simply there isn't any other tool that operates at the same level. Critics compare surface features while missing that Emacs is essentially a different category of software altogether.
- massysett 1y ago
  I think this sort of comment turns people off from Emacs. Most people don’t want to become experts in the editor. The editor is a means to an end: writing code, writing text, etc. This comment suggests to the new user: if I don’t program Emacs and publish packages in it, I’m not really using it, I’m just dabbling in it. But I don’t want to program the editor, so I shouldn’t use it at all. I also don’t think the comments you criticize discourage users who would have discovered something transformative. Someone interested in programming their editor isn’t discouraged by someone who complains that Emacs is missing some modern prettiness, or that it’s not popular. There is plenty of Emacs evangelism that will hook those receptive to it. I would like to balance out your comment by saying: it is just fine to, as you would say, dabble in Emacs. Don’t write advice. Don’t publish packages. Use customize. Don’t write a .emacs. Use the pull-down menus. It is still a delightfully powerful and well-documented editor even if you do none of the “expert” things. The developers have added so many of these features precisely so Emacs is easier to learn and use, and don’t let commenters who call you a dilettante convince you that if you’re not an Emacs Lisp maestro, you shouldn’t bother with Emacs.
  - iLemming 1y ago
    To start, I disagree. If it takes a person to turn away from a tool just because some random human tool said something online, maybe they are not ready, on what level - emotional, spiritual, mental, moral - I'll leave them to decide. I'm not saying "don't dabble in Emacs", dable all you want. Just use the damn tool - it's not that hard. To use the tool you just need to use the fucking tool with the intent to fucking use it. When someone says something like "I used Emacs for a decade as just a text editor" to me it sounds like: "I had this smartphone for the past two years and used it only to make calls. Not even video - I never bothered to figure out how that works..." Emacs is a Lisp-based event-loop, with an embedded editor in it. This is of course a "simplification", but that will do. What do you do with a Lisp interpreter? You feed Lisp programs into it. Try writing some Lisp, it's not that hard. Swallow you hubris, swallow your pride - whichever you prefer and stop blaming parenthesis, bad weather, ThePrimeagen's mustache, sanctions or AI. With AI tools these days it may even feel like playing a video game. You don't need to be "an expert" there are no "experts" in Emacs, there's no "career ladder," progression system, no ranks and shoulder straps, I don't know anyone who gets paid even just a little bit more for simply being good in Emacs - I certainly don't. Use it or not - just don't think of being "a newbie" or becoming "an expert" you either enjoy it or not, whichever it is - it's fine. And by the way, I personally think I would've loved to witness my kind of evangelism back when I was still a tool, just much younger.

Karrot_Kream 1y ago

> Hell yeah, you should. I just don't understand how the heck people would claim to be using Emacs for decades and still not knowing how to use the built-in profiler, edebug, apropos, macro expansion, advising system, indirect buffers, etc. Yes I'm familiar with apropos, macros/extensions, advising, indirect buffers, and a lot of stuff. I've just never debugged elisp mostly because I haven't had a hard time just iterating on elisp to make it work and have never bothered debugging packages I've installed. I've put off learning edebug because for the most part I've used the "Lisp debugging" part of my brain on SBCL and Common Lisp. It's just one of those "do I really need to shave this yak?" kind of things and until now it's been no. Sounds like edebug is the next elisp frontier for me, thanks. (Btw your comment is a bit condescending sounding but I actually love reading your emacs comments on HN because your enthusiasm for emacs is great.) > You have no idea how liberating the feeling is when you can pinpoint a problem, launch a gptel buffer and then ask Emacs to write some elisp for a hook or an advising function, you can even try the snippet in-place, without ever moving it anywhere. Yes absolutely this though. I've been having a lot of fun with gptel and in general I have all sorts of fun bindings that do exactly what I want to do. There's a reason I don't want to give up emacs and it's this ability to write elisp and wrangle text. > When something breaks (usually due to upstream changes), I don't even get annoyed. Identifying a problem and finding a workaround doesn't take too long - typically minutes - and it doesn't even happen very often. I'll be honest, my interest in dealing with this kind of thing greatly varies based on what's going on in my life at the time. Sometimes I'll be locked in and go on a deep binge to optimize my environments. Other times I find it very painful. Maintaining an emacs config has always been quite annoying but I put up with it because the power and customizability of the whole thing is unparalleled. (The fact that an editor like Cursor is a proprietary fork of an open codebase that restricts you to the team's vision is, uh, honestly pretty silly to me. Like why? I can write code can't I? Guess that means I need to maintain configuration but I'd rather do that than use Cursor any day.)

iLemming 1y ago
> Maintaining an emacs config has always been quite annoying I dunno, I feel it stopped being like that for me long ago. Perhaps I'm just a "tinkerer" and maybe I never even minded improving my setup. But like I said, at some point, my workflow has become purely "goal-oriented" - whenever I see a problem, I either: - Make a todo list item and forget about it until next time - Or start writing some Elisp (if the problem is simple enough) Let me share some practical examples of each. One day I got annoyed that it was taking me more than a minute to search for my own comment on HN, around some interesting conversations. I made a todo list item. Then at some point I wrote a function, then later I published a package. I can't even tell you how effing nice it feels now - takes me seconds to find relevant stuff. The other day I was reading a pdf, while taking notes. pdf-tools has this nice feature called pdf-view-themed-minor-mode - it adjusts the colors of the document to the colors of your theme, nicely blending the pdf into your editor. I use it all the time. I also use a package called circadian.el - using Emacs' built-in solar calendar, it adjusts the color theme based on the time of day. So, my color theme changes automatically, but it doesn't get automatically reflected in pdf documents I previously had opened. Not a biggie, I still can do it manually, yet it took me a few minutes to concoct an advising function that runs after (load-theme) and sets the colors in every pdf. Of course, why do something manually that the computer is supposed to figure out without your assistance? Now, neither pdf-tools maintainers, nor the author of circadian.el know about my customizations. If any of them make some changes that break my beautiful zen fidgets, why would I even get mad about it? I'll try to fix it, and if it takes me longer than three minutes, I'll just remove it altogether and go back to toggling it manually - not a biggie, never was. That has become my philosophy that probably extends beyond Emacs - my terminal, my browser, my WM, etc. The world is never meant to be perfect for everyone. But you can make it perfect just for you. I learned that it's better to apply ideas that enable you to build your perfect world, than someone else's perception of what _your_ ideal world should be. That's why for an individual programmer, choosing FOSS tools almost always yields better results in the long run. In a team setting that may be a bit difficult, but if you get inventive enough, you can always find workarounds. This is what Emacs taught me that no other tool ever did - the instinct to never settle for the status quo. Whenever something bothers me, I either discover workarounds on the spot or make it a todo item.