I am setting up Aquamacs 2.4 to be used on at least three different computers and I'm uncertain how best to go about excluding a path (e.g., /Applications/Aquamacs.app/Contents/Resources/lisp/aquamacs/tabbar) from subdirs.el located within /Applications/Aquamacs.app/Contents/Resources:
(if (fboundp 'normal-top-level-add-subdirs-to-load-path)
(normal-top-level-add-subdirs-to-load-path))
And, another subdirs.el located within /Applications/Aquamacs.app/Contents/Resources/lisp:
;; In load-path, after this directory should comecertain of its subdirectories. Here we specify them.
(normal-top-level-add-to-load-path '("url" "textmodes" "progmodes" "play" "org" "nxml" "net" "mh-e" "mail" "language" "international" "gnus" "eshell" "erc" "emulation" "emacs-lisp" "contrib" "cedet" "calendar" "calc" "aquamacs" "obsolete"))
I spent several hours trouble-shooting and ultimately customizing aquamacs-tabbar.el within /Applications/Aquamacs.app/Contents/Resources/lisp/aquamacs/tabbar. After finally figuring out what was happening, I had two obvious choices -- (1) hard-code aquamacs-tabbar.el by striking out the relevant portions that were overriding customizations.el; or, (2) hard-code all of my customizations directly into aquamacs-tabbar.el. So now I have a hard-coded customized aquamacs-tabbar.el (hidden within the application package) -- I'd like to copy it over to a more user-friendly script loading directory /Users/HOME/Library/Preferences/Aquamacs Emacs so that I can use it there, and also synchronize that directory and all sub-directories with my other three computers.
I'd like to leave as much of the application intact as possible, but I really don't want to be synchronizing the application itself to multiple computers on an ongoing basis.
Maybe the solution is to just strip the guts out of Aquamacs 2.4, and synchronize the skeleton to all of my computers, and then place the stripped guts within /Users/HOME/Library/Preferences/Aquamacs Emacs. Then I can synchronize the latter with my other computers to my hearts content.
I'm sure that customizing aquamacs-tabbar.el is just the first of many scripts (hidden within the application package) that will need to be tweaked.
Any ideas would be greatly appreciated.
For ideas regarding how to customize the paths for all emacs-related files during the build process (to have everything under the same roof), please refer to:
OSX -- configuring Emacs to use NSSpellChecker
Related
What's the best way to associate file extensions with my own customizations? For example, when I open a .py file the frame would be bigger and split into 2 windows, but when a .tex file is opened the frame would be smaller with just one window. Should I split my .emacs and write all configurations associated with python in a .el file (key bindings, python shell = ipython, etc ...) and for latex in another .el file (load auctex, pdf mode = default, etc ...)? How would I "call" the files and make them work appropriately (if that'a possible and good solution)?
(First, +1 to #phils's comment. You will get better help if you are more specific about what you need/want.)
Depending on just what you need/want, see also variable (not option) file-name-handler-alist. You might not need it, but you might.
You can make use of it if you intend all or particular operations on the files to involve additional actions (such as those you describe). For any operations where you do not need special treatment, just provide the default behavior. For the others, provide the default behavior plus the extra behavior (in whichever order is appropriate).
See (elisp) Magic File Names for more information.
I am not sure whether I should version control the following files under my .emacs.d:
[lucas#lucas-ThinkPad-W520]/home/lucas/.emacs.d$ file elpa/archives/marmalade/archive-con
tents
elpa/archives/marmalade/archive-contents: HTML document, UTF-8 Unicode text, with very lo
ng lines, with no line terminators
[lucas#lucas-ThinkPad-W520]/home/lucas/.emacs.d$ file elpa/archives/gnu/archive-contents
elpa/archives/gnu/archive-contents: ASCII text
[lucas#lucas-ThinkPad-W520]/home/lucas/.emacs.d$
As shown above, marmalade/archive-contents is an HTML document while gnu/archive-contents is ASCII text. Are these safe to include in my version control or should I remove them from my index?
For example, I use emacs across different platforms like Ubuntu Linux and Windows 7, and I would like to keep my emacs environment consistent. It works so far, but I want to avoid future problems. I am ignoring files like *.elc, but I don't know whether archive-contents under version control will help or hinder my cross-platform emacs environment.
I looked at other .emacs.d/ repositories, like this one, and examined their .gitignore files, but I don't know if they are doing correctly either. Any suggestions or resources on how to manage the .emacs.d/ version control for cross-platform development would be great.
Here is my current .gitignore:
*~
*.elc
tramp
Update
This seems to be an iffy topic, but it seems that the significant majority do not version control their entire elpa/ folder even though it may take a hit on their initial load time (immediately after cloning). I think I will follow that advice, and I'm willing to live with it rather than spending more time managing the extra issues of a pre-compiled repository.
I do not commit .emacs.d/elpa at all. My init.el automatically reinstalls missing packages on startup. I did not have any issues yet, even though I exclusively use unstable packages from MELPA.
I don't think including archive-contents should cause any problems. I don't make much use of package.el, but I have that file in my repo, and haven't noticed any issues.
Byte-compiled .elc files are portable. I recommend that you do include them in your repository, otherwise you risk ending up with uncompiled elisp when you clone your repo, and Emacs will run your config awfully slowly.
Remember that none of the default recompilation commands will compile a .el file if it doesn't already have a .elc file, so you'd be left needing to decide whether or not it was valid to forcibly compile everything (which isn't necessarily a safe thing to do), or manually pick and choose. Neither is a good option.
The exceptions I make are for the elisp files which I edit myself (init file, etc) as there's more chance of causing problems when you're editing files in multiple places, and merging. So I do .gitignore these files (and forcibly compile them for new deployments). However I use http://tarsius.github.com/auto-compile (Highly recommended) to automatically ensure that the compiled versions of these (and indeed all) .elc files is always up to date, so that when I merge the modified .el files, Emacs won't load the outdated .elc file instead.
FWIW my .gitignore looks like this (although some of the names are custom). It's pretty much a case of adding stuff as you encounter a need for it, though, so I wouldn't suggest that you copy this.
*~
/auto-save-list/
/backup/
/bookmarks.bmk
/desktop/*
/eshell/*
/history
/server/
/tramp
/geben/
/erc/*
/image-dired/
/url
session.*
/my-lisp/*.elc
These files are created by package.el (more specific, the package-update-contents function), and contain the index of packages for each ELPA repository. Checking them into VC might be annoying because they get updated frequently and you have to deal with merge, which is meaningless since they will be updated by package.el eventually.
How do I specify different source directories under cedet ?
I have configured my project like this:
(when (file-exists-p "~/ws/madwifi/build/Makefile")
(setq cpp-tests-project
(ede-cpp-root-project "madwifi"
:file "~/ws/madwifi/build/Makefile"
:system-include-path '("~/ws/madwifi/build/include/drivers"
"~/ws/madwifi/build/include/hw/"
)
)))
But when I do a semantic-symref-symbol on a symbol, it sometimes lists only functions
that are used in the project. variables are not symref'd
But when I completely remove the block above, it shows the references of variables only
from the current directory. How to properly configure ede-cpp-root-project.
The symref tools only work within the current project, and do not pull data in from include paths. You can search for references to a symbol from an include file, but it won't find the declaration from the includes.
The symref tool works with several different external tools such as GNU Global or idutils. In theory you could use one of those tools to index whichever files you want, and as long as the index file is at the root of your project, it will find it, and also find your external includes. I haven't tried this though, so I don't know if these tools have that capability.
If you want to jump to a reference in an external include, you can use other tools, like semantic-ia-fast-jump and that uses include paths instead of project indicies, but it won't find references.
How do I set up cscope in Emacs when my source code lives in multiple directories?
Say I have several paths for my C++ project:
/path/to/my/code (and subdirectories)
/path/to/other/code (and subdirectories)
/path/to/static/linking/include/files (and subdirectories)
/path/to/static/linking/lib/files' (and subdirectories)
I would like to use xcscope to navigate/look up symbols in my code and the library that I am linking to.
The instructions for xcscope.el say that I should first run C-c s (Cscope->Create list and index) at /path/to/my/code, but I am then confused about how I to have the other paths indexed by cscope.
The documentation says I should go to the other directories and run cscope -b, but what I am supposed to do after that?
I looked at the cscope.files file that C-c s built. I think I am supposed to add my other paths to this file, but this file includes a list of source code files (not directories).
Do I have to manually edit cscope.files to add every single file that I want to index that is outside of my project's root directory?
The documentation is confusing.
I got one sol'n from http://cscope.sourceforge.net/large_projects.html. Still confusing.
cscope.files is aptly named. It is NOT directories. It is files, only files. Which is as daunting as it sounds. What if you have hundreds of files. Then you have to write hundreds of lines, one per file, into cscope.files. No joke.
Automate it with some scripting. E.g., on linux, use bash scripts and redirection (>,>>,|) operators to select and filter files from any and all directories into that cscope.files.
What about the directory where cscope.files resides? IF you don't include those files, it'll only find them when you open your project (in emacs, but probably applicable to any IDE) in that source directory. So, include them, too, for easy opening of your project from anywhere.
The option "recursive/-R" seems obvious to send to cscope-indexer. Nope, not with many root directories. Does nothing (probably could do something with scripts or elisp or who knows). Just feed those files, absolute path, into cscope.files. And you might have to make sure you have only one cscope.files per project. Don't split them up relative to each diretory. Or maybe you can, something to look into.
Remember, include the /path/to/each/file/ before the file if you want cscope.files to point to it from anywhere. cscope isn't "smart", it's dumb, it just takes directions for where to look and it won't know where to look for "filename", without knowing where it is. You're just asking it to call locate filename, which it can't do anyway, when you give it a lonely filename without a dir path outside of the directory that a particular cscope.files resides.
I hope there's a way to use xcscope inside emacs, just adding directories which it will catalog and index, as the xcscope docs and emacs menu suggest. But I didn't succeed in making it work that way.
Wouldn't a soft link (ln -s) work? Worked for me.
I've placed 2 plugins in different directories (according to their docs instructions).
One is in C:\Documents and Settings\Alex.AUTOINSTALL.001\Application Data\.emacs.d
(the plugin is yasnippet-0.6.1c).
I placed the second in D:\Program Files\emacs-23.1\site-lisp (the plugin is color-theme).
I think its a bit confusing to place plugins in different directories. It is possible to place them in only one directory? or because of the 'nature' of those plugins they must be placed in those separated directories?
You may put your elisp files wherever it's convenient for you, as long as the directories you use for this purpose are on your load-path. For example, I have this line in my ~/.emacs file:
(add-to-list 'load-path "~/.emacs.d/autoload")
And most of my extra elisp resides there. (I've also got separate directories for larger apps.)
On Windows, you'll be putting something similar in your _emacs file.
Similar to Michal, I suggest having a folder, next to your .emacs file (wherever that is) and in there, you can have sub-folders for whatever local elisp you need. I use a folder called ~/elithp (I thought it was funny 17 years ago when I started it B-)
Also, things will often want to be put in /usr/local/share/emacs/site-lisp or some equivalent, if they are not user specific.
I'm not exactly sure what the Windows equivalent locations are...