I am using Doxygen for generating documentation for my project, which generates docsets that work almost perfectly with dash.
What I want to know is how to set the search keyword in dash; the default is "unknown:"
What do I need to change so that it reads something other than "unknown:". Can I change this in Doxygen?
I'm Dash's developer. Dash uses the DocSetPlatformFamily key in the Info.plist file inside the docset to determine the default keyword. Unfortunately, Doxygen has no option as far as I'm aware to set this value. I will contact the Doxygen team and ask them to add this option. Feel free to do the same.
For now, my best recommendation would be to write a post-generation script that would add the required key in the Info.plist file (it's just a text file).
For example, this should work:
perl -pi -w -e "s/<\/dict>/<key>DocSetPlatformFamily<\/key><string>__DESIRED KEYWORD__<\/string><key>DashDocSetFamily<\/key><string>doxy<\/string><\/dict>/s" Info.plist
Note: I've also added a "DashDocSetFamily" entry with a value of "doxy". This will cause Dash to handle the docset as a Doxygen-generated one and display the filterable table of contents.
In case you haven't found them already, here are some recommended settings for generating a Doxygen docset for use in Dash:
SEARCHENGINE = NO
DISABLE_INDEX = YES
GENERATE_TREEVIEW = NO
Related
I'm using Gvim in windows.
Normally, when we type some character then press Ctrl-n, vim will show some tag, but those tags just includes words which have been pre-typed in the current file.
Now, I need it working in a new language, and show the tag which has been defined in other files.
So, I create a new \\.ctags for this new language, and generate tags file by exuberant-ctags.
I can choose a function in current file, then press Ctrl-] to jump to the function definition, but this function was define in the other files. It is working very well.
I don't know how to make it show the tags which are generated by ctags when I type some character.
Please help me. Thanks very much.
My English is poor, I hope you can understand what I said.
CTRL-N is just the default completion (which completes from a variety of sources, including the open buffers and also the tags database). There are many more specialized completions (all starting with CTRL-X), among them tags completion, triggered via CTRL-X CTRL-], see :help i_CTRL-X_CTRL-]. If you've correctly configured the 'tags' option (so your tags database is found) and tags jumps do work, just start using that.
Some languages / filetypes also define a language-specific completion (for language keywords etc.), usually via the 'omnifunc' option and triggered by CTRL-X CTRL-O. You could write such yourself, too.
I am struggling with this issue:
I have to document a fairly large project composed by a C core engine and different API that are built on top of that, say Java, Python C#.
The docs must be deployed separately for each API, i.e. for each language, but 99% of the docs are the same, just the code snippet and example mainly need to change.
I set the type of language in the conf.py file by defining a global variable
I have used primary_domain and highlight_language to set the correct syntax highlighting
For each example I have a source file with the same name but different extension
Now, I'd like to include say an example using the literalinclude directive specifying the name of the file and let its extension change depending on the language in use. I tried naively to use the replace macro but with no success:
rst_prolog = ".. |ext| replace:: .%s\n" % primary_domain
correctly replace |ext| around the docs, but not in the command
.. literalinclude: filename|ext|
Is there any way I can do this, except parse rst files using sed or the like?
I am trying to create custom syntax highlighting for Kivy '.kv' files in the Geany editor. Although the specific filetype seems irrelavant to the issue I'm having, as any efforts I make at getting syntax highlighting to work for a custom filetype results in a completely non-highlighted file. I believe I have done my homework on this, and nothing seems to work.
I have added the following to ~/.config/geany/filetype_extensions.conf
Kivy=*.kv;
I also have a custom type definition file named 'filetypes.Kivy.conf' in ~/.config/geany/filedefs/. I have tried basing this file off several of the stock type definition files in /usr/share/geany/ and the file never gets any syntax highlighting applied in Geany. Right now, just for experimentation's sake, my 'filetypes.Kivy.conf' file looks like this:
# For complete documentation of this file, please see Geany's main documentation
[settings]
# default extension used when saving files
extension=kv
# single comments, like # in this file
comment_single=#
[keywords]
# all items must be in one line
primary=size canvas
secondary=pos size
[indentation]
width=4
# 0 is spaces, 1 is tabs, 2 is tab & spaces
type=0
This is very loosly based on the stock XML definition file, but like I said I've tried many other stock files. In many cases I only changed the 'extension=' value to kv and still no highlighting was applied, even though going to Document>Set Filetype in Geany and choosing virtually any random filetype (besides my custom entry) would yeild some sort of highlighting within my .kv file. This is even the case when using the unmodified contents of a stock definition which otherwise works fine on my .kv file when specifically selected in Geany!
Also, the Kivy filetype is listed and selected by default in Document>Set Filetype within Geany, so I must be doing something right here!
I realize this similar question has been asked, but the solutions seem irrelavent to my case, as I've tried every related topic on this and many other sites. My Geany version is 1.22 and I'm running Arch Linux. This is driving me nuts - any suggestions?
Thank you!
Set lexer_filetype= property in the [settings] section of your filetype file. Working highlighting requires that there is a lexer that could be used for highlighting the .kv-files.
For more info see http://www.geany.org/manual/#lexer-filetype
There are three important things to obey:
the configuration file should be placed in "~/.config/geany/filedefs"
the configuration file must have the extension ".conf" - otherwise it won't show up at all (the files in "/usr/share/geany/filesdefs", where I copied my base file from, do not have a ".conf" extension!)
you must set the "lexer_filetype" to an existing (presumably builtin) configuration; e.g. "lexer_filetype=Python"
I've seen some build settings being used like
$(PRODUCT_NAME:identifier)
Using :upper also makes the setting value uppercase, but I don't know what those are called and can't find any documentation. Does anyone know their name or where the documentation is to use them properly?
The file /Developer/Library/PrivateFrameworks/DevToolsCore.framework/Versions/A/DevToolsCore has a bunch of these:
[ 09:22 root#MacBookPro / ]# strings /Developer/Library/PrivateFrameworks/DevToolsCore.framework/Versions/A/DevToolsCore | egrep "(^:|^[a-z0-9]+$)"
:children.count=%lu
:name='%#'
:File='%#':Line=%lu:RefType=%#
:fileRef=%#:timestamp=%lu
:char-range=%#
:line-range=%#
:<range-type-%lu>=%#
:name='%#'
:name=%#:path='%#'
:name='%#'
:name='%#':buildSettings(%lu)=%#
:path='%#'
:quote
:identifier
:rfc1034identifier
:dir
:abs
:remoteRef='%#'
:File='%#':Head Revision=%#:Active Branch=%#
:scmProprties='%#':sandboxEntry='%#'
.... SNIP ....
upper
environment
diagnostics
type
category
description
path
kind
message
ranges
alternate
start
edges
location
file
Found this as well: DevToolsCore Framework Reference. Looks like an API for the Framework (- (id)initWithName:(id)arg1 productTypeIdentifier:(id)arg2).
Couldn't find any other documentation for it though, just this SO question (xcode-info-plist-build-variable-product-namerfc1034identifier-seems-complete).
Since they are not documented I don't think they have a name. When building Xcode 4 templates I found 3 variable modifiers in the Apple templates that seem to do the following:
identifier: ensures that it is a legal C variable name. It replaces illegal characters with underscores.
bundleIdentifier: ensures that it is a legal bundle identifier.
RFC1034Identifier: ensures that it is a legal domain name.
And thanks to you I know another one:
upper: change the value to uppercase.
The Xcode project templates are not documented. They are defined in plists with an inheritance system. Their elements have a defined structure and use several expansion macros with double underscore like __PACKAGENAME__ (also seen in Xcode 3) that are modified with one of the modifiers mentioned above.
If you want to dig further on this I recommend Documentation: Xcode 4 templates. Learning Apple's template system was painful and slow until I stumbled onto this PDF. It's $10/€7,50 but it's worthy. Writing templates remains very cumbersome, I guess Apple engineers use an internal tool or a great deal of patience.
The build settings are called "build settings" and they are documented in the Xcode Build Setting Reference. The Product Name defaults to your target name, but you can make up your own value if you like. These settings are referenced when writing scripts. Usually you don't need to touch anything while using XCode.
/* $Id: file.c,v 1.0 2010/09/15 01:12:10 username Exp $ */
I find this line in many source code files in the comment at the top (header) of the file. Why? Is it aimed for the version control software? -Thanks.
These sort of comments are automatically modified by various source code control systems, things like author, date, history and so forth.
See here for some common ones for RCS which is the first source code control system I ever saw to implement this sort of thing (that doesn't mean it was the first, just that RCS was the first I ever used and it had that capability).
One particular trick we used to use was to put the line:
static char *fileId = "$Id: $";
into the source file (and header files as well, although the names had to be unique) so that, when it was built, it would automatically have the ID of the files in the executable itself.
Then we could use something like strings to find out which source files were used to build the executable. Ideal for debugging problems in the field.
It tells CVS (and other VCSs) to expand the value of the Id at check-out time, so anybody reading the source file in question will know what version exactly was checked out for it. Not very popular any more (you can always ask your VCS for such info if you keep the source file in a client / repository / working directory -- or however else your VCS calls such things;-).
I believe you are correct. It appears to be a keyword substitution string for CVS.
Take a look at this question $id: name of file, date/time creation Exp $