I'm working with Ruby under Windows platform. Solving "Carriage return character missing" rubocop offenses, I created file .rubocop.yml in the root of my project:
Style/EndOfLine:
EnforcedStyle: lf
This solved my "Carriage return" problem. But new warning appears:
~/project/.rubocop.yml:Style/EndOfLine has the wrong namespace - should be Layout
What does it mean "wrong namespace - should be Layout"? At current moment I have no idea where to dig to fix it.
It’s Layout/EndOfLine, not Style/EndOfLine. The part before the / is the namespace.
To remove this warning need to use Layout/EndOfLine instead of Style/EndOfLine. EndOfLine is a rubucop cop that responsible for detecting offense related to indentation, because it placed in Layout department.
Layout/EndOfLine:
EnforcedStyle: lf
It is interesting why in this comment about fixing "Carriage return character missing" advised to use Style/EndOfLine. It's relative new article and comments. Looks like since April some changes in rubocop been added.
Looks like you need to indent that second line:
Style/EndOfLine:
EnforcedStyle: lf
Related
We use a linter (for Golang) that run through a Github Actions workflow every time we open or update a Pull Request on our repository.
It recently started to return the following error:
File is not `gofmt`-ed with `-s` (gofmt)
After what happened in this other PR to the file pkg/api/api/go.
(EDIT: link added to evaluate and eventually reproduce the error)
Evidences:
I would like to understand what was the source of this error, as well as how to resolve it?
Source of the error
It seems this error can be returned when the file is not properly formatted according to Go rules.
For example: If you accidentally used tab indentation rather than spaces.
EDIT: blackgreen's answer gives more accurate details about the source of the error
How to resolve it
You can use the following Go command:
gofmt -s -w <path_to_file>.go
... then commit the code.
Note that in my case: gofmt -w pkg/api/api.go was enough to resolve the problem (without the -s flag, which I found strange as the error specifically asked for the -s).
Source 1 + Source 2
The -s flag in gofmt has nothing to do with formatting. It's about simplifying the code:
Try to simplify code (after applying the rewrite rule, if any).
The warning you see comes from the linter golangci-lint. Since you claim to have fixed the error by running gofmt -w, the presence of the hint "with -s" may be due to this bug: https://github.com/golangci/golangci-lint/issues/513.
The linked issue was fixed in 2019 and released with v1.17.0. You might want to check if your pipeline is using an older version.
Assuming that your file pkg/api/api.go triggered the warning just because it was not formatted, gofmt -w solves the issue because -w overwrites the file:
If a file's formatting is different from gofmt's, overwrite it with gofmt's version.
I have many lines in my specs that result in this IntelliJ warning:
"Cannot resolve properly, was not processed"
The vast majority of the lines have this format:
expect(result[:err]).to include('(Check the file permissions.)')
If I move the literal string to a separate variable, the warning goes away:
msg = '(Check the file permissions.)'
expect(result[:err]).to include(msg)
Is there a way to make this error go away (other than moving all my string literals to variables)?
My guess is that the RubyMine parser thinks that include is the Ruby keyword to include a module and so it emits a warning telling it cannot find the corresponding module.
The only way I found to fix this warning is to use the inclusion alias proposed by the rspec include matcher :
expect(result[:err]).to inclusion('(Check the file permissions.)')
This fixes the warning and the expectation works the same, but sadly the english sentence is bad.
There is also 3 other aliases available, but they don't give better english syntax:
alias_matcher :a_collection_including, :include
alias_matcher :a_string_including, :include
alias_matcher :a_hash_including, :include
alias_matcher :including, :include
These alias definitions can be found here
Maybe by chance this answer could lead someone to a better solution.
If you're willing to switch from using the word include to something like contain, you could simply create a custom matcher:
RSpec::Matchers.define :contain do |expected|
match do |actual|
expect(actual).to include(expected)
end
end
You could either add that code directly in your rails_helper.rb file, or better yet in a separate file. For instance, create spec/support/custom_matchers.rb and place the code there. You'll need to make sure that file gets included when running rspec. To do that, you could uncomment the following line which appears in the default spec/rails_helper.rb file:
# Dir[Rails.root.join('spec', 'support', '**', '*.rb')].each { |f| require f }
With that in place, your spec file would read:
expect(result[:err]).to contain('(Check the file permissions.)')
It can be fixed by adding this to rails_helper.rb or support/rubymine_stubs.rb:
# Rubymine IDE underlines `include` matchers with warning "Cannot resolve properly, was not processed"
# To fix this issue let's make an alias `contain` and use it instead
RSpec::Matchers.alias_matcher :contain, :include
module RubymineStubs
# create stub for `contain` so Rubymine won't underline it
def contain(*_args) end
end
how to fix Line is too long error in a ruby file without ignoring it and not introducing new errors.
I have tried giving the extra character in the next line using IDE. It is introducing new errors like 'Ternary operators must not be nested. Prefer if or else constructs instead.'
Rubocop already suggested the way to fix this error. Let me repeat it here. Assuming you have a very long line that reads:
variable = long_condition ? true_clause : false_clause
change it to:
variable = if long_condition
true_clause
else
false_clause
end
Other way would be to instruct rubocop to [temporary] ignore this error by running from the very project directory:
rubocop --auto-gen-config
Or, as last but not the least chance, update your .rubocop.yml file to increase a line length within a respective rule.
Rubocop tells you what to do, just follow its advice.
Also, have a look at the ruby styleguide, which explains all the rubocop rules in detail.
I've been using vim over ssh to work for a week or two now and all has been going great. Today I decided to add in some syntax highlighting, autocomplete, and some other general plugins. Set up vundle and went to work.
My current .vimrc can be found at https://github.com/scottopell/dotfiles/blob/master/.vimrc
I have cloned my vimrc and vim files onto my local ubuntu desktop and vim runs exactly as expected, no slowness on any files that I can find. Same plugins and same vimrc and no slowness on ruby files.
update
I can reproduce this issue with the following .vimrc
syntax on
and an empty ~/.vim folder.
However, vim on this vps is very slow with ruby/haml files. Much moreso ruby files. When I open any ruby file, startup takes about 2 seconds (timed with --startuptime). With a comparable length haml file, its about .5 seconds. This slowness isn't just on startup either, moving around and editing the file are both painfully slow.
Haml/erb(they are basically the same)
268.818 000.005: before starting main loop
848.871 580.053: first screen update
Ruby
199.613 000.004: before starting main loop
2937.859 2738.246: first screen update
Without syntax highlighting on the same ruby file as above
149.047 000.004: before starting main loop
152.912 003.865: first screen update
I have tried using mosh(http://mosh.mit.edu) and it doesn't help. not really relevant anymore
As you can see in my .vimrc file, I have tried a few different solutions to this problem.
I have tried running with all plugins disabled (I moved them all from ~/vim/bundle/PLUGINNAME to ~/vim/bundle/disabled/PLUGINNAME, is this correct?), set ruby path, set foldlevel to manual, disabled my colorscheme, nothing helps. see edit3
I can post the full startupttime log for any file if that will help.
I have tested a few other languages(php, c, python, vimL) and none experience any slowdown.
EDIT: Just to clarify, I am running an ssh session with ssh user#server then once inside the server I am doing vim file.rb.
EDIT2: I just tried accessing the server directly and the slowness persists without ssh, I have updated to reflect that this isn't a problem with ssh.
EDIT3: I can reproduce the issue with a .vimrc file that contains the single line syntax on with an empty ~/.vim folder
EDIT4 I uninstalled my compiled version of vim and any versions that I may have installed through apt, manually removed all vim stuff from my system, and I can run vim with vim -u NONE /path/to/file.rb then do :syn on and the issue will be there. The file in question is a rails controller, but like I've said, I can recreate it to some degree with most any file, but rails controllers see to be the worst.
The solution to this problem turned out to be the regex engine that vim uses.
The speculation on #vim on freenode is that the ruby syntax files use something that is slower on the new regex engine.
Any version older than and including Vim 7.3.969 has the old regex engine.
Add in set re=1 to your vimrc to force the old regex engine on any version newer (and don't forget to reload the file you're currently editing with :e).
Thanks to Houl, Dolio and dmedvinsky from #vim for help figuring it out.
I haven't had a chance to try the absolute latest version, there was a commit last night that may help with this issue. I will update this if I get the chance to try the bleeding edge version again.
You should set this tw options in your vimrc:
set ttyfast
set lazyredraw
If this is not solving your problem try to start vim without your vimrc to be sure that none of your current settings are screwing it up.
vim -u NONE
Two things that will drastically help speed up Ruby syntax highlighting are disabling cursor line and relative number for Ruby (if you use those).
I have the following in my .vimrc:
" Ruby is an oddball in the family, use special spacing/rules
if v:version >= 703
" Note: Relative number is quite slow with Ruby, so is cursorline
autocmd FileType ruby setlocal ts=2 sts=2 sw=2 norelativenumber nocursorline
else
autocmd FileType ruby setlocal ts=2 sts=2 sw=2
endif
I'm using vim 7.4.52 and none of these solutions worked for me.
According to this github comment on the issue (https://github.com/vim/vim/issues/282#issuecomment-169837021), foldmethod=syntax is responsible for the slowness.
Adding this to my .vimrc finally fixed it!
augroup ft_rb
au!
" fix the SLOOOW syntax highlighting
au FileType ruby setlocal re=1 foldmethod=manual
augroup END
Try setting your ruby path explicitly in your vimrc:
let g:ruby_path="/usr/bin/ruby"
see UPDATE at the bottom.
this may be helpful as a workaround -
i am using vim version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan 2 2014 19:40:46)
Included patches: 1-52
it is the stock version from
Linux Mint 17.1 Rebecca.
the php.vim syntax file is not version'd that i can see, but it sez last edit'd 28 aug 13.
it isn't a ruby project, but when editing a large php class file (
$ php -w test.inc | wc
2 2410 19220
) i note significant delays near the top of the class, but not above or below the class, and, notably, not toward the bottom of the class. as i attempt to insert new text near the bottom of the class, delay is minimal and seems to be proportional to the line number inside the class. "minimal" means almost instantly, "significant" means 1 to 1.5 seconds per character.
the file is approx 1800 lines with approx 500 lines of legit php and 1300 lines of comments and doc. the class begins at approx line 30 and ends at approx line 1700. it is conceded it's a bit large, but well documented :-\
if i insert
class dummy { }
in front of the original "class originalName {",
there is no delay anywhere in the file. this unsightly kluge permits vim/gvim to regain its responsiveness and could be considered a workaround. note no linefeed between the two, just
class dummy { } class originalName {
it can even be comment'd out:
/*class dummy {}*/class originalName {
additional info:
during this test, the plugins directory was moved.
with "set syntax=off", the problem completely disappears. this is NOT a fix.
setting the regular expression engine with
set regexpengine=1 (or any other number)
does not appreciably change the results.
based on these results, i would suspect the regular expression engine as well. my point is that diddling a bit with the syntax in ruby files may lead to a workaround.
UPDATE:
i have found that the issue is "caused" by setting php_folding to 1 (enabled). the vimrc i THOUGHT i was using was not, but at least some of the mystery is solved due to that mistake. a simple vimrc like this will induce the problem (for me, as least):
:syntax enable
:let php_folding = 1
this means my issue is totally unrelated to the ruby issue, but there may be a similar thing going on with the ruby.vim file. maybe not.
apologies for the deflection.
I tried most of these solutions but what ended up working for me the best was removing any plugins associated with airline.
When editing ruby, some files but not all are garbled when editing in vim.
Inspecting the options with :set, I discovered that there is some magic done to produce one of the option values, and something went wrong with the magic and there is an error or warning message where the option value should be. That may be causing side effects.
The method throwing the error is Gem.all_load_paths, and it happens regardless of whether I use ruby 1.8.7, 1.9.2, whether I use rvm or system ruby. Using Ubuntu 11.10
I've tried setting the omnifunc option to nil, but that doesn't solve the problem; it seems to be a different option producing this value. The plugins I'm using can be seen below.
:set
--- Options ---
autoindent comments=:# history=50 keywordprg=ri scroll=29 suffixesadd=.rb ttyfast
backup filetype=ruby hlsearch mouse=a shiftwidth=2 syntax=ruby ttymouse=xterm2
backupdir=~/.tmp helplang=en incsearch ruler showcmd tabstop=2
backspace=indent,eol,start
balloonexpr=RubyBalloonexpr()
commentstring=# %s
fileencodings=ucs-bom,utf-8,default,latin1
formatoptions=croql
include=^\s*\<\(load\|w*require\)\>
includeexpr=substitute(substitute(v:fname,'::','/','g'),'$','.rb','')
indentexpr=GetRubyIndent()
indentkeys=0{,0},0),0],!^F,o,O,e,=end,=elsif,=when,=ensure,=rescue,==begin,==end
omnifunc=rubycomplete#Complete f
rom ~/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/rubygems/deprecate.rb:62:in `all_load_paths'^#^Ifrom -e:1^#1.8/rubygems/deprecate.rb:62:in `send'^#^I
printoptions=paper:letter /
after,/var/lib/vim/addons/after,~/.vim/afterm,~/.vim/bundle/vim-rails,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim73,/usr/share/vim/vimfiles
suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg,.inx,.out,.toc
I got the same thing today after updating from Snapshot 63 to Snapshot 64 of MacVim. It's an ugly hack, but I found the offending line (79) in MacVim.app/Contents/Resources/vim/runtime/ftplugin/ruby.vim and removed the reference to Gem.all_load_paths, which is deprecated with no replacement.
I've posted a diff of my gist that gets me going. It's not clear to me at this point if this is a bug to be reported against MacVim or Vim.
I built on #pbyme a little bit and actually found the new way to do it. With my current setup, it's even pulling in some local gems brought in by bundler.
The key is replacing all_load_paths with Specification.map(&:lib_dirs_glob)
MacVim.app/Contents/Resources/vim/runtime/ftplugin/ruby.vim
79c79
< let s:code = "print ($: + begin; require %q{rubygems}; Gem.all_load_paths.sort.uniq; rescue LoadError; []; end).join(%q{,})"
---
> let s:code = "print ($: + begin; require %q{rubygems}; Gem::Specification.map(&:lib_dirs_glob).sort.uniq; rescue LoadError; []; end).join(%q{,})"