I have a custom .gitmessage. It is defined in the git config. I've added a ~/.vim/after/ftplugin/gitcommit.vim to redefine a couple of things in the plugin (in support of Conventional Commits), e.g., textwidth.
My .gitmessage looks something like this:
#subject-|---------|---------|---------|---------|---------|---------|---------|---------|-------->|
# Commit messages should follow the Conventional Commits Specification
# <type>(<optional scope>): <imperative subject>
# empty separator line
# <optional body>
# empty separator line
# <optional footer>
#
# API relevant changes || perf commits improve performance
# feat commits add a new feature || revert commit, well, revert a previous
# fix commits fix a bug || commit
...
...
where I provide an ASCII "ruler" for 100 chars (though the VIM filetype plugin config autowraps to the textwidth per my customization, &tc.
However, I would like to colorize the conventional commit sample and the type keywords, e.g., feat, fix, perf, &tc.
I've tried most of standard ASCII escape codes in the .gitmessage, e.g., \\e[1;30m, ^[1;30m (Ctrl-V, esc), and \033[1;30m. Alas, they all just get dumped to the vim editor—it makes sense that vim would make sure that these codes are editable—but gitcommit.vim does colorize the diff in git commit --all --verbose...
This appears to be, maybe, a function of shellescape (see :h shellescape in vim). I see this used in some of the filetype plugins, but I'm not a plugin hacker.
Any pointers?
Vim doesn't care about your escape codes.
A quick and dirty method would be to use :help :match or :help matchadd() in your custom ftplugin:
But the real solution is to create your own syntax script, following the instructions under :help usr_44. See $VIMRUNTIME/syntax/gitcommit.vim for a start.
Related
What mistake am I making in the steps I'm following?
I've edited files in repo Alpha on my local box. I then realized I wanted those changes in a different repo Bravo that is also on my local box. I tried this:
c:/repos/alpha/>git diff --cached > mypatch.txt
I then copy the patch file to the other repo location and type this:
c:/repos/bravo/>git apply mypatch.txt
If the shell I used for the diff and apply was powershell or "Git CMD", then the second command makes the error:
fatal: unrecognized input
If instead I use the "Git Bash" shell to execute the two commands, then I get a different error:
5109e.patch:19: trailing whitespace.
IL.DataUsageGB,
warning: 1 line adds whitespace errors.
I then try to apply the changes more carefully with the following command:
$ git apply --reject --whitespace=fix mypatch.txt
From this I get a dump of numerous errors. Example:
error: while searching for:
);
GO
-- Anchor table ------------------------------------------------------------
-------------------------------------------
-- IL_InvoiceLine table (with 33 attributes)
----------------------------------------------------------------------------
-------------------------------------------
IF Object_ID('dbo.IL_InvoiceLine', 'U') IS NULL
CREATE TABLE [dbo].[IL_InvoiceLine] (
error: patch failed: scripts/bi/sql/Unified_ODS_Schema.sql:302
The branch in repo Alpha and the corresponding branch in repo Bravo both come from the same origin and both have a git status that report "up to date" with the upstream. In other words, the branches are identical except for the staged changes that exist on Alpha. I am expressly avoiding a push/pull with the origin.
Suggestions?
TL;DR
There's nothing wrong, and you can completely ignore the warning. You don't need --reject or --whitespace=fix, but if you do want to use the latter, use it without the former.
Longer
If the shell I used for the diff and apply was powershell ...
This winds up writing the output as Unicode (through some mechanism I cannot describe properly since I don't "do" Windows). You'd have to filter that back to UTF-8 or ASCII to get it to apply.
If instead I use the "Git Bash" shell to execute the two commands, then I get a different error:
5109e.patch:19: trailing whitespace.
IL.DataUsageGB,
warning: 1 line adds whitespace errors.
That's not really an error, that's a warning. It means that your original patch adds a blank before an end-of-line. By default, git apply calls this an "error" but it really means "warning". It's meant to alert you to the fact that there's an invisible character on the line(s) in question, which you may not have intended. (Or maybe you did! For instance, in some Markdown formats, ending a line with two blanks inserts a paragraph break. See aslo Git ignore trailing whitespace in markdown files only.)
What constitutes a "whitespace error" (which really should be "whitespace annoyance" or "whitespace warning" or "whitespace glitch" everywhere, rather than "error") is configurable. By default git diff will highlight such whitespace glitches. While I cannot quite show it here, imagine the - line is in red and the + line is in green and that <space> represents a trailing blank:
- blah blah
+ blah foo blah<space>
This space would be highlighted in red, to make it stand out as a "whitespace error" (which I would call a whitespace glitch or annoyance or warning, but as long as we are using Git we should understand what the phrase "whitespace error" means here).
With --whitespace=fix, git apply will find the things it considers to be whitespace errors and determine whether it can fix them automatically by:
stripping trailing whitespace
removing some space-before-tab spaces
fussing with CRLF vs LF-only
If it can fix them, it will. This includes applying the patch even if the context does not quite match up but can be made to do so by this kind of fussing, so it's more than just "removing trailing whitespace in the added lines".
I use bash to configure many of my build tools.
I want to use variables to set certain things so that the build tools can be used in many environments.
Currently I do
exports var=val
and then I do
$var
when I need to use it.
Is this the best way to go about it, as I know there are many ways to do things in bash.
**Example**
#!/bin/bash
path_bash="$HOME/root/config/bash/"
source "${path_bash}_private.sh"
source "${path_bash}config.sh"
source "${path_bash}utility.sh"
source "${path_bash}workflow.sh"
source "${path_bash}net.sh"
source "${path_bash}makeHTM.sh"
#
#
#
# Divider - Commands
#
#
#
cd ~/root
Skip the export unless you really need it (that is, unless you need that variable to propagate to unrelated (=execed) processes that you execute).
If you do export, it's usually a good idea to capitalize the variable (export VAR=val) to make it apparent that it will spread to executed binaries.
When you refer to a shell variable, you usually want to double quote it ("$var") unless you need glob expansion and whitespace-splitting (splitting on $IFS characters, to be exact) done on that variable expansion.
sparrow automation framework gives you an opportunity to configure bash scripts in many ways :
passing command line named parameters
configuration files in yaml format
configuration files in json format
configuration files in config::general format
Of course you need to pack your bash scripts into sparrow plugins first to get this behavior , but this is not a big deal . Follow https://github.com/melezhik/sparrow#configuring-tasks for details .
PS. disclosure - I am the sparrow tool author .
I created an empty directory on zsh and added a file
called hello.rb by doing the following:
echo 'Hello, world.' >hello.rb
If I want to make changes in this file using the terminal
what's the proper way of doing it without opening the file
itself using let's say TextEditor?
I want to be able to make changes in the file hello.rb strictly
by using my zsh terminal, is this at all possible?
Zsh is not a terminal but a shell. The terminal is the window in which the shell executes. The shell is the text program prompting you commands and executing them.
If you want to edit the file within the terminal, then using vim, nano, emacs -nw or any other text-mode text editor will do it. They are not Zsh commands, but external commands that you can call from Zsh or from any other shell.
If you want to edit the file within Zsh, then use zed. You will need to run once (in ~/.zshrc)
autoload zed
and then you can edit hello.rb using:
zed hello.rb
(exit and save with Control-j)
You have already created and edited the file.
To edit it again, you can use the >> to append.
For example
echo "\nAnd you too!\n" >> hello.rb
This would edit the file by concatenating the additional string.
Edit, of course, by your use and definition of 'changing' a file, this is the simplest way to do so using the shell.
In a normal way, though you probably want to use a terminal editor.
Zed is a great answer, but to be even more stripped down - for a level of editing that even a script can do - zsh can hand all 256 characters/byte-values (including null) in variables. This means you can edit line by line or chunk by chunk almost any kind of file data directly from the command-line. This is approximately what zed/vared does. If you have a current version with all the standard modules included, it is a great benefit to have zsh/mapfile or zsh/system loaded so that you can capture any of the characters that are left out by command-expansion (zed uses $(<$file) to read a file to memory). Here is an example of a way you could use this variable manipulation method:
% typeset -T Buffer buffer $'\n'
% typeset -T Edit edit $'\n'
It is most common to use newline to divide a text file one wishes to edit.
This handy feature will make zsh give you full access to one line or a range of lines at a time without unintentionally messing with the data.
% zmodload zsh/mapfile
% Buffer=$mapfile[path/to/file]
Here, I use the handy mapfile module because I can load the contents of a file byte-for-byte. Alternately you can use % Buffer="$(<path/to/file)", like zed does, but you will always have the trailing newlines removed and other word splitting is possible with a typo or environment variation, so the simplicity of the module's method is best. When finished, you save the changes by simply assigning the $Buffer value back to the $mapfile[file] or use a more classic command like printf '%s' $Buffer >path/to/file (this is exact string writing, byte-for-byte, so any newlines or formatting you added back will be written).
You transfer the lines between Buffer and Edit using the mapped arrays as follows, however, remember that in its simplest form assigning one array to another drops elements that are completely empty (one \n \n two \n three becomes one \n two \n three). You can suppress this empty-element removal by quoting the input array and adding an '#' symbol to its index "$buffer[#]", if using the whole array; and adding the '#' symbol to the flags if using a range of the array "${(#)buffer[2,50]}". Preserving empty lines can be a bit troublesome for typing, but these multiple arrays should only be used in a script or function, since you can just edit one line at a time from the command line with buffer[54]="echo This is a newly written line."
% edit=($buffer[50,70])
...
% buffer[50,70]=($edit)
This is standard Zsh syntax, that means in the ... area you can edit and manipulate the $edit array of lines or the $Edit scalar block of text all you want, including adding more lines or taking some away. When you add the lines back into $buffer it will replace the specified block of lines (50-70) with the new lines, automatically expanding or reducing the other array elements to accommodate the reintegrated lines. -- Because of the dynamic array accommodations, you can also just insert whatever you need as a new line like this buffer[40]=("new string as new line" "$buffer[40]"). This inserts it before the index given, while swapping the order of the elements ("$buffer[40]" "new string as new line") inserts the new line after the index given. Either will adjust all following elements, including totally empty elements, to their current index plus one.
If you wanted to re-write the zed function to use this method in some complex way like: newzed /path/to/file [start-line] [end-line], that would be great and handy too.
Before I leave, I wanted to mention that using vared directly, once you have these commands typed on the interactive terminal, you may find it frustrating that you can't use "Enter" for inserting or appending new lines. I found that with my terminal and Zsh version using ESC-ENTER worked well, but I don't know about older versions (Mac usually comes stocked with a not-most-recent version, if my memory is right). If that doesn't work, you may have to do some documentation digging to learn how to set up your ZLE (Zsh Line Editor, a component of Zsh) or acquire a newer version of Zsh. Also, some other shells, when indexing a scalar variable may count by the byte because in ascii and C a byte is the same as a character, but Zsh supports UTF8 and will index a scalar string by the UTF8 character unless you turn off the shell option multibyte (on by default). This will help with manipulating each line if you need to use the old byte-character indexing. Also, if you have a version of Zsh that for whatever was not compiled with zsh/mapfile or zsh/system, then you can achieve a similar effect using number of options to the read builtin, like <path/to/file |read -u 0 -k $[5 * 2**20] -r -s Buffer ||(($#Buffer)). As you can see here, you have to make the read length big enough to accommodate the file's size or it will leave off part of the file, and the read return code will nearly always be an error because of not being able to read the full length of the string. We fix this with ||(($#Buffer)), but this builtin was simply not meant to handle large scale byte manipulation efficiently, so what you see is what you can get from it.
I would like Rubocop to ignore lines with comments (just a comment or some code with an end of line comment) when checking if a line is too long. Is there a way to do this?
There is a way to ignore cops on a per line basis.
There is also a way to do it via configuration file.
Run rubocop --auto-gen-config and it will generate a file that you can use to disable the offenses.
The command also gives a hint on what to do to load those options.
On a line per line basis, you can enable and disable the cops as well.
# rubocop:disable RuleByName
This is a long line
# rubocop:enable RuleByName
You can also do more than one rule at a time in your code.
# rubocop:disable BlockComments, AsciiComments
By using an inline directive, the directive becomes valid only for that
line, and it would look like this:
# Thanks to #jnt30 for the comment!
method(argument) # rubocop:disable SomeRule, SomeOtherRule
You can read a ton more about RuboCop in its official manual.
To find all the rule names its worth looking in the rubocop config files
cyberwiz says - "run rubocop -D when I need the rule names rather than looking in the documentation." Update: This is now the default behavior without the flag.
The -D is now default, so we would get that for "free" now.
It's possible to define regex patterns to automatically ignore certain lines in rubocop.yml, so you could choose to ignore all lines starting with a # character:
Layout/LineLength:
Max: 80
AllowedPatterns: ['\A#']
This could be improved so that "indented" comment lines (i.e. whitespace followed by a # character) are also ignored, if that's what you want.
Note that this doesn't account for lines of code that end with a comment, though:
some_code(that_does_something) # This line would NOT be ignored by Rubocop.
You can use the following comment with rubocop to ignore a specific rule:
# rubocop:disable Layout/LineLength
def this_could_be_a_very_long_line_that_extends_forever_into_infinity
end
# rubocop:enable Layout/LineLength
You can also ignore whole files by adding them to .rubocop.yml:
AllCops:
Exclude:
- path/to/file.rb
i think the basic idea here is that you want to enforce line length, no matter what is after n characters. the default to 80 characters is some cargo cult for old terminal windows that could only hold that number of chars. the only option that i saw in the code is an option to allow urls that might exceed the character limit.
you can ignore whole files, i guess that's not what you are looking for.
The following configuration worked for me:
Layout/LineLength:
AllowedPatterns: ['^(\s*#)']
This regex only works when the entire line is commented out. Code followed by a long comment on the same line will still trigger a Rubocop lint error, which is by design.
Since I installed OS X Mavericks, the result of the command git diff is rendering ESC[xxx characters like this:
ESC[1mdiff --git a/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xml b/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xmlESC[m
ESC[1mindex 3b65cf1..0ca5d7e 100644ESC[m
ESC[1m--- a/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xmlESC[m
ESC[1m+++ b/console/org.linkedin.glu.console-webapp/decorate-grails-methods-plugin/plugin.xmlESC[m
ESC[36m## -15,14 +15,14 ##ESC[m ESC[mThe purpose of this plugin is to decorate various grails methods.ESC[m
This used to render properly prior to installing Mavericks. I have no clue what is different so any help in troubleshooting would be much appreciated.
Note that the pager used is less since when I hit h I get the following:
SUMMARY OF LESS COMMANDS
Commands marked with * may be preceded by a number, N.
Notes in parentheses indicate the behavior if N is given.
Do you have a LESS environment variable set? You can check using:
env | grep LESS
or:
echo $LESS
If so, you want to make sure the R option is in there. That allows the ANSI escape sequences to pass through unscathed, and they'll be rendered as colors in the terminal.
Just for reference, I use this:
export LESS=eFRX
This works:
git config --global core.pager "less -r"
Try "less -R" (big "R")
This worked for me:
git config core.pager 'less -R'
Example:
Without "-R" you just get raw ESC control codes:
With "-R" you get the actual color:
"less -R" vs. "less -r"
-R (big R) seems to be the safer version of -r (small r). So that's why I prefer the big R version.
Quote from man less:
-r or --raw-control-chars
Causes "raw" control characters to be displayed. The default is to display control characters using the caret notation; for example, a control-A (octal 001) is displayed as "^A". Warning: when the -r option is used, less cannot keep track of the actual appearance of the screen (since this depends on how the screen responds to each type of control character). Thus, various display problems may result, such as long lines being split in the wrong place.
-R or --RAW-CONTROL-CHARS
Like -r, but only ANSI "color" escape sequences are output in "raw" form. Unlike -r, the screen appearance is maintained correctly in most cases. ANSI "color" escape sequences are sequences of the form:
ESC [ ... m
where the "..." is zero or more color specification characters For the purpose of keeping track of screen appearance, ANSI color escape sequences are assumed to not move the cursor. You can make less think that characters other than "m" can end ANSI color escape sequences by setting the environment variable LESSANSIENDCHARS to the list of characters which can end a color escape sequence. And you can make less think that characters other than the standard ones may appear between the ESC and the m by setting the environment variable LESSANSIMIDCHARS to the list of characters which can appear.
The global pager configuration option within git, just sends the output stream to the more or less commands. You can get rid of the escape characters within this output by setting the global configuration option to either:
git config --global core.pager "more -R"
To continue using more as your pager or
git config --global core.pager "less -R"
To continue using less as your pager
Another alternative is to eliminate git's "colorizing" of output by doing something like
$ git config --global color.ui false
See git help config for details.
Reference: unix.stackexchange: How to colorize output of git?
You change use the option -R Repaint the screen to remove all the buffered input.
export LESS="$LESS -R"
I had faced similar issues. My Output for LESS was:
LESS=-iMPM--?f%f--:--.?lb lines %lt-%lb.?L of %L.?pB (%pB%).
LESSOPEN=||/usr/bin/lesspipe.sh %s
Tried executing below, but it did not resolve the issue-
git config --global color.ui auto true
The issue was resolved using -
export LESS=eFRX