Concatenate content of TAGS files from different directories - emacs

I'm referring to TAGS file generated by ctags or etags in order to have some code navigation in Emacs with M-..
The typical project looks like this:
Large standard library (more than 100 files, but rarely updated).
Project-specific library (updated on the daily basis).
I would like the project to be able to use two (or maybe more TAGS files), but regenerate only the portion of them, only the ones used inside the particular project. How would I approach this problem?

etags --help:
-i FILE, --include=FILE
Include a note in tag file indicating that, when searching for
a tag, one should also consult the tags file FILE after
checking the current file.

Related

How do I configure mplayer to use a default edl file name?

I want to configure mplayer to look for an edl when playing a video. Specifically, I want it to use "show.edl" when playing "show.mp4", assuming both are in the same directory. Very similar to how it looks for subtitles.
I can add a default edl in the config file by adding the following:
edl=default.edl
And this will look for the file "default.edl" IN THE CURRENT DIRECTORY, rather than in the directory where the media file is. And it isn't named after the media file either, and thus even if it did look in the right place, I'd have one single edl file for every media file in that directory.
Not really what I wanted.
So, is there a way, in the "~/.mplayer/config" file, to specify the edl relative to the input file name?
Mplayer's config file format doesn't seem to support any sort of replacement syntax. So there's no way to do this?
MPlayer does not have a native method to specify strings in the config file relative to the input file name. So there's no native way to deal with this.
There's a variety of approaches you could use to get around that. Writing a wrapper around mplayer to parse out the input file and add an "-edl=" parameter is fairly general, but will fail on playlists, and I'm sure lots of other edge cases. The most general solution would of course be to add the functionality to mplayer's config parser (m_parse.c, iirc.)
The simplest, though, is to (ab)use media-specific configuration files.
pros:
Doesn't require recompiling mplayer!
Well defined and limited failure modes. I.E. the ways it fails and when it fails are easily understood, and there aren't hidden "oops, didn't expect that" behaviors hidden anywhere.
Construction and updating of the edl files is easily automated.
cons:
Fails if you move the media around, as the config files need to full path to the edl file to function correctly.
Requires you have a ".conf" file as well as an EDL file, which adds clutter to the file system.
Malicious config files in the media directory may be a security issue. (Though if you're allowing general upload of media files, you probably have bigger problems. mplayer is not at all a security-hardened codebase, nor generally are the codecs it uses.)
To make this work:
Add "use-filedir-conf=yes" to "/etc/mplayer.conf" or "~/.mplayer/config". This is required, as looking in the media directory for config files is turned off by default,
For each file "clip.mp4" which has an edl "clip.edl" in the same directory, create a file "clip.mp4.conf" which contains the single line "edl=/path/to/clip.edl". The complete path is required.
Enjoy!
Automatic creation and updating of the media-specific .conf files is left as an exercise for the student.

Is there a way to ignore temporary folders in RTC client?

I have temporary files created in separate folders inside my source tree which I would like to ignore. Something like:
project/
|--component/
|--.jazzignore
|--file.src
|--file-9df29e29373e66caef72/
|--file.src.tmp
I already ignore file.src.tmp by extension using .jazzignore, but I would also like to ignore the file-9df29e29373e66caef72/. The folder looks empty in the "Unresolved" category for the component, but since its name changes over time, I cannot ignore it by name.
since its name changes over time, I cannot ignore it by name.
Still, if you know its naming convention, you might consider an ignore pattern:
core.ignore= \
file-*
Note it is non-recursive, you that would ignore any file, folder or symlink named file-... anywhere under component.
Here, that would ignore only file-... directly under component.
Eclipse workspaces often include files or folders, such as compiler output, log files, and so on, that you do not want to place under source control.
You can specify resources or classes of resources to be ignored by Rational Team Concertâ„¢ source control. Ignored resources are never checked in.
A .jazzignore file is used to prevent items from being checked into change sets.
A .jazzignore file consists of a series of patterns. Any file, folder, or symbolic link whose name matches a pattern cannot be committed to a change set.
There are two types of patterns in a .jazzignore file:
core.ignore patterns, that are effective in the same directory as the ignore file; and
core.ignore.recursive patterns that affect items in all of the directories below the .jazzignore file.

Generating a global include graph in Doxygen

Doxygen can generate graphs showing which files in a project include which others, as a directed graph. This is a nice tool, but it only comes in two flavors, namely showing all the files that include (directly or indirectly) a given file, or all the files that are included (again directly or indirectly) by a given file.
I would like to generate a global include graph, containing all the files that Doxygen knows about, and showing the include structure. Is that possible?
One trick that kind of works but feels extremely dirty: add some dummy.h header somewhere, and include it from every other file, or alternatively (a bit cleaner since it doesn't need to touch the other files) have dummy.h manually include everything else. And then manually remove useless includes (which are implied by others as indirect dependencies). That is not the right way to do it...

Repeating elements/links in org pages to be published as html?

Is there a simple way to add something like the {Back to Worg's index} to every .org page in a directory which I plan to publish with org-publish-project-alist? Is this accomplished with a #+ tag, or some definition in the .css file?
I looked at how they did it on Worg, and it doesn't look like CSS.
There are a few ways you might be able to do so.
Create a generic file that only includes the details you want in each file. For example:
[[./index.org][Back to index]]
Then use #+include: <filename> at the location in your file where you want the line. (See Include Files)
Alternately you could define a macro in a setupfile (See In-Buffer Settings) that is the definition of the link (or multiple link choices)
#+macro: toIndex [[./index.org][Back to index]]
In both cases it is worth noting that the relative paths are based on the exported file. So a [[../index.org]] will always point to the index.org file in the parent directory, no matter where the setupfile is.

Making stable names for doxygen html docs pages

I need to refer to Doxygen documentation pages. The file names however are not stable as they change after every generation. My idea is to create a symlink to each HTML file created by Doxygen , having a stable and human friendly name. Have anyone tried this?
Actually, it might be very easy just to parse the annotated.html file Doxygen produces. Any documented class shows up there as a line like:
`<tr><td class="indexkey"><a class="el" href="dd/de6/a00548.html">
ImportantClass</a></td>`
The hard problem for me is that I would like to have my file names (i.e. the symlinks) be visible on my server like:
http://www.package.com/com.package.my.ImportantClass.html
[Yes, the code is in java]. So the question actually reads: "how to connect a HTML page by Doxygen with the right java class name and its package name.
You seem to have SHORT_NAMES enabled, which will indeed produce volatile names. When you set SHORT_NAMES to NO in the configuration file (the default), you will get longer names, but these are stable over multiple runs (i.e. they are based on the name, and for functions also on (a hash of) the parameters.