How can I make Gvim to treat(syntax highlighting) lines starting with # and ; in an assembly file as comment ? Meaning in addition to ; (which is normally the way to represent comment in assembly)
If the file is being recognised as Assembler, it will have it; $VIMRUNTIME/syntax/asm.vim has the line syn match asmComment "[#;!|].*" contains=asmTodo which matches # lines as comments.
Going by the contents of Vim 7.3's $VIMRUNTIME/filetype.vim, .asm, .s, .S, .a, .A, .mac and .lst files will all be recognised as Assembler. If you are having a different extension, look at :set ft to see what it's being recognised. You may need to override it in your ~/.vimrc:
augroup filetypedetect
au BufNewFile,BufRead *.whatever setf asm
augroup END
On you installation, you have a file called syntax\asm.vim which should define color syntax rules for assembly.
On my installation, I got the following line:
syn match asmComment "[#;!|].*" contains=asmTodo
Which means that lines starting by # (or ;) should be considered as comments and it does work on my installation.
You can check in filetype.vim if the file you are working on is recognized as asm.
In your .vimrc or .gvimrc which are vim configuration files, you need :
" Syntax highlighting and filetypes
filetype plugin indent on
syntax on
Related
Asking this question is my last resort. I try to run "make all" and I get the error
Makefile:457: *** missing separator. Stop.
on the the line with cloc (second line).
linecount:
cloc --read-lang-def=$(PROJECT).cloc \
src/$(PROJECT) include/$(PROJECT) tools examples \
python matlab
I changed spaces to tabs both on that line and inside the file $(PROJECT).cloc. However, the error persists. And it only appears on that line. I am at a loss.
Use vim or vi to open makefile then write :set list it will show you all the spaces and tabs. Tabs are ^I and line endings are ^$ . Make sure your indentation is always with tabs instead of spaces or even 4 spaces. 4 spaces doesn't make a tab in makefile you should use tabs for indentation. You can make this with other editors as well.
You can do the same thing as in Alperen's answer with nano by opening the makefile and using the key combination alt+shift+p to enable whitespace display where tabs will be represented by a > character and spaces by a . character. This will indicate what make is 'seeing' at the beginning of that line, it may not be a tab character despite what it may seem.
When installing my package, the user should at some point type
./wand-new "`cat wandcfg_install.spell`"
Or whatever the configuration file is called. If I put this line inside \code ... \endcode, doxygen thinks it is C++ or... Anyway, the word "new" is treated as keyword. How do I avoid this is in a semantically correct way?
I think \verbatim is disqualified because it actually is code, right?
(I guess the answer is to poke that Dimitri should add support for more languages inside a code block like LaTeX listings package, or at least add an disableparse option to code in the meantime)
Doxygen, as of July 2017, does not officially support documenting Shell/Bash scripting language, not even as an extension. There is an unofficial filter called bash-doxygen. Simple to setup: only one file download and three flags adjustments:
Edit the Doxyfile to map shell files to C parser: EXTENSION_MAPPING = sh=C
Set your shell script file names pattern as Doxygen inputs, like
e.g.: FILE_PATTERNS = *.sh
Mention doxygen-bash.sed in either the INTPUT_FILTER or the
FILTER_PATTERN directive of your Doxyfile. If doxygen-bash.sed is in
your $PATH, then you can just invoke it as is, else use sed -n -f /path/to/doxygen-bash.sed --.
Please note that since it uses C language parsing, some limitations apply, as stated in the main README page of bash-doxygen, one of them, at least in my tests, that the \code {.sh} recognises shell syntax, but all lines in the code block begin with an asterisk (*), apparently as a side-effect of requiring that all Doxygen doc sections have lines starting with double-hashes (##).
I already looked through other topics, but I still couldn't find a solution. I'm trying to install "nxhtml" plugin for Emacs in windows 7. I already setup my "HOME" environment variable as "C:\". So, my .emacs.d folder is there, and I put the nxhtml in there and added the following line to my "_emacs.d" file, as the readme says:
(load "C:\.emacs.d\nxhtml\autostart.el")
But it doesn't load.
I also tried putting:
(add-to-list 'load-path "C:\.emacs.d\nxhtml")
(load "autostart.el")
But to no avail... can anyone shed some light here? tnx.
A number of points here:
Firstly, _emacs.d is not a default file name for your init file, ie emacs will not load it automatically. Try ~/.emacs.d/init.el, or ~/.emacs instead.
Secondly, Windows 7 has a feature where it prevents programs from writing to certain system directories, but for backwards compatibility for the many old programs that do this, rather than causing them to fail, it silently redirects the write elsewhere, in an application specific directory. C:\ is one of those directories, so setting your HOME to point there is asking for trouble.
Thirdly, see the other response about backslash being an escape character in Lisp strings.
\ is special in the (double-quote) read syntax for strings, as certain characters take on a new meaning when prefixed by a backslash (e.g. \n is a newline, \t is a tab, and \" is a double-quote character). When the following character does not have any special meaning in conjunction with the backslash, that character is used verbatim, and the backslash is ignored.
"C:\.emacs.d\nxhtml\autostart.el" is actually the string:
C:.emacs.d
xhtml^Gutostart.el
To include a \ in the string you need to write \\
However, although it will understand the backslashes, Emacs is nowadays consistent across all platforms in allowing / as a directory separator1; so just do that instead.
1 and the obsolete directory-sep-char variable has been removed entirely.
I got a useful tip from this post: https://stackoverflow.com/a/374363/151453 , but plagued by doskey's special characters.
(env: Windows 7 and Windows XP)
Using Visual C++ command line, we have env-vars INCLUDE and LIB. So with this doskey macro,
doskey whichinclude=for %i in ($1) do #echo.%~$INCLUDE:i
we can easily findout which .h is found first in which INCLUDE directory, really convenient.
However, this trick fails for LIB. I just CANNOT simply code a macro like:
doskey whichlib=for %i in ($1) do #echo.%~$LIB:i
Call whichlib winsock32.lib, it spouts The system cannot find the file specified.
I launch Procmon to know what happens, it reveals:
So I realize $L has special meaning for doskey, it is replaced with current drive letter when run.
Try double dollar( #echo.%~$$LIB:i ), still not working, Procmon report CMD accessing C:\echo .
Counld someone kindly help me out?
My doskey book mark: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/doskey.mspx?mfr=true
I agree with Michael Burr's comment - you may be better off with a batch file. I generally do not use DOSKEY macros because they do not work within batch files, so it seems kind of pointless. In my mind, if a command works on the command line, it should also work within a batch file.
But... it is possible to do what you want :)
The $ only has special meaning if it is followed by a character that has special meaning to DOSKEY. The $L is interpreted as the < character (input redirection). The MS documentation implies that $$L should give a $L literal, but the documentation is not correct, as you have discovered.
The DOSKEY $ substitution happens before the normal command line parsing. The trick to embed a literal $L in your macro definition is to put an intervening character between $ and L that is not treated as special by DOSKEY, but that disappears during the normal command line parsing - The ^ works perfectly. $^ has no special meaning to DOSKEY, and ^L simply becomes L during command line parsing.
You can list the definition of your DOSKEY macros by using DOSKEY /M.
The full definition you require is whichlib=for %i in ($1) do #echo(%~$^LIB:i.
The ^ must be escaped when you define the macro. So the complete line to define the macro becomes:
doskey whichlib=for %i in ($1) do #echo(%~$^^LIB:i
What character can I use to put comments in an Exuberant Ctags .ctags file?
I would like to add comments with explanations, and perhaps to disable some regexps.
But I can't find any comment character which ctags-exuberant accepts!
I keep getting the warning:
ctags: Warning: Ignoring non-option in /home/joey/.ctags
which is better than an error, but still a little annoying.
I have tried # // /* ... */ and ; as comments, but ctags tries to parse them all!
Here is an example file with some comments which ctags will complain about:
# Add some more rules for Javascript
--langmap=javascript:+.jpp
--regex-javascript=/^[ \t]*var ([a-zA-Z_$][0-9a-zA-Z_$]*).*$/\1/v,variable/
--regex-javascript=/^[ \t]*this\.([a-zA-Z_$][0-9a-zA-Z_$]*)[ \t]*=.*$/\1/e,export/
--regex-javascript=/^[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*):.*$/\1/p,property/
--regex-javascript=/^\<function\>[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*)/\1/f,function/
# Define tags for the Coffeescript language
--langdef=coffee
--langmap=coffee:.coffee
--regex-coffee=/^class #?([a-zA-Z_$][0-9a-zA-Z_$]*)( extends [a-zA-Z_$][0-9a-zA-Z_$]*)?$/\1/c,class/
--regex-coffee=/^[ \t]*(#|this\.)([a-zA-Z_$][0-9a-zA-Z_$]*).*$/\2/e,export/
--regex-coffee=/^[ \t]*#?([a-zA-Z_$][0-9a-zA-Z_$]*):.*[-=]>.*$/\1/f,function/
--regex-coffee=/^[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*)[ \t]+=.*[-=]>.*$/\1/f,function/
--regex-coffee=/^[ \t]*([a-zA-Z_$][0-9a-zA-Z_$]*)[ \t]+=[^->\n]*$/\1/v,variable/
--regex-coffee=/^[ \t]*#?([a-zA-Z_$][0-9a-zA-Z_$]*):.*$/\1/p,property/
You can't! I looked through the source code (thanks to apt-get source). There are no checks for lines to ignore. The relevant code is in parseFileOptions() in options.c
But sometimes comments are a neccessity, so as a workaround I put a comment in as a regexp, in such as way that it is unlikely to ever match anything.
--regex-coffee=/^(COMMENT: Disable next line when using prop tag)/\1/X,XXX/
The ^ helps the match to fail quickly, whilst the ( ) wrapper is purely for visual effect.
Your comment should be a valid regexp, to avoid warnings on stderr. (That means unescaped /s must be avoided, and if you use any [ ] ( or )s they should be paired up.) See Tom's solution to avoid these restrictions.
As #joeytwiddle points out, comments are not supported by the parser, but there is a work-around.
Example .ctags file:
--regex-C=/$x/x/x/e/ The ctags parser currently doesn't support comments
--regex-C=/$x/x/x/e/ This is a work-around which works with '/' characters
--regex-C=/$x/x/x/e/ http://stackoverflow.com/questions/10973224/how-to-add-comments-to-an-exuberant-ctags-config-file
--regex-C=/$x/x/x/e/
--regex-C=/$x/x/x/e/ You can add whatever comment text you want here.
You can use '#' as the start of comment if you are using Universal-ctag(https://ctags.io).
Given that comments don't work, what about a .ctags.readme file...
For most things you don't actually need a comment, e.g. you don't really need the comment below.
# Define tags for the Coffeescript language
--langdef=coffee
--langmap=coffee:.coffee
I can see however that you might want to add comments explaining some mind bending regex, so for each line that absolutely needs it you can copy paste it into the .ctags.readme file as a markdown file:
Forgive me father for I have regexed
It was purely because I wanted some lovely coffee properties
```
--regex-coffee=/^[ \t]*#?([a-zA-Z_$][0-9a-zA-Z_$]*):.*$/\1/p,property/
```
Keeping .ctags.readme and .ctags in sync
You could have a block at the bottom of the ctags file separated with a line break, then delete this final block.
If you only have the one line break in your .ctags file this sed will delete all the lines after the line break.
Then do some grepping for the --regex lines to append the lines from .ctags.readme into .ctags.
sed -i '/^\s*$/,$d' .ctags
grep "^--regex" .ctags.readme >> .ctags