I would like to display invisible line endings in Sublime Text 3, as for example in Notepad++. How can we do that?
This is useful because when the automatic word wrap mode is ON for example, because it becomes hard to distinguish soft line breaks from real ones.
The package RawLineEdit is pretty good for this. It toggles on-and-off a mode where you view and can edit line endings by selecting Raw Line Edit: Toggle from the Sublime ctrlshiftp command prompt.
This is good if you want to be able to flick line endings visibility on and off on the occasions when you want to see it (it's not the best option if you want line endings to be always visible).
It's also very useful for seeing (and editing) if you've ended up with crlf problems, with windows-style cr carriage return characters getting mixed up with the standard lf line end characters shown as ¬:
I have written a basic plugin to display line endings as an explicit character, inline. There's certainly some room for improvement but it does the job.
It is available here: https://github.com/sdive/sublime-text_managelineendings
The other suggestions found here didn't work for the character I was encountering (U+2028). I found that this plugin was able to show me where the character was occurring:
https://packagecontrol.io/packages/Highlight%20Dodgy%20Chars
ctrl + shift + p on editor
now, type toggle word wrap and select it
Related
I have written some c code, and the end of my output is '\n', when I check the output text file in vim, I cannot find the last empty line, however, when I open it with another text viewer, I can find the last empty line. How can I configure my vim to show the empty line?
The way Vim shows \n / 0x0a at the end of the file is that it opens the file without complaining about [noeol] when :editing the file (in a kind of "reverse logic" from what you expect). Vim's (and Unix) philosophy is that the trailing newline should be there. This can be confusing when one is used to other editors or predominantly works on MS Windows.
There's a lot of discussion and questions about this (e.g. here); as this is unlikely to change, get used to it.
I may have a unique situation here. I want gVim (gui version, in Linux) to keep concealed characters concealed no matter what, even when the cursor is on that line or that character gets selected. (It should be as close to if the characters never existed as possible.) Currently the concealed characters show themselves when the cursor enters that line, which causes text to jump around when scrolling and when selecting text.
We are using gView (read-only gVim) to view logs, so as to take advantage of its robust syntax highlighting. Problem is, these logs contain lots of escape characters and TTY color codes, that make reading difficult. (^[33mSomeText^[0m)
I'm using this line to hide them:
syntax match Ignore /\%o33\[[0-9]\{0,5}m/ conceal
Since the files are viewed by non-vim-experts, it looks glitchy and broken when the text un-conceals itself. (And also looks glitchy and broken if the color codes are present, and also looks glitchy and broken if the color codes are blacked-out to become invisible, but still show when selected and appear after copy/paste.)
This should be fine because these files are opened read-only in gview, with an extra set nomodifiable making it even more difficult to save the file. While it's possible to edit and attempt to save the logs, doing so is considered both an invalid thing to do, and a harmless thing to do, and requires enough Vim skills that if someone manages to edit a file they know what they're doing. The problem with being able to edit a line with concealed text does not apply.
If 'conceal' can't be configured to keep hidden text hidden no matter what, an acceptable alternative would be to replace the TTY color codes with whitespace when the file gets opened. But, this has to be done in read-only mode, and we can't have gview throwing up a save dialog on closing the window because the file has been modified by its .vimrc.
Note: I am in full control of the .vim script file sourced when these are read, but cannot control the existence of the TTY color codes or the code that opens the log files in gview. (i.e. I can't pass it through sed or anything like that.) The ideal solution is anything that can transparently nuke the color codes from within a .vimrc, but I'll hear any suggestions. The 'conceal' feature is just my most promising lead.
So, any ideas how to permanently get rid of these on file view without dialogs popping up on close?
:help conceal
When the "conceal" argument is given, the item is marked as concealable.
Whether or not it is actually concealed depends on the value of the
'conceallevel' option. The 'concealcursor' option is used to decide whether
concealable items in the current line are displayed unconcealed to be able to
edit the line.
:help concealcursor
Sets the modes in which text in the cursor line can also be concealed.
When the current mode is listed then concealing happens just like in
other lines.
n Normal mode
v Visual mode
i Insert mode
c Command line editing, for 'incsearch'
'v' applies to all lines in the Visual area, not only the cursor.
A useful value is "nc". This is used in help files. So long as you
are moving around text is concealed, but when starting to insert text
or selecting a Visual area the concealed text is displayed, so that
you can see what you are doing.
Keep in mind that the cursor position is not always where it's
displayed. E.g., when moving vertically it may change column.
Also, :help conceallevel
Determine how text with the "conceal" syntax attribute |:syn-conceal|
is shown:
Value Effect ~
0 Text is shown normally
1 Each block of concealed text is replaced with one
character. If the syntax item does not have a custom
replacement character defined (see |:syn-cchar|) the
character defined in 'listchars' is used (default is a
space).
It is highlighted with the "Conceal" highlight group.
2 Concealed text is completely hidden unless it has a
custom replacement character defined (see
|:syn-cchar|).
3 Concealed text is completely hidden.
Only one command is needed: set concealcursor=n
I might have a better idea—you can pass it through sed (using %!sed) or really do a bunch of other :substitute commands—whatever edits you need to get rid of the color codes.
When you’re done, make sure to set nomodified—this forces vim to think there haven’t been any changes!
Is it possible to have a carriage return without bringing about a linebreak ?
For instance I want to write the following sentences in 2 lines and not 4 (and I do not want to type spaces of course) :
On a ship at sea: a tempestuous noise of thunder and lightning heard.
Enter a Master and a Boatswain
Master : Boatswain!
Boatswain : Here, master: what cheer?
Thanks in advance for your help
Thierry
In a text file, the expected line-end character or character sequence is platform dependent. On Windows, the sequence "carriage return (CR, \r) + line feed (LF, \n)" is used, while Unix systems use newline only (LF \n). Macintoshes traditionally used \r only, but these days on OS X I see them dealing with just about any version. Text editors on any system are often able to support all three versions, and to convert between them.
For VIM, see this article for tips how to convert/set line end character sequences.
However, I'm not exactly sure what advantage the change would have for you: Whichever sequence or character you use, it is just the marker for the end of the line (so there should be one of these, at the end of the first line and you'd have a 2 line text file in any event). However, if your application expects a certain character, you can either change the application -- many programming languages support some form of "universal" newline -- or change the data.
Just in case this is what you're looking for:
:set wrap
:set linebreak
The first tells vim to wrap long lines, and the second tells it to only break lines at word breaks, instead of in the middle of words when it reaches the window size.
The answer to this must be somewhere but I'm not finding it -- can anyone help me understand why in Gedit, if I have a page of code there is no extra trailing blank line, but then when I do a file comparison for my svn commit it shows an extra line being added at the end of the file?
I have a feeling that Gedit is automatically adding an ending line break. But why, I have no idea...
Reality finally won and it's been fixed, but the broken behavior is still the default; enable the WYSIWYG behavior in a terminal with
gsettings set org.gnome.gedit.preferences.editor ensure-trailing-newline false
It's a feature. I don't think it can easily be disabled.
this is intentional: text files should always be terminated by \n, otherwise
tools like 'cat', 'sed' etc may have problems. However there is no reason to
always show an empty line at the bottom of the text view, that's why we do not
show the last \n
paolo borelli [gedit developer]
Some editors (I'm unfamiliar with Gedit specifically) will try to ensure that a file always ends with a newline character. Other editors, like perhaps the one that you originally created the file with, will allow you to end a file without a final newline character.
Try the Whitespace Remover plugin.
When I open a text file in Notepad, it shows a blank line if there is a carriage return at the end of the last line containing text. However, in Vim it does not show this blank line. Another thing I've noticed is that the Vim editor adds a carriage return to the last line by default (even though it doesn't show it). I can tell, because if I open a file in Notepad that was created in Vim, it shows a blank line at the end of the file.
Anyway, I can live with these two differences, but I'm wondering if there is an option in Vim that allows you to toggle this behaviour.
Thanks
PS - GVim 7.2
[Update]
Would this make sense to be on Server Fault instead?
[Update 2]
I'll rephrase this... I need to know when there is a carriage return at the end of single line file (Notepad shows an extra line with no text, with Vim I cannot tell). This is due to a Progress program that reads a text file (expects a single line, but with a carriage return) and parses the text for some purpose. If there is no carriage return, Progress treats the line as if it is null.
[Workaround Solution]
One way I've found to ensure there is a carriage return (but make sure I don't add a second one) is to make sure I have the end of line write option turned on (:set eol) and then just do a write/save. This will put an end of line in the file if it's not already there. Otherwise, it doesn't add a new one.
:help endofline
explains how you could stop vim from adding an extra newline.
It seems that vim treats newline as a line terminator, while notepad treats it as a line separator: from http://en.wikipedia.org/wiki/Newline
There is also some confusion whether
newlines terminate or separate lines.
If a newline is considered a
separator, there will be no newline
after the last line of a file. The
general convention on most systems is
to add a newline even after the last
line, i.e., to treat newline as a line
terminator. Some programs have
problems processing the last line of a
file if it isn't newline terminated.
Conversely, programs that expect
newline to be used as a separator will
interpret a final newline as starting
a new (empty) line. This can result in
a different line count being reported
for the file, but is otherwise
generally harmless.
If I recall correctly, on unix-y systems a text file must be terminated with a newline.
One useful Vim option is
set list
It will help you see all end of lines characters (and possibly other generally invisible chars). So you will be able to view this last endofline directly in Vim and not only in Notepad.
When you open the file in VIM the status line should say [noeol] after the filename. So that's one indication. As Manni said, you can change this by setting both the endofline option off and the binary option on. You can set this as your default settings in a .vimrc file.