Please have a look at the screen shot below:
Why is the following Text highlighted yellow: This is a Test2. The text appears in both files.
I have found a quote from the following website: http://manual.winmerge.org/Intro_diffs.html. The quote is: "it's also useful to treat an entire block of lines as a single difference". Therefore I am wandering if a block is being treated as a single difference. Where is this configured?
WinMerge compares by lines, and treats a block of lines that have differences as a single difference. You don't configure that, per se. That's not your problem.
Your problem is that Test2.txt doesn't finish with a carriage return.
So WinMerge compares This is a Test2\r\n with This is a Test2<eof> and these are different.
(And note how WinMerge treats the rest of the lines in Test1.txt as 'a single difference').
Confirmed with WinMerge 2.14.0.0
Related
In Sphinx (the ReStructuredText publishing system), are there any obscure rules that limit what a literal block can contain?
Background: My document contains many literal blocks that follow a double-colon paragraph, like this:
Background:... follow a double-colon paragraph, like this::
$ sudo su
# echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc
This block (with a different preceding paragraph) is one of the ones that issues an error: "WARNING: Inconsistent literal block quoting." The message indicates that the error is in the "echo" line. In the HTML output the literal block contains only the "sudo" line; the "echo" line is treated as ordinary text.
I haven't been able to identify any common property in the lines that report errors, or anything that distinguishes them, as a class, from lines in other literal blocks that don't get errors.
I stripped down the project to isolate the problem, and I identified it that way.
I had a numbered list item that contained a double-colon literal block that was indented only as far as the list item's text, like this:
2. Set up the... directory::
$ A Linux command
$ Another Linux command
$ And ANOTHER Linux command
$ etc.
When I indented the literal block further, the problem went away.
I was misled by two things:
The message does not point to the first line in the literal block, but to some apparently random line within it. In the case above, it pointed to the fifth line (out of eight) in the block!
In most cases this form of indention, although incorrect, works just fine.
Isolating the problem is a brute-force method of solving it, but is often effective when deduction fails. I'll keep that in mind in the future.
Sometimes I find myself editing a C source file which sees both use of tab as four spaces, and regular tab.
Is there any tool that attempts to parse the file and "normalize" this, i.e. convert all occurrences of four spaces to regular tab, or all occurrences of tab to four spaces, to keep it consistent?
I assume something like this can be done even with just a simple vim one-liner?
There's :retab and :retab! which can help, but there are caveats.
It's easier if you're using spaces for indentation, then just set 'expandtab' and execute :retab, then all your tabs will be converted to spaces at the appropriate tab stops (which default to 8.) That's easy and there are no traps in this method!
If you want to use 4 space indentation, then keep 'expandtab' enabled and set 'softtabstop' to 4. (Avoid modifying the 'tabstop' option, it should always stay at 8.)
If you want to do the inverse and convert to tabs instead, you could set 'noexpandtab' and then use :retab! (which will also look at sequences of spaces and try to convert them back to tabs.) The main problem with this approach is that it won't just consider indentation for conversion, but also sequences of spaces in the middle of lines, which can cause the operation to affect strings inside your code, which would be highly undesirable.
Perhaps a better approach for replacing spaces with tabs for indentation is to use the following substitute command:
:%s#^\s\+#\=repeat("\t", indent('.') / &tabstop).repeat(" ", indent('.') % &tabstop)#
Yeah it's a mouthful... It's matching whitespace at the beginning of the lines, then using the indent() function to find the total indentation (that function calculates indentation taking tab stops in consideration), then dividing that by the 'tabstop' to decide how many tabs and how many spaces a specific line needs.
If this command works for you, you might want to consider adding a mapping or :command for it, to keep it handy. For example:
command! -range=% Retab <line1>,<line2>s#^\s\+#\=repeat("\t", indent('.') / &tabstop).repeat(" ", indent('.') % &tabstop)
This also allows you to "Retab" a range of the file, including one you select with a visual selection.
Finally, one last alternative to :retab is that to ask Vim to "reformat" your code completely, using the = command, which will use the current 'indentexpr' or other indentation configurations such as 'cindent' to completely reindent the block. That typically respects your 'noexpandtab' and 'smarttabstop' options, so it use tabs and spaces for indentation consistently. The downside of this approach is that it will completely reformat your code, including changing indentation in places. The upside is that it typically has a semantic understanding of the language and will be able to take that in consideration when reindenting the code block.
In my terminal, when I'm typing over the end of a line, rather than start a new line, my new characters overwrite the beginning of the same line.
I have seen many StackOverflow questions on this topic, but none of them have helped me. Most have something to do with improperly bracketed colors, but as far as I can tell, my PS1 looks fine.
Here it is below, generated using bash -x:
PS1='\[\033[01;32m\]\w \[\033[1;36m\]☔︎ \[\033[00m\] '
Yes, that is in fact an umbrella with rain; I have my Bash prompt update with the weather using a script I wrote.
EDIT:
My BashWeather script actually can put any one of a few weather characters, so it would be great if we could solve for all of these, or come up with some other solution:
☂☃☽☀︎☔︎
If the umbrella with rain is particularly problematic, I can change that to the regular umbrella without issue.
The symbol being printed ☔︎ consists of two Unicode codepoints: U+2614 (UMBRELLA WITH RAIN DROPS) and U+FE0E (VARIATION SELECTOR-15). The second of these is a zero-length qualifier, which is intended to enforce "text style", as opposed to "emoji style", on the preceding symbol. If you're viewing this with a font can distinguish the two styles, the following might be the emoji version: ☔︉ Otherwise, you can see a table of text and emoji variants in Working Group document N4182 (the umbrella is near the top of page 3).
In theory, U+FE0E should be recognized as a zero-length codepoint, like any other combining character. However, it will not hurt to surround the variant selector in PS1 with the "non-printing" escape sequence \[…\].
It's a bit awkward to paste an isolated variant selector directly into a file, so I'd recommend using bash's unicode-escape feature:
WEATHERCHAR=$'\u2614\[\ufe0e\]'
#...
PS1=...${WEATHERCHAR}...
Note that \[ and \] are interpreted before parameter expansion, so WEATHERCHAR as defined above cannot be dynamically inserted into the prompt. An alternative would be to make the dynamically-inserted character just the $'\u2614' umbrella (or whatever), and insert the $'\[\ufe0e\]' in the prompt template along with the terminal color codes, etc.
Of course, it is entirely possible that the variant indicator isn't needed at all. It certainly makes no useful difference on my Ubuntu system, where the terminal font I use (Deja Vu Sans Mono) renders both variants with a box around the umbrella, which is simply distracting, while the fonts used in my browser seem to render the umbrella identically with and without variants. But YMMV.
This almost works for me, so should probably not be considered a complete solution. This is a stripped down prompt that consists of only an umbrella and a space:
PS1='\342\230\[\224\357\270\] '
I use the octal escapes for the UTF-8 encoding of the umbrella character, putting the last three bytes inside \[...\] so that bash doesn't think they take up space on the screen. I initially put the last four bytes in, but at least in my terminal, there is a display error where the umbrella is followed by an extra character (the question-mark-in-a-diamond glyph for missing characters), so the umbrella really does occupy two spaces.
This could be an issue with bash and 5-byte UTF-8 sequences; using a character with a 4-byte UTF-encoding poses no problem:
# U+10400 DESERET CAPITAL LETTER LONG I
# (looks like a lowercase delta)
PS1='\360\220\220\200 '
Notepad++ obviously recognizes all comments as such. Is there a way to simply delete all?
Edit: Stat-R's bookmark method has helped greatly, not only for removing comments but for conditionally removing lines in general.
For a general file, first of all you need to know the comment operator of the language you are writing the file in. For example, in java script the comment operator is //.
For the following code...
In NP++, you need to
Mark the lines that contains '//'. Make sure the bookmark option is enabled.
Then, choose from NP++ menu Search>Bookmark>Remove Bookmarked lines
EDIT:
Another solution after #Chris Mirno 's suggestion is as follows:
Use regular expression. See the image below. It is self explanatory
To understand it better, refer to these
In the Find & Replace Dialog, put the following regex and adjust the search options as depicted.
/\*.*?\*/
Replace with: (empty)
Select Mode: Regular Expression AND .(dot) matches newline
This should remove all your C style comments spanned across lines.
Star-R and Chris Mirno Answer are also Correct and Good.
But For Line Comment:
//.*?(?=\r?$)
Explanation:
// will be the Starting Position
.*? Will be any character
(?=\r?$) will search to the end of the line (as it is required in line comment)
Note:
But Still check each of the line because for example if your code contains soap format like
//www.w3.org/2001/XMLSchema-instance\x2......");
it will capture this line because the starting is // and it goes to end of the line so watch out for this :)
Warning to all using Stat-R's solution:
This method will remove lines of code if formatted like this:
echo "hello"; //This comment will be detected
Following his method, the entire line will be removed.
Therefore make sure to go through and make these comments, their own line before doing this method.
I have had some luck running a macro for the above. Basically:
search for // (F3)
select to end of line (shift+end)
delete (delete)
Put // into the search dialog by just searching for it once. Then record the three steps in a macro, then play it back until EOF.
The first time I did it I had a problem, but then it worked, not sure what I did differently.
Anton Largiader's answer was the most reliable one, including complex inline comments.
However, it will leave many empty lines, including ones with empty characters (space, tabs...) so I would just add another step to make it almost perfect:
After running the macro, just do:
Edit > Line Operations > Remove Empty Lines
OR
Edit > Line Operations > Remove Empty Lines (Containing Blank Characters)
1st option is good if you wish to remove only really empty lines
2nd options will remove every empty line even containing space etc. so there will be no more actual spacing left between code blocks. 1st option might be the safest with some manual cleanup afterwards.
As someone suggested in another post, the simplest and most reliable is maybe to export the all text in .RTF format using Menu Plugin-->NppExport-->Export to RTF and then:
-Open the newly created file in Word
-Select any part of any comment
-On the top-right side of Word clic Select--> Select all texts with similar formatting
-Remove the selected comments all at once (del or cut if doesn't work)
To remove Powershell comments if someone find it handy:
Removing Comment in a Powershell using Notepad ++
To find just lines beginning with # (and not with # elsewhere in the line).
Notepad++ SEARCH Menu > Find
‘Mark‘ Tab – fill in as below.
Select ‘Mark All’ (clear all marks if used previously).
Regex ^[#}
enter image description here
SEARCH Menu > bookmark > Remove (or do anything on the list with
them)
Clear all marks to reset
You can select no comments just code by doing the following:
Regex ^[^#}
enter image description here
Enter ctrl+shift+K to remove comment
I'm having problems about a regexp.
I'm trying to implement a regex to select just the tab indent blocks, but i cant find a way of make it work:
Example:
INDENT(1)
INDENT(2)
CONTENT(a)
CONTENT(b)
INDENT(3)
CONTENT(c)
So I need blocks like:
INDENT(2)
CONTENT(a)
CONTENT(b)
AND
INDENT(3)
CONTENT(c)
How I can do this?
really tks, its almost that, here is my original need:
table
tr
td
"joao"
"joao"
td
"marcos"
I need separated "td" blocks, could i adapt your example to that?
It depends on exactly what you are trying to do, but maybe something like this:
^(\t+)(\S.*)\n(?:\1\t.*\n)*
Working example: http://www.rubular.com/r/qj3WSWK9JR
The pattern searches for:
^(\t+)(\S.*)\n - a line that begins with a tab (I've also captured the first line in a group, just to see the effect), followed by
(?:\1\t.*\n)* - lines with more tabs.
Similarly, you can use ^( +)(\S.*)\n(?:\1 .*\n)* for spaces (example). Mixing spaces and tabs may be a little problematic though.
For the updated question, consider using ^(\t{2,})(\S.*)\n(?:\1\t.*\n)*, for at least 2 tabs at the beginning of the line.
You could use the following regex to get the groups...
[^\s]*.*\r\n(?:\s+.*\r*\n*)*
this requires that your lines not begin with white space for the beginning of the blocks.