It appears that vim.org supports questions only via mail and/or mail digests, and vim's own internal :help utility doesn't give me what I think I need regarding highlighting, so I'm here to ask my question. General searching via google gives me no good hits, possibly revealing that I'm just not asking with the right search terms.
My question will be: Can I highlight by regex independent of search highlighting?
If there is a stackoverflow site intended for vim questions such as that?
The simplest built-in way is
:mat[ch] {group} /{pattern}/
e.g. :match ErrorMsg /ERROR:/; you have two more slots with :2match and :3match (some plugins use those, too), and programatically an arbitrary number via the matchadd() function.
Differences
Whereas the search pattern is global in scope, the :match applies only to the current window. That can be unexpected. If you would like to have a quick way to define (and also jump to) some additional patterns (and don't mind installing a plugin), I can recommend you my Mark plugin.
There are tons of vim questions here on SO answered by some highly skilled vimmers so I don't see the need for a separate vim-SO-site...
But if you feel like creating one, you can always propose one at http://area51.stackexchange.com/
To answer your vim question: Have a look at this page http://vim.wikia.com/wiki/Highlight_multiple_words
Which describes a method to use multiple highlights.
Related
I installed Latex-Suite for Vim, and I like it very much, but I'd like to be able to customize the environment mappings that came by default, and add new ones. For example I want to edit the equation environment that appears typing EEQ and move around some elements, like the \label{} command. How can I do this? I've been scanning everything inside my /usr/share/vim/vimfiles/ftplugin but I can't find a way to do it (or I just don't understand what those files are).
You want to check out the documentation on Macro Customisation, specifically the Tex_Env_{name} bit.
In short, if you want your theorem snippet to look like
\begin{theorem}
<++>
\end{theorem}<++>
then you want a line like
let g:Tex_Env_theorem = "\\begin{theorem}\<CR><++>\<CR>\\end{theorem}"
in your vimrc.
Note the backslashes to escape carriage-return, and double-backslash for normal backslashes.
The <F5> functionality (press F5 after typing an environment name, i.e. figure<F5>) should work out of the box, but you may need to refresh the three-letter code. This is more hassle than it needs to be, but something like
autocmd BufNewFile,BufRead *.tex call IMAP('EFI', g:Tex_Env_figure,'tex')
will do the job.
The answer to the question you asked comes with a caveat, which is that Latex-Suite is an enormous amount of code that is very hard and annoying to modify, and which does not play nicely with other plugins. This falls into Latex-Suite's philosophy that it's the only plugin you need for editing latex within vim.
That said, you want to look in /path/to/ftplugin/latex-suite/envmacros.vim. Searching for EEQ will lead you on the path to understanding the set of calls that latex-suite performs. I would like to reiterate that many functions are deeply intertwined.
On the other hand, there is a very easy way to have very easily customizable environments, which are snippets. See the UltiSnips page for a good example of how this works. These are designed for customization and extremely easy to write.
The documentation of linebreak says:
This option is not used when the 'wrap' option is off or 'list' is on.
I find this unsatisfactory. Is there a workaround to use certain listchars and linebreak?
My ideal .vimrc looks like this:
set linebreak
set list
set listchars=tab:▸–,trail:·,extends:»,precedes:«,nbsp:⍽
… so I’m not actually interested in eol:$, which is presumably the reason why list conflicts with linebreak (that’s just my assumption but I see no other plausible reason for them to conflict).
There’s a closely related question but in that the OP specifically wants the EOL mark, and the accepted answer addresses only this, so it’s not useful for me.
I would guess (but do not know for sure) that the current implementation cannot deal with the change of the displayed width when a Tab character shrinks to ^I (assuming it has no value in 'listchars'). In any way, I think Vim could be enhanced to do just what you want, though it might not be easy to implement. It might be worth to raise this request on the vim_dev mailing list.
There are little good workarounds; one could theoretically use the new conceal feature to emulate certain things of :set list, but it interferes with syntax highlighting and there's only one choice for highlighting.
Is there a VIM absolute (registers, marks, undo history, tags) bar or tree toggle ?
I mean, like the tag-bar, but with subsections. Having the primary sections to be the followings, custom marks, custom registers, custom records, undo history (as the Gundo plug-in). So undo the bar, we can go to a mark, execute a record, yank or paste a register, etc.....
If there is not, would anyone like to help me build it??? Or just, help me with good starting tutorials for vim plug-in building, since it'll be the first one that I'll make.
No, there's nothing like that, what would be the point of such a monster?
Aren't :marks, :registers, :changes, :undolist… enough?
Anyway, you should start by getting familiar with Vim's built-in documentation: :help eval contains all the raw info you will need.
Steve Losh's Learn Vimscript the Hard Way is a really great third party ressource and the Vim Wiki can be useful, too.
Though plugins like tagbar and Gundo efficiently display information in a side bar, like IDEs, this is mostly a concession to what today's users are used to, but not a fundamental way to use vi(m). Marks and registers are meant to be memorized by their names (a..z), with the :marks, :registers, etc. commands to provide you a refresher after a long break / the next day.
There are many plugins (e.g. for automatic mark management and visualization), but I would recommend to use them sparingly. It's definitely a "smell" if you want to turn Vim into a full-blown IDE. Please don't.
I'm making a colorscheme for Vim and have a command that allows me to view the 'scope' of a attribute to highlight, but I need some of the general attributes (background, line numbers, etc.) so I can properly create my scheme. Is there any good cheat sheets or lists of some of the attributes? I checked all the Vim documentation and wikis but they don't list many things that affect the editor itself.
Yes, there is such a list. All you need is in Vim's awesomely-exhaustive-but-sometimes-cryptic documentation: :help syntax, more specifically :help highlight-default for a list of default highlight groups. If something is not there it probably means that it can't be done or that it's custom/syntax-dependant.
You could also open a pre-existing colorscheme and see how it's done. It's actually not that complicated to understand how the syntax works.
Good luck and make sure to share your colorscheme with the community when it's ready.
May be you'll find useful this colorscheme: http://www.vim.org/scripts/script.php?script_id=106 .
Here is the description given by author:
The philosophy here is to provide a ready-to-uncomment list of highlight commands for all the important groups. Then you can deviate from the default until you come up with one you like.
I have recently started using Vim as my text editor and am currently working on my own customizations.
I suppose keyboard mappings can do pretty much anything, but for the time being I'm using them as a sort of snippets facility almost exclusively.
So, for example, if I type def{TAB} (:imap def{TAB} def ():<ESC>3ha), it expands to:
def |(): # '|' represents the caret
This works as expected, but I find it annoying when Vim waits for a full command while I'm typing a word containing "def" and am not interested in expanding it.
Is there a way to avoid this or use this function more effectively to this end?
Is any other Vim feature better suited for this?
After taking a quick look at SnippetsEmu, it looks like it's the best option and much easier to customize than I first thought.
To continue with the previous example:
:Snippet def <{}>():
Once defined, you can expand your snippet by typing def{TAB}.
Snipmate - like texmate :)
http://www.vim.org/scripts/script.php?script_id=2540
video:
http://vimeo.com/3535418
snippet def
""" ${1:docstring} """
def ${2:name}:
return ${3:value}
As another suggestion (although slightly different) using vim's built in functionality:
:iabbrev def def(): #<LEFT><LEFT><LEFT><LEFT><LEFT>
Now whenever you type def followed by a space or other non-word character, it will expand to the same as what you've given as the output of SnippetsEmu (the space comes from the space you entered to trigger the completion).
This approach doesn't suffer the "lag" issue you encountered using :inoremap, and is built-into vim. For more information on this feature, look at :help abbrev.
You may be concerned that being triggered by space not tab it will trigger unnecessarily, but in general vim is pretty smart about when to trigger it. The issue can be additionally mitigated by enabling the abbreviation only for certain file-types (eg, python):
au filetype python :iabbrev ... etc
Snip[ets] (Manager|Emu|Mate|.vim) is of course also a perfect solution, but it's nice to be aware of the alternatives (especially when they are built in).
If SnippetsEmu is too heavy or ambitious for what you need (it was for me), I wrote a plugin that manages snippets based on filetype. It even has tab completion when picking the snippet! :)
Get it here: snippets.vim
I just installed UltiSnips. There’s a good article that explains why you might choose UltiSnips: Why UltiSnips?
I haven’t used any of the other snippet plugins; I decided to take the plunge with one that seemed full-featured and would be able to accommodate me as I gain more Vim skills and want to do more sophisticated things.
SnippetsEmu is a useful snippets plugin.
As noted by MDCore, SnippetsEmu is a popular Vim script that does just that and more. If you need only expanding (without moving back the caret), you can use the standard :ab[breviate] command.
:ab[breviate] [<expr>] {lhs} {rhs}
add abbreviation for {lhs} to {rhs}. If {lhs} already
existed it is replaced with the new {rhs}. {rhs} may
contain spaces.
See |:map-<expr>| for the optional <expr> argument.