When I edit any .coffee file in my mvim and try to save that file with any line longer than 80 symbols, I get such error.
file_name.coffee |18 error| Line exceeds maximum allowed length Length is 91, max is 80.
This is extremely annoying, especially taking into consideration that we have convention of max 100 symbols per line in our company and even code of other team members causes problems for me locally.
The only place where I can change this limit is in nodejs module in file .../node_modules/coffeelint/lib/coffeelint.js, which has such line:
max_line_length: {
value: 80,
-level: ERROR,
+level: IGNORE,
message: 'Line exceeds maximum allowed length'
},
But, of course, editing sources of nodejs libraries is not a good option.
In my mvim I use these dotfiles - https://github.com/skwp/dotfiles
In my project directory I have .coffeelint.json, but it does not work, however, it seems to contain needed and valid code for that (it works perfectly on TravisCI and on machines of other team members).
Questions:
Is there any place where I can turn off coffeelint call when saving file?
Is there any place where I can configure my coffelint max allowed line length?
Update:
Putting properly named (.coffeelint.json) config file into home directory helps, but is not proper solution in my case.
It seems it is more a coffeelint question than a Vim question.
From http://www.coffeelint.org/#options :
It seems you have to generate a configuration file, tweaking the following option.
max_line_length This rule imposes a maximum line length on your code.
Python's style guide does a good job explaining why you might want to
limit the length of your lines, though this is a matter of taste.
Lines can be no longer than eighty characters by default.
default level: error
It also seems you have to call coffeelint with your configuration file:
From : http://www.coffeelint.org/#usage
coffeelint -f coffeelint.json application.coffee
You probably have to find in your dotfile where the coffeelint invocation is done, and add the configuration file with the -f option there.
You don't have to pass the config file explicitly. Here are the user docs for CoffeeLint. You should either create a ~/coffeelint.json file or create a coffeelint.json in the root of your project.
In all project parts (5 different repos now) we currently have .coffeelint.json file, that is not the proper name for coffeelint, if you want it to pick config file automatically. Current .coffeelint.json is used on TravisCI when checking code and is invoked with -f option, as it turned out. So I my case I have two ways to fix weird behaviour (that is intended behaviour, actually):
Copy one of the configs from 5 related repos to ~/coffeelint.json, so that coffeelint will use it automatically when vim will check file on save (but this will not do if some repos will have different configs, however, this solution does not require any changes to repos).
Create copy of each config file in each repository (so I'll have both .coffeelint.json and coffeelint.json in each repo) and add the newly added one to .gitignore, so that team members will not see it in their editors. This option is also inappropriate and looks ugly, cause I have to add 5 changes and 5 commits.
It seems that guys from the team decided to name coffeelint config file not properly in order to hide it visually in code editors. Solution cost me nerves, so, probably, I'll reconfigure everything properly and will rename configs to default names.
It would be nice if coffeelint supported multiple config files with levels of priority, but this is not possible now.
Related
I have read so much about the config setting core.autocrlf and what you can set it to. Yet I am having a lot of problem understanding why it doesn't work the way I expected it to.
Machine I'm working on: Windows
Experience with git: Beginner
Terminal: git bash
core.autocrlf: true
So let's begin with the first bit of confusion. I used the command echo hello > file1.txt in my working directory, then I also created a text file by opening notepad and saving it in the same location as my "file1.txt" and giving it the name "file_windows.txt". When opening both files on notepad, I saw a difference, "file1.txt" had "Unix (LF)" marked at the bottom of the notepad tab, whereas "file_windows.txt" had "Windows (CRLF)". I imagine the distinction was made since the first file was made with a unix/linux command in comparison to the other file which was created through the use of notepad and windows.
Now the problem arises when I tried adding those files to the staging area. When using the command git add file1.txt, I was faced with the following message:
warning: LF will be replaced by CRLF in file1.txt.
The file will have its original line endings in your working directory
I was a bit shocked since I thought that having core.autocrlf set to true would mean that git would make changes to the file by making sure "crlf" was replaced with "lf" when adding to the staging area, not the other way round suggested by the warning, of course the point of having that setting on was so that if let's say for example, someone on a linux platform with core.autocrlf set to false, would be able use that git repository without having to worry about some file having "crlf" instead of "lf".
Then when using the command git add file_windows.txt there would be no warnings as expected, since I imagine it is doing what it is supposed to do and replace "crlf" with "lf" when adding it to the staging area. What I am trying to get at here is that if there was for some reason to be a file that I'm working with that is in "lf", I wouldn't want it then switching it to "crlf" when I am adding it to the staging area, since there really wouldn't be a need to do so and it would probably not be beneficial.
Another thing to mention is that (although shouldn't be taken too seriously since I am a beginner using git so I don't know if it is because I am doing something wrong) when I commit both files, then use the command git checkout <commit hash> and then go open the files by start file1.txt (which opens them up on a notepad), I don't end up seeing the change which the warning stated it would make, it still shows as "Unix (LF)" and not "crlf" so it leaves me even the more confused.
Coudl someone explain what is going on please?
The warning "LF will be replaced by CRLF in file1.txt" means that it will be replaced by CRLF when you check the file out next. The file is indeed stored with LF endings in the repository, since all files subject to text handling are stored that way.
However, when you use git checkout, Git doesn't check out files which are up to date in the index. That's why you don't see git checkout modifying the files in the working tree.
This message is ultimately harmless, but it just warns you that you've placed a file into the working tree that does not use the line endings that you've requested, explicitly or implicitly, which means you may end up with different behavior next time you clone or checkout the repository. If all your tools handle any line ending gracefully, or you've properly configured your .gitattributes file to specify appropriate line endings, then you shouldn't have anything to worry about.
I am using Sublime Text 3 with the Packet Manager, and installed SublimeLinter and then SublimeLinter-flake8.
I want to use tabs for indentation, but I can't find out how. I can't actually find any indentation that works, because if I put one space it says: flake8: E111 - indentation is not a multiple of four, but when I put four spaces it says: flake8: E101 - indentation contains mixed spaces and tabs.
I am on Windows and using Python 3. Does anyone know how to change the settings?
This is answered in the flake8 documentation:
Flake8 supports storing its configuration in the following places:
Your top-level user directory
In your project in one of setup.cfg, tox.ini, or .flake8.
Values set at the command line have highest priority, then those in the project configuration file, then those in your user directory, and finally there are the defaults. However, there are additional command line options which can alter this.
Since this is editor-agnostic, this should be the favoured approach. Also, you keep flexibility when working with configurations at project-level.
However, you can also specify your flake8 arguments in the SublimeLinter configuration, exactly as described in the documentation for SublimeLinter-flake8. Keep in mind that this is a very unflexible solution since it requires editing if you're using different configuration settings across your projects.
I share Sublime prefs between two machines (home, work) using Git.
My monitor at work has a higher DPI than my monitor at home, so in one of the two machines I'd like to override font_size.
I was hoping for:
The possibility to override using a command-line flag (to do something like subl --override-pref font_size=15), like kitty --override does.
Another level of prefs cascading below User.
, but I don't think any of this exists in Sublime. Language-specific config is not what I'm looking for, I want something global, but only in one of the two machines.
Ideas? Workarounds? Thanks.
The general mechanism at play for settings files is that when Sublime loads a sublime-settings file by name, it pulls all of the similarly named files across all of the known packages and combines them together (the same also happens for many other resource files) with content from later files overriding anything that appears in an earlier file.
The order that's imposed here is lexically by package, with Default always being first and User always being last. That's why the default settings are in the Default package and your custom settings are in the User package. Additionally syntax specific settings also apply (as do settings specific to projects).
Apart from this mechanism there's no direct way to override settings without some sort of manual intervention on your part. Potential solutions for this sort of problem include the following examples:
Don't sync the Preferences.sublime-settings file
If the file isn't synced across multiple machines, then this problem becomes moot because each machine can easily have it's own unique settings. The downside to that is that each machine then has it's own unique settings, which is a pain in the butt if you often move from machine to machine and things don't quite work the same way.
Use separate git branches
An alternative here if you're using git such as you are is to try and keep separate branches per host or per host type (like hi_dpi and reg_dpi or some such). Then on each machine check out the appropriate branch.
The obvious downsides here are having to try and cross-sync desired settings changes (for both User as well as any packages you might install) between branches, which is less than ideal unless you really love git.
Use extra Preferences.sublime-settings files
Here the idea is that you don't include the font_size setting in your User/Preferences.sublime-settings file at all. Instead, you use Browse Packages from the command palette to open the Packages folder, then create a new folder there with some arbitrary name. Inside of that folder include a Preferences.sublime-settings file that contains only the font_size setting.
Doing this on multiple machines, you can sync the settings in your User folder across machines without also syncing the preference that contains the font_size. As a note, if you create the file while Sublime is already running, you may need to quit and restart to get it to notice that the settings file exists; this only applies the one time, though.
Use a plugin
Looking at the link provided above, the ultimate trump card for any setting is a setting that's been applied directly to a view. Given that, you can use a plugin that selectively always applies a specific font size to any newly created or opened file:
import sublime
import sublime_plugin
import socket
class CustomFontListener(sublime_plugin.EventListener):
hostname = socket.gethostname()
def on_new(self, view):
if self.hostname in ("host1", "host1.example.com", "host2"):
view.settings().set("font_size", 20)
on_load = on_new
Now any time you open a file or create a new buffer, if the current hostname is in the list you've configured the view will immediately get an appropriate font_size applied; otherwise the one from the preferences would be used instead.
You could also extend this to be configurable via it's own settings file, apply a different font size depending on the host name, etc.
Settings in views are persisted in the sublime-session file and also in the workspace files associated with sublime-project files, so these settings will remain in place even across restarts.
Something to keep in mind is that the internal commands for changing the font size (via Preferences > Font or via the mouse wheel keyboard shortcuts) work by writing a new font_size to your user preferences.
If you're using separate preference files, then doing this will add font_size to your User settings and you will need to manually remove it and modify the other settings file.
If you're using the plugin, then these shortcuts won't seem to do anything because it applies a font_size that overrides the User preference, but in fact as outlined above your preferences file end up being changed and you may not notice right away.
So whichever way you go, if you tend to use those you may need to make manual adjustments to settings files in the aftermath. It's also possible to create smarter versions of those commands as well, if this is the sort of thing that happens often.
Initially I used a makefile to deploy my application in linux.
I had various sed commands to replace variables like the PHP upload file size, post size, log file location etc.
Now I am shifting to ansible. I know I can copy the files, but how can I make changes to the conf files? Like if i just want to change the upload_filesize = 50M parameter. I don't want to make copies of the whole conf file and then replace with my file.
Sometimes it’s only a one-line change. Is there any better way to edit the config files in ansible?
If it's an INI file, then your specific requirements can be probably met by ini_file module (http://docs.ansible.com/ini_file_module.html).
If your change is limited just few lines (or eve one), then you can probably look at lineinfile module (http://docs.ansible.com/lineinfile_module.html).
Should you however need to change large number of settings, then it may be more beneficial to use template (http://docs.ansible.com/template_module.html) or assemble (http://docs.ansible.com/assemble_module.html). The main disadvantage of this approach is that you may need to review your template or fragments when updating your dependency.
Depending on the operating system, you can add files here /etc/php/apache2/conf.d/10-someinifilewithsetting.ini
First off, I was about to write a long list of if/else statements in vim and realized that 1) there was a better way to do what I was trying to do and 2) SO would be ripe with help on the subject. So! I have a variety of files spread about like
foo/src/file01.C
foo/src/file02.cc
foo/src/file03.c
foo/include/file01.hh
foo/include/file02.h
foo/include/file03.h
If you notice that the C/H, cc/hh, c/h extension may or may not match then you are keen and I'd like you to please help. I've look at things like the following vim scripts from the Vim wiki for "Easily switch between source and header file" and although I only dumped a few hours into a.vim without success, it doesn't seem that the others would work via the docs on that page. So can anyone help out on how to make this work?
A good lead I had was a quick How to Easily Switch between Header and Source topic, but still couldn't make it work.
I guess what I really want is how to avoid the multiple if statements and use real matching to do what I want. I want to look into another directory and if look for a header file of the same name with any familiar extension if it was a source C/C++ file, or look for a source file of any regular extension if it was a header file. Thanks for your help!
UPDATE: I specifically want to open the file in a new tab. I live on vim tabs!
I recommend using the FSwitch plugin. https://github.com/derekwyatt/vim-fswitch
This does exactly what you need out of the box. It is better than a.vim in more than one way, being a rewrite of the idea behind a.vim.
The link you posted presents it as a solution, too.
I have just installed it to my vim configuration and it does its job well.
Enjoy.
Just to make sure I was using the most current version, I downloaded the latest a.vim script (2.18) and copied it into my ~/.vim/plugin directory.
You can define certain variables in your ~/.vimrc file to get a.vim to recognize alternate file extensions.
To get the files in your example to match their alternates I added the following to my ~/.vimrc:
let g:alternateExtensions_C = "H,hh"
let g:alternateExtensions_hh = "C"
These are global variables that allow you to override what's already defined. You'll have to define
both relationships (they don't work both ways).
You can see what the current mappings are by typing:
:echo g:alternateExtensionsDict
If you need to define other mappings, follow the same pattern. What comes after the underscore is the file extension you're editing. What's in the double quotes is a comma-separated list of alternate extensions.
let g:alternateExtensions_<ext> = "<list,of,alt,ext>"
If you have a different directory structure, you can define what paths to search by overriding the g:alternateSearchPath variable. ../src and ../include are already included by default.
:echo g:alternateSearchPath
To open the alternate file in a new tab:
:AT
By the way, the a.vim script is pretty well documented. You might want to open it up and take a look. I found a setting or two that I didn't know about and I've been using it for years ;o)
I hope that helps.
IMO your best option is to adopt existing scripts to use :tabf instead of :e or whatever the scripts use right now to open the counterpart file. You can also try to make the change configurable and submit it to the script author. (I'm pretty sure many would find the enhancement useful.)
That reminded me of a trick I used very long time ago. Instead of guessing where the corresponding source/header files are, I have used at the top of file special comment containing relative path to the counterpart file. Switching was as simple as finding the special comment, extracting file name and opening it. Problem was similar to yours in that file extensions were not predictable. My rational solution was to stop guessing and denote counterparts explicitly in the source code. (This days I would have probably tried to put the relationship table into an external file with a standard name and look it up in VIM using the upward search.)
Two helpful things
:he 'path'
:he tabfind
So you would do
:set path=../,/usr/include/,/home/buildagent/SDKROOT/mysdk/inc
:tabfind error_codes.h
to open error_codes.h from somewhere exotic without having to specify it. Note how vim globbing is very very flexible, so you might not need mucht
:argadd ./**/*.[h,H] | tab sall
will open all header files under the current directory, regardless of how many levels deep. Be careful running this command on a large tree or with symlinks outside the tree