'Using Emacs' Series
cestlaz.github.io
'Using Emacs' Series
1–10 of 106 posts
Re: 'Using Emacs' Series
#2EDIT: Also, C-h v user-emacs-directory RET says programs in Emacs store information in this directory.
Re: 'Using Emacs' Series
#3I have never understood the rampant practice of using ~/.emacs.d/ for one's personal Elisp files. Most of what is in this directory appears to be machine generated files from various packages. To me, it seems much cleaner to have a separate directory for my own files, instead of maintaining ~/.emacs.d in Git and having to constantly update my .gitignore as I install and use new packages. EDIT: Also, C-h v user-emacs-…
*
!.gitignore
!init.el
2. The reason I prefer ~/.emacs.d/ is that I have it in a git repo and on every system, I'll just clone the repo and soft link it in the home directory. This way, I have only one directory inside home about emacs within which my files are explicitly separated and tracked.P.S. I've recently tried to move from Spacemacs to Emacs and by no means a pro, so the process I've described may not be optimal.
Re: 'Using Emacs' Series
#4I have never understood the rampant practice of using ~/.emacs.d/ for one's personal Elisp files. Most of what is in this directory appears to be machine generated files from various packages. To me, it seems much cleaner to have a separate directory for my own files, instead of maintaining ~/.emacs.d in Git and having to constantly update my .gitignore as I install and use new packages. EDIT: Also, C-h v user-emacs-…
Re: 'Using Emacs' Series
#5I have never understood the rampant practice of using ~/.emacs.d/ for one's personal Elisp files. Most of what is in this directory appears to be machine generated files from various packages. To me, it seems much cleaner to have a separate directory for my own files, instead of maintaining ~/.emacs.d in Git and having to constantly update my .gitignore as I install and use new packages. EDIT: Also, C-h v user-emacs-…
Using ~/.emacs.d this way came about well before git was invented. :)
user-emacs-directory is a variable defined in ‘subr.el’.
Its value is "~/.emacs.d/"
This variable may be risky if used as a file-local variable.
Documentation:
Directory beneath which additional per-user Emacs-specific files are placed.
Various programs in Emacs store information in this directory.
Note that this should end with a directory separator.
See also ‘locate-user-emacs-file’.Re: 'Using Emacs' Series
#6I have never understood the rampant practice of using ~/.emacs.d/ for one's personal Elisp files. Most of what is in this directory appears to be machine generated files from various packages. To me, it seems much cleaner to have a separate directory for my own files, instead of maintaining ~/.emacs.d in Git and having to constantly update my .gitignore as I install and use new packages. EDIT: Also, C-h v user-emacs-…
1. You shouldn't be updating your `.gitignore` continuously. You need to ignore everything and explicitly define exceptions e.g. * !.gitignore !init.el 2. The reason I prefer ~/.emacs.d/ is that I have it in a git repo and on every system, I'll just clone the repo and soft link it in the home directory. This way, I have only one directory inside home about emacs within which my files are explicitly separated and trac…
2. A similar scheme would be to maintain a directory called ~/elisp in git and make ~/.emacs a symlink to ~/elisp/emacs. And pretend that ~/.emacs.d/ does not exist.
Re: 'Using Emacs' Series
#7Re: 'Using Emacs' Series
#8Earlier quoted context omitted.
1. You shouldn't be updating your `.gitignore` continuously. You need to ignore everything and explicitly define exceptions e.g. * !.gitignore !init.el 2. The reason I prefer ~/.emacs.d/ is that I have it in a git repo and on every system, I'll just clone the repo and soft link it in the home directory. This way, I have only one directory inside home about emacs within which my files are explicitly separated and trac…
1. I still need to grow my .gitignore file as I add more .el files of my own. 2. A similar scheme would be to maintain a directory called ~/elisp in git and make ~/.emacs a symlink to ~/elisp/emacs. And pretend that ~/.emacs.d/ does not exist.
2. You could!
Re: 'Using Emacs' Series
#9I am a little concerned you start with package repository and then org mode. Emacs is at heart a simple, modeless editor. With c-[fbpns] and c-x c-[fa] you can immediately, if laboriously, do anything. Every new thing you learn incrementally speeds you up.
You mean c-x c-[fs], right? I'm by no mean an emacs expert although I've been using it for 6 years now, and when I read your comment I thought "Wow, c-x c-a is a functionality? How comes I have never used that?", so I tried that in emacs but it's not mapped to anything.
Apart from that, I fully agree with your comment.
Re: 'Using Emacs' Series
#10I have never understood the rampant practice of using ~/.emacs.d/ for one's personal Elisp files. Most of what is in this directory appears to be machine generated files from various packages. To me, it seems much cleaner to have a separate directory for my own files, instead of maintaining ~/.emacs.d in Git and having to constantly update my .gitignore as I install and use new packages. EDIT: Also, C-h v user-emacs-…
1. You shouldn't be updating your `.gitignore` continuously. You need to ignore everything and explicitly define exceptions e.g. * !.gitignore !init.el 2. The reason I prefer ~/.emacs.d/ is that I have it in a git repo and on every system, I'll just clone the repo and soft link it in the home directory. This way, I have only one directory inside home about emacs within which my files are explicitly separated and trac…
- .emacs - which defines my config dir and loads everything in there
- my own config dir (called .emacs.conf), in which I have lots of .el files with specific configurations
Emacs packages still write by default to .emacs.d, and this way I don't have to care about any of that when moving between machines, because my configuration and Emacs's ongoing state are separate.
To be honest, though, I'll probably be migrating into a single-file literate solution soon, which will render my own config directory unnecessary.