I have the following AutoHotkey script sample, notice the code is indented by a single space:
#z::
MsgBox The Win-Z hotkey was pressed.
Gosub MySubroutine
return
MySubroutine:
Sleep 1000
return
I searched through the VS Marketplace but didn't find a usable formatter extension for AHK scripts.
I've configured "editor.tabSize": 2, is there a way to format the code to use the specified tabSize with the VSCode built-in formatter?
It looks like there is an AutoHotKey Plus extension that includes formatting that seems to adhere to the Visual Studio Code built-in formatter setting for the tab size. I set my tab size to two and performed the format shortcut using the extension (Shift + Alt + F):
It seems though that certain keywords, such as return will cling to the margin, presumably because the formatter for the extension interprets this as the standard convention for AHK (in my opinion though, I like the way it looks).
This feature request is tracked here.
I added the following comment with backtick for code:
/** Checks if the given data is of type `list`. */
+ (BOOL)isList:(id)object {
// ..
}
but the backtick prints as in the Xcode quick help:
How to get Xcode to display code formatted properly? It works fine when documenting Swift source.
As discussed in the comments above, in Objective-C documentation comments you can use #p or #c to display Typewriter font in the QuickHelp documentation. Whereas Swift documentation comments accept Markdown (using the backticks)
While this answers is relatively old, it still lists a good amount of the options available in Objective-C documentation comments: https://stackoverflow.com/a/19169271/7833793
Here's a brief example:
/// Here's how to use #c Typewriter #c Font
- (void)myMethod {}
Which displays this in the QuickHelp:
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
One of Xcode 5's new features is the ability to document your own code with a special comment syntax. The format is similar to doxygen, but appears to only support a subset of those features.
Which commands are supported, and which ones aren't?
Do any of their usages differ from doxygen?
Here is an example of all the options I have found as of Xcode 5.0.2
That was generated with this code:
/** First line text.
Putting \\n doesn't create a new line.\n One way to create a newline is by making sure nothing is on that line. Not even a single space character!
#a Italic text #em with ##a or ##em.
#b Bold text with ##b.
#p Typewritter font #c with ##p or ##c.
Backslashes and must be escaped: C:\\foo.
And so do ## signs: user##example.com
Some more text.
#brief brief text
#attention attention text
#author author text
#bug bug text
#copyright copyright text
#date date text
#invariant invariant text
#note note text
#post post text
#pre pre text
#remarks remarks text
#sa sa text
#see see text
#since since text
#todo todo text
#version version text
#warning warning text
#result result text
#return return text
#returns returns text
#code
// code text
while (someCondition) {
NSLog(#"Hello");
doSomething();
}#endcode
Last line text.
#param param param text
#tparam tparam tparam text
*/
- (void)myMethod {}
Notes:
The commands must be in a /** block */, /*! block */, or prefixed with /// or //!.
The commands work with the # (headerdoc style) or the \ (doxygen style) prefix. (I.e. #b and \b both do the same thing.)
The commands usually come before the item they are describing. (I.e. if you are trying to document a property, the comment must come before the #property text.) They can come afterwards, on the same line, with /*!<, /**<, //!<, ///<.
You can add documentation to classes, functions, properties, and variables.
All of these commands appear in dark green text to signify that they are valid commands, except for #returns.
You may need to build your project (or restart Xcode) before the latest changes to your documentation appear.
Where to see the documentation:
1. During code complete, you will see the brief text:
This will show the brief text (with no formatting); if no brief text exists, it will show a concatenation of all the text up to the first #block; if none exists (e.g. you begin with #return), then it will concat all the text striping away all #commands.
2. Option-clicking an identifier name:
3. In the Quick Help Inspector panel
(See first screenshot.)
4. In Doxygen
Since the commands in Xcode 5 are compatible with Doxygen, you could download and use Doxygen to generate documentation files.
Other Notes
For a general introduction to Doxygen and how to document Objective-C code, this page seems like a good resource.
Descriptions of some of the supported commands:
#brief: will insert text at the beginning of the description field, and is the only text that will appear during code completion.
The following don't work:
\n: doesn't generate a newline. One way to create a newline is by making sure nothing is on that line. Not even a single space character!
\example
The following are not supported (they don't even appear in dark green):
\cite
\docbookonly
\enddocbookonly
\endinternal
\endrtfonly
\endsecreflist
\idlexcept
\mscfile
\refitem
\relatedalso
\rtfonly
\secreflist
\short
\snippet
\tableofcontents
\vhdlflow
\~
\"
.
::
\|
Apple reserved keywords:
Apple uses what appears to be reserved keywords that only works in their documentation. Although they appear in dark green, it looks like we cannot use them as Apple does. You can see examples of Apple's usage in files such as AVCaptureOutput.h.
Here is a list of some of those keywords:
#abstract, #availibility, #class, #discussion, #deprecated, #method, #property, #protocol, #related, #ref.
At best, the keyword will cause a new line in the Description field (e.g. #discussion). At worst, the keyword and any text following it will not appear in the quick help (e.g. #class).
Swift 2.0 uses the following syntax:
/**
Squares a number.
- parameter parameterName: number The number to square.
- returns: The number squared.
*/
Notice how #param is now - parameter.
You can also now include bullets in your documentation:
/**
- square(5) = 25
- square(10) = 100
*/
Senseful:
You may need to build your project before the latest changes to your documentation appear.
Sometimes this hasn't been enough for me. Closing Xcode and opening the project back up usually remedies those cases.
I'm also getting different results in .h files and .m files. I can't get new lines when the documentation comments are in a header file.
Most of the formatting has changed for Swift 2.0 (as of Xcode7 ß3, also true in ß4)
instead of :param: thing description of thing
(as it was in Swift 1.2)
it is now - parameter thing: description of thing
Most of the keywords have been replaced by - [keyword]: [description] instead of :[keyword]: [description]. Currently the list of keywords that don't work includes, abstract, discussion, brief, pre, post, sa, see, availability, class, deprecated, method, property, protocol, related, ref.
I want to highlight variables in a C/C++ file .
such as:
int num;// Highlighted num
char str;// Highlighted str
struct data
{
int year;
int month;
};
struct data *p,time;// Highlighted p time
..........
How to highlight variables as given above （num ,str, p,time.....）
I know we can modify syntax\c.vim to reach that，but how to write the syntax?
Is there any other solution?
In general, you need to do two things:
Generate tags using ctags;
Generate syntax file using resulting tags file.
Now some details.
There are plugins to help you. Firstly, plugin Indexer automatically generates tags for a whole project and keeps tags up-to-date. (i'm author of this plugin, so, if you have any problems using it, feel free to ask me)
And secondly, there's plugin TagHighlight to extra highlights variables, enums, typedefs, etc.
If you mean how to turn on syntax highligting, then you need to:
:syntax on
If it does not work, determine filetype first:
:set filetype?
Should print "cpp". If not, set it first:
:set filetype=cpp
This question already has answers here:
Custom tags with Doxygen
(3 answers)
Closed 5 years ago.
I'd like to add a custom command to my doxygen documentation. Basically for each C function I'm writing doc for, I need to write which global variables are "touched" in read mode or write mode. It's like the "See also" list, just with a different caption.
In my file I'd like to write something like this:
/*
* \read-globals #var1, #var2
*
* \write-globals #var3
*/
I tried with an alias like this:
read-globals = \par <b>Globals read</b>\n
It works but I fear that it's style sheet independent: If tomorrow I'll want to change css, then this custom command will generate output which looks different from seealso, author and all other sections.
Basically I just want to copy the format from other standard commands.
Another option is to use to the \xrefitem command, which works too, but it requires to introduce a section as second parameter which is totally useless in my case (maybe it can be hidden somehow?).
Is there a "right way" to achieve my goal?
You can combine \xrefitem and ALIASES if you want to hide the second parameter. Here is an example I use for requirements:
ALIASES += "req=\xrefitem req \"Requirement\" \"Requirements\" "
Then in documented code:
/// \req #42 The system shall work in any situation
(from my answer to that question: Custom tags with Doxygen)