-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add provision for user-specific customization #5
Comments
Right, it would be ideal that I not have to edit your files but make my changes elsewhere. |
I'm finally getting to work on this after a long while and have pushed some changes. @ericllazarus, Kindly try it out and let me know how it all looks now. Read this section for details. There are a few more things that I have in mind post which the experience would be so much better. |
@ericllazarus, I'm thinking I should be including blank 'custom' files as well and not ignore them in the project. That way you don't have to 'force' git to track them on your side and as changes from upstream will never modify that file, it will eventually never lead to any merge conflicts anyway. What do you think? |
Sound fine for now. I'm thinking about an even more general idea... perhaps we should have a directory and all the files in that directory will be loaded in alphabetical order or something like that so that the person customizing can barrow from his friends customization and add his/her own or something like that? If someone wanted to fork from my branch of super emacs, say a staff member of mine, how should she add her customizations, potentially share them back with me, etc.? Not thought deeply yet about it yet. |
That makes sense. I've been looking for an idea like that. Let's flesh it out further, think about a few more scenarios and it looks good, I'll be more than happy to switch to that kind of an arrangement sooner than later. |
Sounds good. In the culture of Emacs hacking, is there any standard for this sort of thing? For example, a hierarchy of config files? We can make a wiki page were we put in requirements we are trying to meet. OK if I do that? |
Sure. How about here? |
I just pushed a change to un-ignore the *-custom.el files so that you do not have to change the .gitignore to be able to carry them across your workspaces. You might at least for once have to redo your customizations in your local copy when you pull from upstream. |
@ericllazarus, any further ideas on this? |
The purpose is to add a provision for personal configs so that updates do not break things or lead to conflicts.
Courtesy: @ericllazarus.
The text was updated successfully, but these errors were encountered: