I'm an iOS developer, when I press enter, xcode automatically indent the new line with 4 spaces, that's convenient for developing.
But when it comes to using git diff, every empty line will be marked with red color.
This can be annoying in team development.
So how to deal with it?
Thanks in advance!
Use this when using diff
git diff -w // (--ignore-all-space)
You can create an alias for this so you will not have to type it every time.
git config --global alias.NAME 'diff --ignore-space-change'
git diff
-b / --ignore-space-change
Ignore changes in amount of whitespace.
This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
-w / --ignore-all-space
Ignore whitespace when comparing lines.
This ignores differences even if one line has whitespace where the other line has none.
--ignore-blank-lines
Ignore changes whose lines are all blank.
With Git 2.25 (Q1 2020), three+ years later, the "diff" machinery learned not to lose added/removed blank lines in the context when --ignore-blank-lines and --function-context are used at the same time.
So your intermediate 4 empty lines won't show up.
But in the context of functions, they might.
See commit 0bb313a (05 Dec 2019) by René Scharfe (rscharfe).
(Merged by Junio C Hamano -- gitster -- in commit f0070a7, 16 Dec 2019)
xdiff: unignore changes in function context
Signed-off-by: René Scharfe
Changes involving only blank lines are hidden with --ignore-blank-lines, unless they appear in the context lines of other changes.
This is handled by xdl_get_hunk() for context added by --inter-hunk-context, -u and -U.
Function context for -W and --function-context added by xdl_emit_diff() doesn't pay attention to such ignored changes; it relies fully on xdl_get_hunk() and shows just the post-image of ignored changes appearing in function context.
That's inconsistent and confusing.
Improve the result of using --ignore-blank-lines and --function-context together by fully showing ignored changes if they happen to fall within function context.
Related
I'm learning COBOL programming and using GNUCobol (on Linux) to compile and test some simple programs. In one of those programs I have found an unexpected behavior that I don't understand: when reading a sequential file of records, I'm always getting one extra record and, when writing these records to a report, the last record is duplicated.
I have made a very simple program to reproduce this behavior. In this case, I have a text file with a single line of text: "0123456789". The program should count the characters in the file (or 1 chararacter long records) and I expect it to display "10" as a result, but instead I get "11".
Also, when displaying the records, as they are read, I get the following output:
0
1
2
3
4
5
6
7
8
9
11
(There are two blank spaces between 9 and 11).
This is the relevant part of this program:
FD SIMPLE.
01 SIMPLE-RECORD.
05 SMP-NUMBER PIC 9(1).
[...]
PROCEDURE DIVISION.
000-COUNT-RECORDS.
OPEN INPUT SIMPLE.
PERFORM UNTIL SIMPLE-EOF
READ SIMPLE
AT END
SET SIMPLE-EOF TO TRUE
NOT AT END
DISPLAY SMP-NUMBER
ADD 1 TO RECORD-COUNT
END-READ
END-PERFORM
DISPLAY RECORD-COUNT.
CLOSE SIMPLE.
STOP RUN.
I'm using the default options for the compiler, and I have tried using 'WITH TEST {BEFORE|AFTER}' but the result is the same. What can be the cause of this behavior or how can I get the expected result?
Edit: I tried using an "empty" file as data source, expecting a 0 record count, using two different methods to empty the file:
$ echo "" > SIMPLE
This way the record count is 1 (ls -l gives a size of 1 byte for the file).
$ rm SIMPLE
$ touch SIMPLE
This way the record count is 0 (ls -l gives a size of 0 bytes for the file). So I guess that somehow the compiled program is detecting an extra character, but I don't know how to avoid this.
I found out that the cause of this behavior is the automatic newline character that vim seems to append when saving the data file.
After disabling this in vim this way
:set binary
:set noeol
the program works as expected.
Edit: A more elegant way to prevent this problem, when working with data files created from a text editor, is using ORGANIZATION IS LINE SEQUENTIAL in the SELECT clause.
Since the problem was caused by the data format, should I delete this question?
uci documentation says:
All "uci set", "uci add", "uci rename" and "uci delete" commands are staged into a temporary location and written to flash at once with "uci commit".
If I get it right, you first run some commands like the ones mentioned above and to make the changes be written to the configuration files you run uci commit. For example, let's say I have done the following changes...
root#OpenWrt:~# uci changes
network.vlan15.ifname='eth1.15'
network.vlan15.type='bridge'
network.vlan15.proto='static'
network.vlan15.netmask='255.255.255.0'
network.vlan15.ipaddr='192.168.10.0'
...but I don't want to continue and commit them. Is there an easy way to revert all staged changes and avoid doing it one by one?
This should be possible by the following command:
root#firlefanz:~# rm -rf /tmp/.uci/
There is a command to revert all staged changes
revert <config>[.<section>[.<option>]] Revert the given option, section or configuration file.
So, in your case, it should be
uci revert network.vlan15
See https://openwrt.org/docs/guide-user/base-system/uci
This one-liner should do the trick:
uci changes | sed -rn 's%^[+-]?([^=+-]*)([+-]?=.*|)$%\1%' | xargs -n 1 uci revert
tl;dr The sed command extracts the option names from the staged changes. The xargs command executes the revert command for every extracted option.
Now let's have a deep dive into everything:
uci changes prints the prepared changes which are then piped to the sed command.
The sed opton -r enables extended regular expressions and -n suppress automatic printing of pattern matches.
The sed command s is used to do a search and replace and % is used as separation character for the search and replace term.
The uci change lines have different formats.
Removed configuration options are prefixed with -.
Added configuration options are prefixed with +
Changed options don't have a prefix.
To match the prefixes [+-]? is used. A question mark means, that one of the characters in the square brackets can be matched optional.
The option name will be matched with the pattern [^=+-]*. This regex has the meaning of any number of characters as long as the character is not one of =+-.
It is inside round brackets to mark it as group to reuse it later.
The next pattern ([+-]?=.*|) is also a pattern group. There are two different groups spitted by the pipe.
The second part is the easy one and means no character at all. This happens when a uci option is deleted.
The fist part means that the character = can optional prepended with + or -. After the = can be one or more characters which is indicated by .*. =<value> happens on added configuration. The prepending of - or + indicates the value is removed from the list or added to the list if the option is a list.
In the replace pattern the whole line is replaced with the first group by its reference \1. In other words: only the option name is printed.
All the option names are then send to xargs. With option -n 1 xargs execuse uci revert <option_name> for every option_name send by sed.
This are some examples for the different formats of the uci changes output:
-a
+b='create new option with this value'
c='change an existing option to this value'
d+='appended to list'
e-='removed from list'
The extraced option names will be the following:
a
b
c
d
e
xargs -n 1 will then executed the following commands:
uci revert a
uci revert b
uci revert c
uci revert d
uci revert e
This is the whole magic of the one-liner.
I didn't find a uci command to revert all uncommitted changes, but you can probably parse the output of the uci changes command with some shell scripting to achieve the desired result. Here is an example script:
#!/bin/ash
# uci-revert-all.sh
# Revert all uncommitted uci changes
# Iterate over changed settings
# Each line has the form of an equation, e.g. parameter=value
for setting in $(uci changes); do
# Extract parameter from equation
parameter=$(echo ${setting} | grep -o '^\(\w\|[._-]\)\+')
# Display a status message
echo "Reverting: ${parameter}"
# Revert the setting for the given parameter
uci revert "${parameter}"
done
A simpler alternative might be to use the uci revert <config> syntax, e.g.:
#!/bin/ash
# uci-revert-all.sh
# Revert all uncommitted uci changes
for config in /etc/config/*; do
uci revert $(basename ${config})
done
Both of these approaches worked well for me on a router running LEDE 4.
Here's another short one-liner to revert ALL unstaged changes (as per the question):
for i in /etc/config/* ; do uci revert ${i##*/} ; done
(FYI, this uses posix parameter expansion's "Remove Largest Prefix Pattern".)
I am trying to find a way to selectively remove newline characters from a file. I have no issues removing all of them..but I need some to remain.
Here is the example of the bad input file. Note that rows with Permit ID COO789 & COO012 have newlines embedded in the description field that I need to remove.
"Permit Id","Permit Name","Description","Start Date","End Date"
"COO123","Music Festival",,"02/12/2013","02/12/2013"
"COO456","Race Weekend",,"02/23/2013","02/23/2013"
"COO789","Basketball Final 8 Championships - Media vs. Politicians
Skills Competition",,"02/22/2013","02/22/2013"
"COO012","Dragonboat race
weekend",,"05/11/2013","05/11/2013"
Here is an example of how I need the file to look like:
"Permit Number/Id","Permit Name","Description","Start Date","End Date"
"COO123","Music Festival",,"02/12/2013","02/12/2013"
"COO456","Race Weekend",,"02/23/2013","02/23/2013"
"COO789","Basketball Final 8 Championships - Media vs. Politicians Skills Competition",,"02/22/2013","02/22/2013"
"COO012","Dragonboat race weekend",,"05/11/2013","05/11/2013"
NOTE: I did simplify the file by removing a few extra columns. The logic should be able to accommodation any number of columns though. The actual full header line is with all columns is. Technically, I expect the "extra" newlines to be found in Description and Location columns.
"Permit Number/Id","Permit Name","Description","Start Date","End Date","Custom Status","Owner Name","Total Expected Attendance","Location"
I have tried sed, cut, tr, nawk, etc. Open to any solution that can do this..that can be called from within a unix script.
Thanks!!!
If you must remove newline characters from only within the 'Description' and 'Location' fields, you will need a proper csv parser (think Text::CSV). You could also do this fairly easily using GNU awk, but you won't have access to gawk on Solaris unfortunately. Therefore, the next best solution would be to join lines that don't start with a double-quote to the previous line. You can do this using sed. I've written this with compatibility in mind:
sed -e :a -e '$!N; s/ *\n\([^"]\)/ \1/; ta' -e 'P;D' file
Results:
"Permit Id","Permit Name","Description","Start Date","End Date"
"COO123","Music Festival",,"02/12/2013","02/12/2013"
"COO456","Race Weekend",,"02/23/2013","02/23/2013"
"COO789","Basketball Final 8 Championships - Media vs. Politicians Skills Competition",,"02/22/2013","02/22/2013"
"COO012","Dragonboat race weekend",,"05/11/2013","05/11/2013"
sed ':a;N;$!ba;s/ \n/ /g'
Reads the whole file into the pattern space, then removes all newlines which occur directly after a space - assuming that all the errant newlines fit this pattern. If not, when else should newlines be removed?
I am using TeXnicCenter to edit a LaTeX document.
I now want to remove a certain tag (say, emph{blabla}} which occurs multiple times in my document , but not tag's content (so in this example, I want to remove all emphasization).
What is the easiest way to do so?
May also be using another program easily available on Windows 7.
Edit: In response to regex suggestions, it is important that it can deal with nested tags.
Edit 2: I really want to remove the tag from the text file, not just disable it.
Using a regular expression do something like s/\\emph\{([^\}]*)\}/\1/g. If you are not familiar with regular expressions this says:
s -- replace
/ -- begin match section
\\emph\{ -- match \emph{
( -- begin capture
[^\}]* -- match any characters except (meaning up until) a close brace because:
[] a group of characters
^ means not or "everything except"
\} -- the close brace
and * means 0 or more times
) -- end capture, because this is the first (in this case only) capture, it is number 1
\} -- match end brace
/ -- begin replace section
\1 -- replace with captured section number 1
/ -- end regular expression, begin extra flags
g -- global flag, meaning do this every time the match is found not just the first time
This is with Perl syntax, as that is what I am familiar with. The following perl "one-liners" will accomplish two tasks
perl -pe 's/\\emph\{([^\}]*)\}/\1/g' filename will "test" printing the file to the command line
perl -pi -e 's/\\emph\{([^\}]*)\}/\1/g' filename will change the file in place.
Similar commands may be available in your editor, but if not this will (should) work.
Crowley should have added this as an answer, but I will do that for him, if you replace all \emph{ with { you should be able to do this without disturbing the other content. It will still be in braces, but unless you have done some odd stuff it shouldn't matter.
The regex would be a simple s/\\emph\{/\{/g but the search and replace in your editor will do that one too.
Edit: Sorry, used the wrong brace in the regex, fixed now.
\renewcommand{\emph}[1]{#1}
any reasonably advanced editor should let you do a search/replace using regular expressions, replacing emph{bla} by bla etc.
I usually use Geany or Hi-Tide under Debian (GNU/Linux) for firmware development, mainly C (but also reading old assembler). I document code using single-line comments, and it really annoys me when I retype something and have to manually re-break every following line to keep it in the 80-character margin.
Is there a text editor that can re-wrap consecutive single-line comments (and do this automatically while I type)? That is, given:
/// This is a really long line that should have been wrapped at "that" but was not.
/// This sentence is in the same
/// paragraph as the last.
...I want an editor that will re-wrap this to
/// This is a really long line that
/// should have been wrapped at "that"
/// but was not. This sentence is in
/// the same paragraph as the last.
...preferably doing this sensibly while I type.
I've tried:
Hi-Tide (based on Eclipse 3.3)
Geany
jEdit
UniversalIndentGUI + a bunch of prettifiers (I couldn't find any formatters that worked, and it's not a great workflow either)
GVim - next line begins //should have been... instead of /// should have been...
Update: just to elaborate on my accepted answer - I've gone with the snapshot emacs and an extra filladapt mode was also required
In Emacs, to start automatic wrapping, enter auto-fill-mode. To set the line width, run C-u ⟨columns⟩ C-x f.
Emacs, or really CC Mode, will anticipate your commenting structure, so that typing
/// This is a really long line that shoul will result in
/// This is a really long line that
/// shoul‸
And you can refill a paragraph at any time with M-q.
If you want to do refills automatically with each keypress, well there may well be some interal command or third-party library out there, but off-hand you can use this elisp code:
;;; Can't advise SELF-INSERT-COMMAND, so create a wrapper procedure.
(defun self-insert-refill (n)
(interactive "p")
(self-insert-command n))
;;; Advise SELF-INSERT-REFILL to execute FILL-PARAGRAPH after every
;;; keypress, but *only* if we're inside a comment
(defadvice self-insert-refill (after refill-paragraph)
(let ((face (or (get-char-property (point) 'read-face-name)
(get-char-property (point) 'face))) )
(if (and (eq face 'font-lock-comment-face)
(not (string= " " (this-command-keys)))) ; Spaces would get deleted on refill.
(fill-paragraph))))
(ad-activate 'self-insert-refill)
(add-hook 'c-mode-hook
;; Remap SELF-INSERT-COMMAND to be SELF-INSERT-REFILL.
(local-set-key [remap self-insert-command] 'self-insert-refill) ))
This is probably not very robust or in keeping with best-practice, and likely not wholly satisfactory, as it won't work for general editing, e.g. C-d and backspace, and it slows down the editor somewhat, but it's a start.
Vim most certainly can do this.
First, you need to tell Vim that "///" is a comment prefix (it isn't by default):
:set comments^=:///
If you want wrapping to occur as-you-type, set your preferred textwidth:
:set textwidth=80
To format existing paragraphs, use any variation of the gq command. For example, you could:
Select a paragraph visually and type gq, or
Type gqj to re-wrap from the current line to the end of the paragraph