I'm using haskellmode, a vim plugin, and when I move my cursor over an editor window in the course of typing code, I get a message at the bottom of the window that says:
no type information (try :GHGReload)
When I do:
:GHGReload
I get the error:
Not an editor command: GHGReload
What is that all about? Or, alternatively, is there a better vim plugin for haskell? I should note I get no auto indenting with haskellmode, which I find surprising. In fact, haskellmode doesn't seem to do anything but change tabs to 8 spaces and give me that error message.
I believe the command is :GHCReload not :GHGReload.
Related
I'm trying to make the jump from VS Code to pure terminal+vim development and I'm missing one efficiency booster from VS Code I used often. When I make some project, and errors are present, the stdout shows the path to the source file with the error, along with the line:column number. In the VS Code terminal I could just left-click with a mouse on that and it would open the VS Code text editor (with the VIM emulator enabled of course), to that location. Is there any similar time saver in the terminal and/or vim? I.e. something that would enable me to go directly from make error to editing that location in vim rather than reading the error log, memorizing the path:line:column and opening that file manually?
For example, lets say I had the following line within the make output:
/home/myusername/someProject/src/foo.c:30:5: warning: implicit declaration of function 'bar'; did you mean 'barr'? [-Wimplicit-function-declaration]
30 | bar(26);
| ^~~~~~~~~~~~~
| barr
Is there any easy way to jump to /home/myusername/someProject/src/foo.c:30:5 without highlighting it with a mouse and copy/pasting it?
The closest thing I found on SO so far was this but I'm guessing the make output will catch errors that only occur after attempting to compile, whereas something in live time like Syntastic is only going to catch syntax errors. I haven't used Syntastic yet, but I'm guessing what they catch has some union of items, but it obviously would be to costly to continuously be compiling in the background to check for compile errors.
I also note the errors themselves, i.e. -Wimplicit-function-declaration are hyperlinks. Maybe there is some setting in make/cmake to generate links for the src files as well?
The user manual, a mandatory read if you are serious about using Vim, dedicates a whole section to compiling: :help 30.1.
In a nutshell…
You choose what Vim calls a "compiler" with the :help :compiler command:
:compiler gcc
It tells Vim:
what external command to execute for compiling your code,
how to interpret the eventual error output.
You execute the :help :make command:
:make %
It tells Vim:
to execute the external command defined above,
and to capture any output in case there are errors to report.
You use the :help quickfix feature to display, navigate, and interact with eventual errors:
:cwindow " opens the quickfix window if there are valid errors
:cn " jump to next error
etc.
FWIW, Vim has very strong roots in C and it shows all over the place. Since running make is the default behavior of the :make command and the default :help 'errorformat' already handles most common C compilers, doing:
:make
followed by:
:cw
in your current project should give you a taste of what to expect:
Real life considerations…
Setting the compiler manually for each file you edit is a PITA. It makes a lot more sense to spend a few minutes putting together an autocommand.
Vim comes with a large and growing collection of "compilers". Check out $VIMRUNTIME/compilers.
Vim provides the basics of the "edit, compile, run" cycle but the experience may not be polished enough out of the box. For example, you might want to open the quickfix list automatically when there are errors, etc. There are basically two ways to address this: using some third-party plugins and/or writing your stuff yourself. I tend to like the latter the most (see this and this for example) but the third-party plugin path is valid, too.
I'm new to Vim. When I use Vim to write Go with vim-go plugin, I found it can mark the statements that go wrong. But what confuses me is that the message on the status bar(or command line?) is truncated and sometimes I couldn't see the whole message. I've tried :messages cmd, and tried to :set cmdheight=5, they just wouldn't work as I expected. Could anyone tell me how to show the full message?
After compilation, vim-latex opens a quickfix buffer, lists errors and warnings, and jumps to the first error or warning in the list. How do I make it not jump for warnings? or better yet, for certain warnings?
If this is not possible, is there some shortcut for returning the cursor back to its position before the jump?
NOTE: Ignoring warnings via let g:TexIgnoredWarnings = ... is not adequate since I do want to see the warnings.
If you're compiling via Vim-Latex's \ll command as I do, then adding the following option in either your vimrc or the ftplugin tex.vim should solve your problem:
let g:Tex_GotoError=0
This will leave your cursor where it was, but still populate the QuickFix window with warnings and errors. The documentation (linked below) says that it defaults to on, so switching it off should accomplish what you want.
http://vim-latex.sourceforge.net/documentation/latex-suite.html#Tex_GotoError
I assume you are compiling LaTeX with the :make command. The help for that command gives a list detailing exactly what the command does, including:
If [!] is not given the first error is jumped to.
If you trigger your compilation with :make! or the abbreviation :mak! instead of :make, then the cursor will not jump.
vim also saves a list of places your cursor has been recently. You can jump back to your previous location with Ctrl-O, and then jump forward again with Ctrl-I Use :help jump-motions to see more about this feature.
I'm trying to achieve something simple, usually called "function hints". For example, scintilla-based editors have it:
You type a name, and just get the prototype. There are a few problems with that in vim:
You have to rebuild the ctags to keep it up to date
You can't type C-X C-O after the (, you'll just get "Pattern not found"
You can't type C-X C-O in normal mode, the cursor will just jump around
You get the annoying preview window at the top
I've tried a few plugins; most of them mess things up even more [^1].Can anyone recommend a simple way to get just that ? A simple rectangle containing the function prototype and nothing more.
[^1] It's really mind-numbing how idiotic some of these plugins are. One plugin (I won't mention it) actually contained in the .vim file a list of functions from libc.
ctags for autocompletion is a mess. I suggest you try a compiler based plugin such as clang-complete or gcc-sense (haven't tried this one). Advantages are:
more accuracy as what they do is pretty much compiling
compile errors are marked on the fly over the source code
You have to rebuild the ctags to keep it up to date
you don't need to deal with ctags (they are still useful to jump around though)
You can't type C-X C-O after the (, you'll just get "Pattern not found"
what would you expect?
You can't type C-X C-O in normal mode, the cursor will just jump around
you can always remap that sequence if you think it's a frequent mistake (something like nnoremap <C-x><C-o> a<C-x><C-o>)
You get the annoying preview window at the top
You can disable this by removing preview fromcompleteopt option. see :help completeopt
I'm using the following setup:
clang-complete for completion
supertab to complete with tab key
ultisnips for function signature placeholders. (also works with snipmate)
and some vimrc settings:
set pumheight=10 " so the complete menu doesn't get too big
set completeopt=menu,longest " menu, menuone, longest and preview
let g:SuperTabDefaultCompletionType='context'
let g:clang_complete_auto=0 " I can start the autocompletion myself, thanks..
let g:clang_snippets=1 " use a snippet engine for placeholders
let g:clang_snippets_engine='ultisnips'
let g:clang_auto_select=2 " automatically select and insert the first match
Enjoy!
Try to use eclim (plugin for integration with Eclipse).
This solution is overheaded a lot but it works in all cases.
When I open the command-line window for editing a complex command-line in vim, I expect to be able to go back and forth in and out of insert / normal mode to edit as I would in any other buffer. (That's the point of the command-line window, right? So that I can do that?) But instead, when I hit ESC to go back to normal mode, I get this:
Error detected while processing function <SNR>15_CloseStackPop:
line 3:
E11: Invalid in command-line window; <CR> executes, CTRL-C quits: pclose
I'm game to try to figure this out, but I don't have a lot to go on. vim --noplugin doesn't seem to have this problem, so it's clearly one of the plugins I have loaded, but which one? I have quite a few. "line 3" of what file? What does "E11" mean?
It turns out that this was a bug in the 'autoclose' plugin. I removed the reference to pclose from the <SID>CloseStackPop function, and now Escape in command-line mode works fine.
In case anyone else has this problem: functions in plugins can be defined with <SID>, which (in the source code) just looks like <SID>Foo, but to Vim look like <SNR>4321_Foo. I was looking for 15_CloseStackPop, assuming that the <SNR> was something special, but when I just did a grep CloseStackPop -r ~/.vim/plugins the offending plugin came up right away.
Try Ctrl+C as a synonym for Escape. Also check .vimrc for the plugins. This isn't standard behavior for vi. If I were you I wouldn't use any plugins unless I was absolutely sure what they did. Perhaps start from scratch and reinstall the ones you feel completely sure of.