You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I saw your post on Hacker News, linked from Emacs News. I could not find your email. I don't use HN much, Twitter at all, and try to stay away from proprietary software. So, I reply here.
What are some good resources on Emacs?
The best resources I have found are A) the tutorial (open vanilla Emacs and press enter), B) the manual and C) the Emacs lisp reference. Learn to use the info system inside Emacs. This will help you find the information you need quickly. Also, read the source code for things. Use C-h v and C-h f to quickly look at the source code for whatever you're using.
If you use Emacs as your primary editor, how long did it take you to understand enough internals to be able to debug issues?
I started by using vanilla Emacs. If a bug appeared, it was always because of something I put in my init. I never put anything I don't (think I) understand in my init. If a problem appears, I know it is likely through something I have done. I remove the code I recently entered and see if the bug goes away. If it does, I isolate the bad part and make sure I can reproduce it. Then, I check my understanding. I have not come across a single Emacs bug in 5 years of daily use. All problems I've had I introduced. In this way, I have more or less always been able to debug issues. It took me reading "An Introduction to Programming in Emacs Lisp" to feel confident extending Emacs, however. https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html
If you use doom/spacemacs, do you feel the bloat?
I have never used doom/spacemacs because it prevented me from doing the process I described in answer 2.
I do my init a little differently than I've seen others do it. I keep an "experimental.el" file to test code in. Once I feel it's stable, I put it in my init. I use use-package mainly for the syntax and use straight.el to manage my packages (straight.el is great, but not "straight foreward"). This arrangement works well for me. I also have little tricks, like a debug mode for my init which tells me which package just loaded. This helps in the rare cases that I need to bisect my init. I would be happy to do a video chat with you some time. Please let me know, [email protected].
Take care
The text was updated successfully, but these errors were encountered:
I saw your post on Hacker News, linked from Emacs News. I could not find your email. I don't use HN much, Twitter at all, and try to stay away from proprietary software. So, I reply here.
What are some good resources on Emacs?
The best resources I have found are A) the tutorial (open vanilla Emacs and press enter), B) the manual and C) the Emacs lisp reference. Learn to use the info system inside Emacs. This will help you find the information you need quickly. Also, read the source code for things. Use C-h v and C-h f to quickly look at the source code for whatever you're using.
If you use Emacs as your primary editor, how long did it take you to understand enough internals to be able to debug issues?
I started by using vanilla Emacs. If a bug appeared, it was always because of something I put in my init. I never put anything I don't (think I) understand in my init. If a problem appears, I know it is likely through something I have done. I remove the code I recently entered and see if the bug goes away. If it does, I isolate the bad part and make sure I can reproduce it. Then, I check my understanding. I have not come across a single Emacs bug in 5 years of daily use. All problems I've had I introduced. In this way, I have more or less always been able to debug issues. It took me reading "An Introduction to Programming in Emacs Lisp" to feel confident extending Emacs, however. https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html
If you use doom/spacemacs, do you feel the bloat?
I have never used doom/spacemacs because it prevented me from doing the process I described in answer 2.
I do my init a little differently than I've seen others do it. I keep an "experimental.el" file to test code in. Once I feel it's stable, I put it in my init. I use
use-package
mainly for the syntax and usestraight.el
to manage my packages (straight.el
is great, but not "straight foreward"). This arrangement works well for me. I also have little tricks, like a debug mode for my init which tells me which package just loaded. This helps in the rare cases that I need to bisect my init. I would be happy to do a video chat with you some time. Please let me know, [email protected].Take care
The text was updated successfully, but these errors were encountered: