VIM: created syntax not showing up? - syntax

HI people
I recently changed to VIM for coding in C.
I'd like to hightlight the operators +-<=& ... etc
I searched in google how should i do it, and i found the answer in this website: I was suppose to do something like:
syntax match Operadores /[][><()&!|+*={}-]/
hi Operadores guifg=#000000 gui=BOLD
Those characters were supposed to appear as black, bold characters.
However, that doesn't happen when I open my .C files. However, if I create a newfile, (where there the C syntax doesn't show up), I am able to see the black, bolded operators.
How can i correct this situation, and why is this happening (it seams like if my syntax is beeing overwrided by the C syntax).
I'm using gvim, and this is my vimrc:
colorscheme nicotine
set smartindent
set number
set guifont=Inconsolata\ Medium\ 11
set numberwidth=5
noremap j jzz
noremap k kzz
Thanks, any help is appreciated.
(And dont forget I'm a novice in VIM, and ..sorry for my English)

The best way to do this is putting those two lines in the following file:
~/.vim/ftplugin/c.vim
creating it if it's not already present (of course you need to adjust the path to your personal Vim directory if you're not on un*x). That file is called for every C file you edit, and it's executed after the default scripts so your syntax won't be overridden.
For ftplugin to work you also have to add
filetype on
although a full
filetype plugin indent on
is usually more generally useful.

Related

how to turn off all vim settings for golang?

How could I turn off syntax highlighting in vim, but only for Go?
I've seen a few posts about just turning off the red-highlighting for white space but that's not quite what I'm looking for.
Add the following line to your vimrc file:
autocmd FileType go setlocal syntax=OFF
Considering that the vim documentation states
The syntax and highlighting commands for one language are normally stored in
a syntax file.
The name convention is: "{name}.vim". Where {name} is the
name of the language, or an abbreviation
If you can find a go.vim file (similar to this one) and delete it (or move it), that should disable the syntax highlighting just for Go.

Custom syntax highlighting in Geany

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"

What are these shell escape characters?

I'm trying out the coffee script repl inside Emacs (under ArchLinux) and I'm seeing these escape characters surrounding the prompt:
[1Gcoffee> [0K[9G
These shouldn't be colors as I already enabled the ansi-color-for-comint-mode. So does anyone recognize these?
P.S.: Funny thing is I don't have this issue under my Emacs+Cygwin setup!
I don't know where they're coming from (something to do with your shell prompt, obviously, but it's hard to say more than that).
I read them as:
ESC[1G - Move to column 1 (Cursor Character Absolute)
ESC[0K - Erase to right
ESC[9G - Move to column 9
It looks like an attempt by the shell to ensure that the prompt is at the far left of an empty line. Not sure what shell you have, but zsh does something similar when the PROMPT_SP option is enabled. I don't think it uses the above sequences, though.
Many, many, control sequences can be found here. Note that the sequence "ESC[" is interpreted as a "Control Sequence Introducer" (CSI) and is shown as that on that page.
I had the same problem and was able to solve it by adding
export NODE_NO_READLINE=1
to my .bashrc file.
So, the characters appear to have come from the CoffeeScript REPL's use of Readline. Perhaps the reason you didn't have the issue in Cygwin was because Readline wasn't available there.

What are the advantages of using vim to program Ruby (over Notepad++)? (other languages, too, but specifically Ruby) [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been using Notepad++ for a while; in fact, I've even started using Launchy for that "load this resource into the editor right now" functionality that many fuller IDE's like Eclipse has. It has syntax highlighting, split window view, code collapsing, parentheses (and other delimiter) paring, automatic indent, block commenting.
However, it seems that everywhere I go, people are using vim for their programming needs.
I know the basics of vim; it's my main "basic text editor" when I'm on a linux machine; I use it like I'd use the basic Notepad on Windows. I get the controls, most of the shortcuts, the repetition eliminators, etc.
What I'm not quite understanding are these killer apps that people are espousing about. How "debugging Ruby in vim was a life-changing experience", or how, when using it, magic occurs.
Am I missing some essential plug-ins? Is there a dimension I'm not seeing? Should I just shut up and start using it for a bit, to see? How do I get syntax highlighting?
I'm specifying Ruby specifically because I'd like to find some plugins for it. Note that I am not using Rails, and answers should be rails-independent of possible. But I would appreciate some general vim-ness koans about programming in other languages, as well.
Thank you, and I hope my question isn't too vague or inspires any nasty editor wars.
I use vim for all my Ruby programming, and I think its customizability is its killer feature. With vim you can do just about everything to text you can imagine, if you're willing to invest the time to hunt down the plugins that do what you want or write a few scripts yourself.
I'll just list a few things I like about vim for programming (in no particular order):
Syntax Highlighting
The ruby syntax highlighting is very nice. One thing in particular that seems to be somewhat unique is that keywords can be colored differently depending on context. This isn't used as much as I would like, but you can easily see whether that end statement closes, say, an if-statement or a function definition.
Also nice is that, since vim knows which parts of the text are comments, you get spell checking for these only.
Automatic indenting.
When you're writing code, vim will automatically place the cursor at the right indentation level, so you don't have to worry about that. I also find myself invoking this functionality manually by selecting a block and pressing = to automatically (re-)indent everything I highlighted.
Autocompletion
I use a plugin that automatically pops up completions.These are very versatile. They know the methods of classes from the standard library, look at other files you have open (good for variable names and class methods), recognize when you're typing a filename, etc.
Snippets
There is a plugin called snipMate that provides shortcuts for often used text snippets. It's a big help with writing tests and the like.
Code folding
Scriptability
As I said, vim's scripting is very powerful. Want extraneous whitespace at the end of the line deleted automatically? Just write a one-line script.
Plugins, Plugins, Plugins!
There are a ton of plugins that help you with all kinds of things. Git integration, Rails integration, Rspec integration, autoclosing parentheses, matching keywords that open a block {def,do,if,while, etc.} to their end... the list is practically endless.
It's an exceedingly powerful editor out of the box, it integrates well with version control, and there are bucketloads of good add-ons available. (See the scripts page as well as the tips wiki.) Those are good reasons to consider Vim, but there are plenty of other good editors available for various platforms. (Look, Ma, no religious editor wars!)
In terms of very Ruby-specific add-ons, check out endwise by Tim Pope, as an example. (It automatically inserts end after do, if, etc.) Actually nearly all of Tim Pope's scripts are potentially useful for Rubyists.
How do I get syntax highlighting?
You need at least a minimal .vimrc or .gvimrc to get syntax highlighting and automatic indentation (assuming you want that). Vim ships with examples that can get you started, and if you search for 'vimrc' or 'gvimrc', you will get plenty of hits. That said, here's some of mine to get you started:
" Most general settings first
set nocompatible " Set Vim rather than Vi settings; must go first
set noeb " Set no audio or visual error beep
set bs=indent,eol,start " Backspace over everything in insert mode
set history=500 " Keep 50 lines of command line history
" Set items for view # bottom of windows
set ruler " Show the cursor position all the time
set showcmd " Display incomplete commands
set showmode " Display current mode
set ls=2 " Always show status bar
" Syntax basics
syntax on
filetype indent on
set autoindent
set smartindent
filetype plugin on
" Text basics
set textwidth=80 " Set text to wrap at 80 columns
set expandtab " Convert tabs to spaces
set tabstop=4 " Tabs = 4 spaces
set shiftwidth=4 " Indent/outdent 4 spaces
set softtabstop=4 " Tab key indents
set shiftround " Indent/outdent to nearest tabstop
set smarttab " Uses shiftwidth # start of lines
set fo=trcn
" An exception for Ruby files
autocmd FileType ruby set tabstop=2
autocmd FileType ruby set shiftwidth=2
autocmd FileType ruby set softtabstop=2
autocmd FileType ruby set number
" Search basics
set incsearch " Do incremental searching
set showmatch " Show matching brackets
set hlsearch " Highlight all matches in a search
" Don't use Ex mode, use Q for formatting
map Q gq
" Pick a colorscheme
colorscheme Dim
My personal killer feature of vim is the humble . command. This command repeats the last edit at the current cursor position. This can save oodles of time.
For me, one of the "killer features" of vim is it's ad-hoc macros.
Press q then a key name to store the macro in (I often use m for a macro mnemonic, but any letter is fine) and you'll notice the recording status at the bottom. Now, any key strokes you press will be recorded until you press q again, and you've recorded a macro in the letter m. Now type #m and your keystrokes will be played back, with all their implications, starting from the current cursor position. Press 20#m and you'll replay the macro 20 times, and now you've got a powerful tool for programmatically editing text without the overhead of writing a larger program (or configuration file).
For Ruby specifically, the syntax highlighting (:syn on), automatic indent (:set cindent), and paren/bracket paring (% to move the cursor to the matching brace) and other features can be found in other editors, as you mention. But really, the general text processing macros in vim are a big advantage for any text file.
I think the main advantage VIM has is the fact it's cross platform. Now you're using notepad++, that is a great editor(even if it hasn't good macros capabilities). Tomorrow, you could be obliged to use another OS, and you should learn to use another text editor.
I know where you are coming from. I used IDEs and even notepad++ for longer than I care to remember. If all you use VIM for is basic navigation, you aren't going to be using it to its full potential. while there are several very powerful plugins, I don't believe that finding the right plugin is what makes VIM so powerful.
What does it for me is that my hands do not move from the keyboard and it allows me to stay in the zone. Every time I go to the mouse, it invariably leads to a concentration break - which as a programmer is the unforgivable sin.
The other killer feature for me is searching and replacing using regex. I highly recommend learning more about it. Or in the words of Jamis Buck, "Know Thy Tools".
ftp://ftp.vim.org/pub/vim/doc/book/vimbook-OPL.pdf
is a great way to get started, but I think I would recommend the O-Reilly book over this one if you want to spend the money. It is easy to get the basics in VIM, but mastering it takes time - but they payoff is immense.

What setting in vim counteracts smartindent's refusal to indent # comments in shell scripts?

I recently started using vim 7 (previously vim 6) and the smartindent setting. For the most part, it works well, though I'm so used to typing a tab after an open brace that it is almost counter-productive.
However, there is one piece of maniacal behaviour. When editing a shell script, I try to create a comment at the current indent level, but smartindent will have nothing to do with it. It insists that the comment must be at level 0 (no indent). What's worse, it breaks shift-right ('>>' and friends) so that they do not work. This is outright insubordination, and I'd like to know what's the best way to fix it?
(I'm also not keen on smartindent's ideas about indenting then after if.)
Preferred solutions will save me manual bashing - I'm being lazy. One option would be 'turn off smartindent when editing shell scripts (leave it on for the rest)'. Another option would be guidelines on how to find the control script for smartindent and what to edit to change the characteristics I don't like. The final option (which I don't need advice on how to do - just the hint that it is the best, or only, way to restore sanity) is to leave smartindent unset.
I saw the vaguely related question on "(PHP and) annoying vim unindent rules"; it doesn't provide me with the direct answer, though maybe the cindent and related items mentioned in there are in fact part of the answer.
Find the indent file, (e.g. /usr/share/vim/vim71/indent/sh.vim on my system)
This line looks like the problem:
setlocal indentkeys-=:,0#
Perhaps you can fix this in your .vimrc or load a custom indent file manually.
edit: It looks more complicated than I thought, but maybe there is something specifically set in the indenting file that you would need to fix.
2nd edit: Looks like I was completely wrong, Check out:
Restoring indent after typing hash
or
howto-configure-vim-to-not-put-comments-at-the-beginning-of-lines-while-editing
Well, after exploring some options, including using ':set cindent' instead of ':set smartindent', I've ended up reverting to just using ':set autoindent'. There probably are ways to make this stuff work exactly as I want it to, but it is messy enough and fiddly enough that I can't be bothered. I've worked fine with autoindent for the previous 20-odd years, and the benefits from the extra bells and whistles provided by smartindent are outweighed by the what I regard as its misbehaviour.
Thank you, Juan, for your assistance. Believe it or not, it did help - quite a lot.
I also discovered a couple of other neat commands, though, while following up on this:
>i}
>a}
These right-shift the block of code you are in. The 'i' version indents the body and not the closing braces (my preferred style), and the 'a' version indents the closing braces to (the version that is required at work).
Also, you can apply qualifiers to '%' in commands executed at the shell:
:make %:r.o
This would run make on the 'root' of the current file name (that's '%:r') followed by '.o'. Or, in other words, if I'm editing somefile.c, this executes make somefile.o.
Add the line below in your .vimrc
filetype indent on
(it will set the right indent mode depending on the filetype)
I had this same issue for a long time, until I realized that autoindent and smartindent are both unnecessary if "filetype indent on" is set in your vimrc - 'filetype indent on' uses the indent/sh.vim (or whatever language) file in your vim directory to figure out the indentation rules, and autoindent and smartindent both can interfere with it.
I haven't tested this with sh, but perl suddenly started behaving properly when I switched.
Sidenote: Juan's redirect, "Restoring indent after typing hash", is not a good solution - while it does correct the problem in one situation (typing code in), it doesn't change how the editor thinks it should be indented, so a re-indent (visual =, or normal ==) will shove it back to the left.
The previous answer suggesting:
:inoremap # X^H#
is excellent. It is the answer suggested by the VIM documentation at ":help smartindent". Note that ^H is entered using CTRL-V CTRL-H. The relevant section from the documentation is below.
When typing '#' as the first character in a new line, the indent for
that line is removed, the '#' is put in the first column. The indent
is restored for the next line. If you don't want this, use this
mapping: ":inoremap # X^H#", where ^H is entered with CTRL-V CTRL-H.
When using the ">>" command, lines starting with '#' are not shifted
right.
I have the following lines in my .vimrc and I don't observe the problem.
set smartindent
inoremap # X^H#
I used to have set autoindent after these two lines but it seems that it has no effect.
Yes that is very annoying. smartindent is really only for C like languages.
See how I enable the appropriate indenting based on language at:
http://www.pixelbeat.org/settings/.vimrc

Resources