Disable `warning.warn` messages in pylint - pylint

Pylint sometimes print following onto console
/usr/lib/python2.7/site-packages/pylint/reporters/text.py:79: UserWarning: parseable output format is deprecated. This is equivalent to --msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg}
% (self.name, self.line_format))
This causes my vim to jump to this file (makeprg=pylint in vimrc) rather than any error or warning in my file. I want to disable it but could not find a way to do so by modifying .pylintrc. Is there a way out of this?
UPDATE
On Fedora-20, with pylint 1.1.0, everything works file with pylint -E command only.

you somehow use a deprecated feature of pylint (the 'parseable' output format). This may be due to a deprecated / not up to date pylint plugin for vim.
You should update the command line from --output-format=parseable to something like --msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg} which should produce equivalent output.

Related

Trouble installing haskell: how to adjust PATH variable to add to a shell config file?

I installed Haskell on my MacOS system using ghcup installer. It worked because if I type ghci I am dropped into this interactive shell. However I got this message in the terminal after doing the install:
In order to run ghc and cabal, you need to adjust your PATH variable.
You may want to source '/Users/user1/.ghcup/env' in your shell
configuration to do so (e.g. ~/.bashrc).
Detected bash shell on your system...
If you want ghcup to automatically add the required PATH variable to "/Users/user1/.bashrc"
answer with YES, otherwise with NO and press ENTER.
YES
grep: /Users/user1/.bashrc: No such file or directory
My shell is bash 3.2 But as you can see, when I typed YES it says there is no such file. How do I find my shell configuration file, or resolve this? I'd like to complete the setup correctly here.
And I have to be honest about my level of knowledge here, I don't truly understand what this is asking exactly. Is the PATH variable 'env'?
On macOS, .bashrc does not exist by default. ghcup will create this file, so the command you ran will have worked correctly. However, one of ghcup's subcommands expected to find the file before it was created, and therefore reported that error message. You can safely ignore this.

Vim Vundle broken, can't open file

My vim setup apparently has broken out of nothing. It now spills errors for every single plugin I have configured. This started happening after I have changed some appearance settings, some syntastic features (both of which I don't think are the cause) and changed my shell to fish (this MAYBE is the cause).
Using the directive set shell=/usr/bin/fish or set shell=fish does not change anything, it still fails, for which I tried after reading this question.
The errors happen for both :BundleInstall and :BundleUpdate. My full vimrc file is available here if there is need to read it, it's not long.
Yes, setting your shell to fish is likely to be the root of your problem. The fish shell doesn't support the standard UNIX syntax for file redirections, which breaks Vim's system(). Just set Vim's shell to sh:
set shell=/bin/sh
You can't use the interactive features of fish from Vim anyway.
A while back I wrote up some docs for this on the Vundle wiki that you may find useful. In short, you can either:
Run: env SHELL=(which sh) vim +BundleInstall! +BundleClean +qall
Add set shell=sh to your .vimrc
As an aside, my Tackle project has an Up plugin that includes a handy way to update your vim plugins via Vundle.

Error when try installing budspencer theme for fish shell

My fish conf (.config/fish/config.fish)
set -e fish_key_bindings
set -U fish_key_bindings fish_vi_key_bindings
set fish_path $HOME/.oh-my-fish
set fish_theme budspencer
. $fish_path/oh-my-fish.fish
result in error: https://gist.github.com/LuizCarvalho/925de989c306828a410a
if I remove theme and sets result in:
desenvolvimento#dp-inf015:~$ fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
fish: Unknown command “fish_vi_key_bindings”
Standard input: begin; fish_vi_key_bindings ;end
^
in . (source) call of file “-”,
called on standard input,
in function “__fish_reload_key_bindings”,
called on line 209 of file “/usr/share/fish/functions/__fish_config_interactive.fish”,
in function “__fish_config_interactive”,
called on line 108 of file “/usr/share/fish/config.fish”,
in function “__fish_on_interactive”,
called on standard input,
in event handler: handler for generic event “fish_prompt”
If I uninstall fish, oh-my-fish and all file conf and install again, error keeps happening...
How I can solve this?
vi bindings are in an upcoming release, but not yet in a public one. That is why you get the error.
If you want to get vi bindings working and are willing to live on the edge, you can install the latest fish from trunk. If you are using homebrew, run brew install fish --HEAD. Or if you prefer to do it the old fashioned way, there's build instructions here.
Alternatively, if you understandably prefer to remain on the most recent public release, you should delete the fish_vi_key_bindings lines from config.fish.

Vim is taking 700MB memory on WIndows, how can I debug it?

I have Vim on Windows server 2012, and when I start it from the start menu everything works fine. However, when I start it from the command line it take 5 seconds and uses 700MB memory. Even when its not opening a file. There is something weird going on, and I was wondering if there are any ways to debug it/figure out what is causing this? Thanks, Eric.
EDIT:
Here is the result of vim --startuptime outputfile (abbreviated):
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.000 000.000: --- VIM STARTING ---
...
016.000 016.000: parsing arguments
016.000 000.000: expanding arguments
4794.000 4778.000: shell init
4794.000 000.000: Termcap init
...
4825.000 000.000: setting raw mode
8768.000 3943.000: start termcap
8768.000 000.000: clearing screen
8783.000 000.000: --- VIM STARTED ---
You could use Sysinternals' Process Explorer to check if any of the processes are starting child processes or if there is any difference in the environmental variables.
Also, Sysinternals' Procmon would allow you to check what registry entries, files, etc does any application use (filter by command name includes vim), but probably you will find the differences just with Process Explorer.
Sysinternals was a company that created some nice apps for Windows and Microsoft bought it some years ago. You can access the last version of any of their apps on http://live.sysinternals.com
Excerpt from Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual runtime
files or any plugin that is distributed with Vim or whether it is a
simple side effect of any configuration option from your .vimrc or
.gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your viminfo
file (-i NONE), without reading any configuration file (-u NONE for not
reading .vimrc file and -U NONE for not reading a .gvimrc file) or even
plugin.
In this invocation, try to reproduce your problem. If the error
persists, the chance is good you've found a bug in Vim (see also
Question 2.6. faq-2.6)
If the error does not occur when starting Vim this way, then the problem
is either related to some plugin of yours or some setting in one of your
local setup files. You need to find out, what triggers the error, you
try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load any
plugins. If the error occurs this time, the error is possibly caused by
some configuration option inside your .vimrc file. Depending on the
length of your vimrc file, it can be quite hard to trace the origin
within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half of
your .vimrc. If it doesn't happen, the problematic setting must be in
the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and move
your way along, until you find the problematic option.
It also mentions how to create a log file:
You can also use the -V command line argument to get more debug
information to analyze the problem:
$ vim -V2logfile
You can increase the value passed to the -V argument to get more debug
information. By also specifying a logfile name, this makes sure, the
debug messages don't appear on the screen and won't disturb you when
trying to reproduce the problem.

How do I validate my YAML file from command line?

I am having issues pulling from a YAML config file:
Fatal error: while parsing a block mapping; expected <block end>, but found block entry
While there are plenty of online YAML validators, which I have tried and have helped, I'd like to validate my YAML files from the command line and integrate this into my continuous integration pipeline.
With basic Ruby installation this should work:
ruby -ryaml -e "p YAML.load(STDIN.read)" < data.yaml
Python version (thx #Murphy):
pip install pyyaml
python -c 'import yaml, sys; print(yaml.safe_load(sys.stdin))' < data.yaml
You could use yamllint. It's available in Homebrew, etc. It can be used for syntax validation as well as for linting.
Given that you have a perl install on the server you are working on, and it has some of the basic YAML tools, you can use...
perl -MYAML -e 'use YAML;YAML::LoadFile("./file.yaml")'
It should be noted that this will be strict in it's interpretation of the file, but useful.
To correct your .yaml files I recommend the tool yamllint. It can be launched easily from the local console.
The package yamllint is available for all major operating systems.
It's installable from the system's package sources. (e.g. sudo apt-get install yamllint).
See documentation for quick start and installation.
My preferd way is
yamllint -d "{extends: default, rules: {quoted-strings: enable}}" .
Since I really want to catch quote errors,
e.g. validate: bash -c ' ' \""
This is valid yaml, since yaml will just quote the string and turn it into:
validate: "bash -c ' ' \\\"\""
Whilst there was just clearly a quote missing at the beginning of the validate comand.
So a normal yaml checker will not detect this, yamllint wil not even detect this in it's default configuration, so turn on quoted-strings checker.
If you got no interpreter installed in your environment but still got a curl, then you could use an online linter project like Lint-Trilogy:
curl -X POST --data "data=$(cat myfile.yml)" https://www.lint-trilogy.com/lint/yaml/json
It delivers the validation result incl. error descriptions (if any) as json or csv or, where sufficient, as plain text true or false.
It's available as docker file, too. So if you often need a REST based linter, perhaps in a CI/CD pipeline, it may be handy to host an own instance on your site.
Or alternately installed (free) Eclipse IDE and then YEdit yaml editor and see your yaml with syntax highlighting, error flags, and outline views. One time setup cost works pretty well for me.

Resources