I use ALE to manage my linting (with flake8) and code formatting (with black).
One annoying incompatibility between flake8 and black is that flake8 gives an error when a line has more than 80 characters, while black only corrects lines with more than 88 characters.
So I would like to change flake8's line length to 88 characters, or change black's line length to 80 characters.
Notice that I do not have flake8 installed independently from ALE, but I do have black installed independently from ALE.
You can add the below to your .vimrc file:
let g:ale_python_flake8_options = '--max-line-length=88'
You can just modify the flake8.vim in:
~/.vim/plugged/ale/ale_linters/python/
folder and change line:
call ale#Set('python_flake8_options', '')
into:
call ale#Set('python_flake8_options', '--config=$HOME/.config/flake8')
Then add all config options in this file.
Related
I want to add colors to the text in Log files. For e.g. I would want lines that contain text 'ERROR', to be red colored. So that when I view that file, these I should be able to easily find those lines with 'ERROR'. I tried looking for the answer to question but couldn't find anything helpful.
Thanks in advnace.
So that when I view that file, these I should be able to easily find those lines with 'ERROR'.
Coloring those lines would be one way but there's a much simpler and more idiomatic way:
$ grep ERROR /path/to/logfile | less
will show you every line containing ERROR from /path/to/logfile in less.
Someprogrammerdude suggested to use ability of viewers to colorize output. It is called 'syntax highlighting' in vim ecosystem but not only there.
The simplest thing you can do in vim is:
:sy match my_error /.*ERROR.*/
:hi my_error ctermfg=red guifg=red
You can add these lines to your .vimrc or may better is to create a special syntax file for your log files where you can define more rules...
I wrote a utility for coloring log files called TxtStyle. It can color log files based on regex patterns defined in a config file ~/.txts.conf:
[Style="example"]
!red: regex("error")
green: regex("\d{4}-\d\d-\d\d")
# .. snip ..
To try it out, run (requires Python):
sudo pip install TxtStyle
wget -q https://raw.githubusercontent.com/armandino/TxtStyle/master/example.log
txts -n example example.log
You could use ccze to color the files:
e.g.:
docker logs -f <container> | ccze -m ansi
Couldn't figure this out. Just need to enter 1 emoji into a string and couldn't figure it out. Unicode is not working. Tried diagraph but didn't work either. Is there some trick to this in Vim? thx!
You do not need to install a plugin for this. All you need to do is enter the unicode value of the emoji. You can do that in insert mode with <C-v>. From :h i_ctrl-v_digit:
*i_CTRL-V_digit*
With CTRL-V the decimal, octal or hexadecimal value of a character can be
entered directly. This way you can enter any character, except a line break
(<NL>, value 10). There are five ways to enter the character value:
first char mode max nr of chars max value ~
(none) decimal 3 255
o or O octal 3 377 (255)
x or X hexadecimal 2 ff (255)
u hexadecimal 4 ffff (65535)
U hexadecimal 8 7fffffff (2147483647)
For example, if you want to enter this smiley-face, which has a unicode value of U+1F60A, you could simply type:
<C-v>U1F60A<esc>
or if you don't want to hit <esc>,
<C-v>U0001F60A
Just so you know, there's a good chance that it will not render properly in vim, depending on your font. If you are using gvim, you can change :se guifont=*, or in regular vim, changing your consoles font to make it render (assuming you pick a font that can render this particular emoji)
Another approach is to use abbreviations.
I added a few in my .vimrc file and now I just type :pushpin: for 📌, :bulb: for 💡, :bomb: for 💣, etc...
" Emoji shortcuts
ab :white_check_mark: ✅
ab :warning: ⚠
ab :bulb: 💡
ab :pushpin: 📌
ab :bomb: 💣
ab :pill: 💊
ab :construction: 🚧
ab :pencil: 📝
ab :point_right: 👉
ab :book: 📖
ab :link: 🔗
ab :wrench: 🔧
ab :info: 🛈
ab :telephone: 📞
ab :email: 📧
ab :computer: 💻
There are a lot more of them on emojicopy.com or similar sites. I just picked a few I already used before.
While it is possible to <c-v>U1f60A<esc>, it's not practical if you're
responding to email / entering a comment in a web form. I'm not going to
memorize unicode emoji tables 😒😫🙄 for quick "Thanks 😜" comment.
Few other options for such use cases:
Type your usual smileys like :) and have a plugin replace it with the
unicode equivalent 😄. The plugin
emoji-ab does this for you.
Type codes like :boom:. Many markdown parsers will convert it to 💥 for
you. But if you're not using such a parser,
emoji-ab will also convert it for
you.
Use something like
gucharmap
(or one of the many online Unicode pickers) to copy and paste unicode
characters into vim.
Another way to access these emojies in many contexts including Vim is to use the character map dialog window:
On Mac, press Ctrl+Command+Space and select the character.
On Windows, press Windows+R and type the charmap.
You can use emoji-fzf pip package
First install fzf
sudo apt install fzf
then intall emoji-fzf
pip install emoji-fzf
now make sure you can run emoji-fzf
emoji-fzf --help
if you get "comand not found" error please see
pip installs packages successfully, but executables not found from command line
now add emoji-fzf to your .vimrc
" Use emoji-fzf and fzf to fuzzy-search for emoji, and insert the result
function! InsertEmoji(emoji)
let #a = system('cut -d " " -f 1 | emoji-fzf get', a:emoji)
normal! "agP
endfunction
command! -bang Emoj
\ call fzf#run({
\ 'source': 'emoji-fzf preview',
\ 'options': '--preview ''emoji-fzf get --name {1}''',
\ 'sink': function('InsertEmoji')
\ })
" Ctrl-e in normal and insert mode will open the emoji picker.
" Unfortunately doesn't bring you back to insert mode 😕
map <C-e> :Emoj<CR>
imap <C-e> <C-o><C-e>
restart your vim and press ctrl + e and search for your favourite emoji and press enter
Esteemed Meld and Emacs/ESS users,
What I did:
Create a script.r using Emacs/ESS.
Make some modifications to script.r by pulling some lines of code from another_script.r
Reopen another_script.r (or script.r) in Emacs/ESS to continue working.
All the lines in another_script.r which were not pushed to script.r end with ^M
Some times it's the other way around - only the line that was pushed/pulled ends with ^M's. So far i haven't isolated exactly which action determines where the ^M's are placed. Either way i still end up with ^M's all over the place and i'd like to avoid getting them after using Meld!
FWIW: the directory is being synced by Dropbox; in Meld, Preferences > Encoding tab, "utf8" is entered in the text box; all actions are performed under Linux (Ubunt 12.04) with Meld v1.5.3, Emacs v23.3.1
Current workaround is running in a terminal: dos2unix /path/to/script.r which strips the ^Ms. But this shouldn't be necessary and I'm hoping some one here can tell me how to avoid these.
Cheers.
In a terminal i ran cat script.r | hexdump -C | head and amongst the output returned found a 0d 0a, which is DOS formatting for a new line (carriage return 0d immediately followed by a line feed 0a). I ran the same command on another_script.r i was merging with but only observed 0a, no 0d 0a, indicating Unix formatting.
To check further if this was the source of the ^M line endings, script.r was converted to unix formatting via dos2unix script.r & verified that 0d 0a was converted to 0a using hexdump -C as above. I performed a merge using Meld in attempting to replicate the process which yielded ^M line endings in my script's. I re-oppened both files in Emacs/ESS and found no ^M line endings. Short of converting script.r back to dos formatting and repeating the above procedure to see if the ^M line endings re-appear, i believe i've solved my ^M issue, which simply is that, unbeknownst to me, one of my files was dos formatted. My take home message: in a Windows dominated environ, never assume that one's personal linux environment doesn't contain DOS bits. Or line endings.
[using MacVim 7.3 on OS X Lion]
I have a vimscript function which runs an external command. It's executing correctly, but the output displays (unwanted) control characters, such as [0m, [33m, [36m, and -1H. The relevant line in the vimscript function is:
exec ":!bundle exec rspec --color " . a:filename
Which produces:
:!bundle exec rspec --color spec/acceptance/user_logs_in.feature
[33m*[0m
Pending:
[33m User logs in [0m
[36m # the step 'the user "foo#test.host" exists' is not implemented[0m
[36m # [0m
Finished in 0.07121 seconds
[33m1 example, 0 failures, 1 pending[0m
Here's what the same command and output look like from the terminal, which is how I want it to display in vim:
$ bundle exec rspec --color spec/acceptance/user_logs_in.feature
*
Pending:
User logs in
# the step 'the user "foo#test.host" exists' is not implemented
#
Finished in 0.1161 seconds
1 example, 0 failures, 1 pending
Also, any time I execute and external command, vim displays -1H immediately after it. For example, if I type:
:ls<return>
I see:
:ls-1H
<rest of the output is as expected>
Any ideas on hiding those control characters and -1H.
(disclaimer: I'm very new to vim so please don't assume too much background knowledge on my part.)
Thanks.
Update 3/31/2012 # 17:32 PM
Sam Goldman's correct: MacVim doesn't know how to display colors, so it outputs the color codes.
I've switched to terminal vim (which supports colors, at least with iTerm), but using the version of vim that comes with MacVim, which is more up-to-date and is compiled with ruby support (among other things). The easiest way to do that is:
brew install macvim --override-system-vim
MacVim doesn't know how to display colors. Terminal vim will display the colors correctly, or you can add --no-color to your rspec command (or a .rspec file). I'm not sure about the -1H thing. Maybe some customization you have for your terminal?
the -w and -W options of vim have theoretically the following effect:
-w {scriptout} All the characters that you type are recorded in the file
"scriptout", until you exit Vim.
This is useful if you want to create
a script file to be used with "vim -s"
or ":source!". When the "scriptout"
file already exists, new characters
are appended. See also
|complex-repeat|. {scriptout} cannot
start with a digit. {not in Vi}
-W {scriptout} Like -w, but do not append, overwrite an existing file.
{not in Vi}
But when I do this, the {scriptout} file will always begin with a hexadecimal sequence like 80 fd 60 (sometimes it is 80 fd 62).
I am using gvimportable.exe 7.3 from portableapps.com. With the -u NONE switch, it does the same.
What is this “magic number” for? Under Windows with gvim.exe I cannot replay my scriptout until I have removed those three leading bytes…
It seems that this feature, which could be very useful, is poorly documented.
Thank you for your answers.
(This answer is probably fragmented significantly, it took me a while playing around - I wanted to find a solution too because it intrigued me - not just the bounty of 200 :P. It more or less shows my train of thought and experimentation.)
I can now reproduce it with gvim on Linux, which is /usr/bin/vim.gnome -g; running as vim -g does just the same.
Delving into the code: (futile in this case, but fun to do and to learn how to do)
I've looked through the source code and I can now explain it somewhat (but not usefully!); it gets the outfile FILE (src/globals.h:1004) set (src/main.h:2275); this is then written to in src/getchar.h:1501, in the updatescript method which is used by gotchars (line 1215) which is used by vgetorpeek, which is used by vgetc and vpeekc... (no, I don't know where this is going!) then these are used in a number of places.
Anyway, I suppose the key is somewhere in src/gui.c, but I don't know where at the moment! It's also possible that some key sequence is being "sent" (physically or virtually, I don't know), but seeing as the issue is the same across platforms it would seem more likely to be a Vim issue than otherwise.
Interesting situations leading to a probable explanation:
It's also worth while noting that if you automatically quit, gvim -u NONE -w scriptout -c quit (:quit after loading) or gvim -u NONE -w scriptout -c quit (instant :quit, never shows GUI), the file scriptout is left empty.
Additionally, if you open gvim and then close it using the X button, pressing no keys:
0000000: 80fd 6280 fd63 80fd 62 ..b..c..b
If you open gvim, click away, click back and use :q:
0000000: 80fd 6280 fd63 80fd 6280 fd2c 80fd 2e3a ..b..c..b..,...:
0000010: 710d q.
So I think it's the window events are internally translated into something else. 80 fd 62 is the open sequence and 80 fd 63 80 fd 62 is the close sequence.
I've found another way of triggering 80fd as well, which leads me to thing it's some sort of "user has access to the window"; by default with GNOME in Ubuntu, Ctrl+Alt+S does something with the window (can't remember what it's called; slides it all up into the title bar, app inside loses keyboard control etc.). gvim ... (you know the arguments!), i<Ctrl+Alt+S (contracted) Ctrl+Alt+S (expanded) >Esc Z Q produces this for me:
0000000: 80fd 6269 3c80 fd63 80fd 623e 1b5a 51 ..bi<..c..b>.ZQ
Summary: so there we have what I believe is the solution; gVim catches the window messages in some form and - whether it should or shouldn't - puts them in its scriptout. If you think it shouldn't (or would like to know why they're left in or if they're even meant to be or whether you should care at all), ask on the Vim list, I think.
My best guess is that this is a bug in the GUI code of gVim.
Using gVim 7.3, if I run gvim -u NONE -W scriptout then I see the problem, but if I run vim -u NONE -W scriptout then the unwanted bytes are not present.
I also tested Vim 7.2 from the shell in Linux, the version of Vim included in Snow Leopard (7.2), and the GUI and terminal versions of MacVim 7.2 (with mvim -W and /Applications/MacVim/Contents/MacOS/Vim -W, respectively) and they all worked correctly.
Someone has done the hard work for us in the vimgolf project, in particular this well-commented file: https://github.com/igrigorik/vimgolf/blob/master/lib/vimgolf/lib/vimgolf/keylog.rb
0x80 in escape sequence for special two-byte codes. In this case they represent gvim focus events. See here:
# If you use gvim, you'll get an entry in your keylog every time the
# window gains or loses focus. These "keystrokes" should not show and
# should not be counted.
"\xfd\x60" => nil, # 7.2 Focus Gained compat
"\xfd\x61" => nil, # Focus Gained (GVIM) (>7.4.1433)
"\xfd\x62" => nil, # Focus Gained (GVIM)
"\xfd\x63" => nil, # Focus Lost (GVIM)