I recently added ripgrep to my list of vim plugins and, immediately after installation, I began receiving this error message whenever I loaded up vim:
Error detected while processing /Users/my_macbook/.vim/plugged/vim-ripgrep/plugin/vim-ripgrep.vim:
line 149: E1208: -complete used without -nargs
Press ENTER or type command to continue
Opening the offending file and reviewing lines 148-149 reveals:
148 command! -nargs=* -complete=file Rg :call s:Rg(<q-args>)
149 command! -complete=file RgRoot :call s:RgShowRoot()
I am well & truly out of my depth here, especially considering that this error was generated by simply installing the plugin; I've made 0 changes to the underlying file (vim-ripgrep.vim).
Has anyone encountered a similarly chronic error after installing ripgrep and, if so, how did you resolve it?
Congratulations, you have found a bug in a FOSS program. Next step is to either notify the maintainer via their issue tracker or, if you know how to fix it, submit a patch.
Case in point, the author assigns a completion method, -complete=file, but custom commands like :RgRoot don't accept arguments by default so the command makes no sense as-is: you can't complete arguments if you can't pass arguments.
It only needs a -nargs=*, like its upstairs neighbour, :Rg, to work properly and the error message is pretty clear about it:
line 149: E1208: -complete used without -nargs
See :help -complete, :help -nargs, and more generally, :help user-commands.
As the other answer stated, it is a bug in this plugin. There is a currently open pull request to fix this: https://github.com/jremmen/vim-ripgrep/pull/58 Unfortunately, the repository is currently unmaintained, so it is unlikely to be merged any time soon. This active forks page may help you identify a new maintainer.
Until there is a new maintainer for vim-ripgrep, I suggest checking out that branch in your ~/.vim/plugged/vim-ripgrep directory and reopening vim.
I met the functionally same error on VIM plugins while using vim ~/.vimrc.
My met error liking yours:
Error detected while processing /Users/my_macbook/.vim/plugged/vim-ripgrep
/plugin/vim-ripgrep.vim:
I fixed the upstairs with the below:
cd /Users/my_macbook/.vim/plugged/vim-ripgrep/plugin/
git pull --rebase
END!
If you are using vim-plug, try to change
Plug "jremmen/vim-ripgrep"
to
Plug "miyase256/vim-ripgrep", {'branch': 'fix/remove-complete-from-RgRoot'}
Here are detail steps:
comment Plug "jremmen/vim-ripgrep"
:PlugClean
add Plug "miyase256/vim-ripgrep", {'branch': 'fix/remove-complete-from-RgRoot'}
:PlugInstall
I've been working with raster data and the code has been working fine. Unexpectedly when reprojecting with:
reproject()
I get
"Error in wkt(projfrom) :could not find function "wkt".
I'm using... CRS arguments:
+proj=utm +zone=5 +datum=WGS84 +units=m +no_defs
I have also tried projectRaster() and get a similar error
Might be an issue with the rgdal package? Anyone else getting this? thank you!
This problem should go away if you update the sp package
I have problems finding the source of an error message reported by JIT-compiled pipeline with halide.
The log message is:
Internal Error at Halide-release_2019_08_27/halide/src/CodeGen_LLVM.cpp:2815 triggered by user code at :
Condition failed: append_string:
The LLVM_code at the following lines is:
llvm::Function *append_string = module->getFunction("halide_string_to_string");
internal_assert(append_string);
I'm using halide release build from 2019_08_27 on Ubuntu 18.04.
The pipeline runs without any errors until somebody wanted to use the Halide::print() for debugging.
I've checked a small test pipeline and print seem to work.
My problem now is to find our bug in a very complex pipeline. Could somebody explain the source of this bug and what I need to check in my code to solve this?
Thanks in advance.
That means the function "halide_string_to_string" was not found in the runtime, which would be very odd for CPU targets. Hrm, I wonder if you're trying to use print inside a Func scheduled on a GPU or DSP? I could easily imagine that being broken.
I am using spdlog, opengl, glad, and glfw in my project. No matter what error I am receiving, it is ALWAYS preceded by the 4 same errors. For example, let's say I have the following code:
std::cout << "sup";
then it will run perfectly. Okay now, let's say I have a typo and I do this:
std:cout<< "sup";
I get the following errors:
Here are the first 2 errors.. they redirect to FMT core.h file
and then the last two redirect to FMT format.h
Does anyone know why this could be happening? it is not made or break, whenever I have an error and I fix it these go away but it's just annoying and I would like to understand why.
It looks as though this PR will fix your issue?
https://github.com/fmtlib/fmt/pull/1279
Maybe just update fmt to the latest version?
I am using CPN Tools to model a distributed system. CPN Tools uses CPN ML an extension of SML. The project homepage is: cpntools.org
I started with a simple model and when I try to make a particular indexed color set timed, I get an "Internal error". There is another indexed colorset within my Petri-net model that is timed and works correctly. I am not sure how I can troubleshoot since I don't understand the error message. Could you help me interpret the error message or give me some hints on what I could be doing wrong?
The model is:
http://imgur.com/JUjPRHK
The declarations of the model are:
http://imgur.com/DvvpyvH
The error message is:
Internal error: Compile error when generating code. Caught error.../compiler/TopLevel/interact/evalloop.sml:296.17-296.20../compiler/TopLevel/interact/evalloop.sml:44.55../compiler/TopLevel/interact/evalloop.sml:66.19-66.27
structure CPN`TransitionID1413873858 = struct ... end (* see simulator debug info for full code *)
simglue.sml:884.12-884.43
"
Thank you~
I know this is an old question, but I run in the same problem and wasted too much time on this, so maybe it will help someone else in the future.
I didn't understand exactly the reason for this, but it seems the problem appears when you play with time values on an arch that ends to a transition (I was updating an integer value to the current time, using IntInf.toInt(time())). Now, if I move the code on the outgoing arch of that transition (that is: the one that ends in a place) there is no error.