When editing a dos-format file from a codebase which is mainly used with Visual Studio in a Windows environment on my local Ubuntu machine with VIM, I get to see the ^M character instead of a newline.
According to the VIM documentation, this represents the carriage return character.
Further complicating the problem is that this only occurs in certain places in the file, so the newlines don't seem to have a consistent format.
By default, VIM recognizes the file as dos file-format, which I see by executing :set ff?.
My goal is to edit the file without breaking its platform conformity; I don't want to persistently convert the file, only because I'm editing in VIM. Hence, the existing answer doesn't satisfy my problem. This answer, doesn't either.
Given this requirement, can I get VIM to just display all ^M's as newlines via some syntax highlighting setting?
Note that ^M isn't composed out of plain characters. I you'd insert them manually in VIM, you'd have to insert Cntr-V before inserting each character.
this only occurs in certain places in the file
There's your problem. If CR-LF were used consistently for all line endings, Vim would (with dos in 'fileformats') correctly detect Windows-style line endings, and handle them transparently (i.e. without showing ^M).
As it is not, Vim detects the file as unix, and displays the parts with Windows line endings with a trailing ^M. You could use the conceal feature to hide them:
:syntax match hideControlM "\r$" conceal
:set conceallevel=2 concealcursor=nv
But if you want to maintain the original structure as much as possible, you need to be able to view them, and add them manually (via <C-V><C-M>) if you add lines inside those Windows-style areas.
Many people would argue that such inconsistent line-ending style is a bug and should be converted to an agreed-upon, consistent line-ending style. Most version control systems (I hope you use one) have automatic conversion features that make it easy to achieve interoperability with both Windows and Unix users.
Related
I have some formatting configured in vim for tabs, trailing spaces and line wrapping:
I have set mouse=v, I copy text by selecting it on the terminal and pasting it into another application. How can I configure vim so those formatting characters are not included into the copied text?
When you don't let Vim handle the mouse, it'll be the terminal that processes the text selection. For the terminal, any application is just driving the cursor and printing characters here and there. It doesn't have any semantic background for the terminal contents; it's just lines and columns of characters.
So, you cannot expect the terminal to be able to detect line wrapping inside Vim. Neither can the terminal discriminate between actual text characters and surrounding visual information (the same applies to statuslines, number and fold columns, etc.)
Therefore, if you want access to the actual text, do the copying through Vim; it has the registers * and + for the X selection and system clipboard, respectively. For these to work, certain preconditions need to be met. There are plenty of related questions here and elsewhere on the Internet (depending on your OS, terminal, and how and what version of Vim you've installed).
If you really can't get this to work, you can :write (parts of) the buffer to a temporary file, and do the copy from there. If you connect to a different host, use Samba, scp, or ftp to transfer the file. As a last resort, temporarily disable the visual embellishments inside Vim, copy from the terminal, and undo hard wraps in the target application after pasting.
I created a Vim plugin to toggle linenumbers, listchars, etc. using a mapping: https://github.com/timakro/vim-copytoggle
Ingo Karkat's answer to use the clipboard feature of Vim is an alternative. I decided against it since debian packages Vim without the feature (the vim-gtk package includes it) and I don't want to set up X11 forwarding everywhere, and I don't want to install X11 libraries on headless servers. Also just selecting text with the mouse is more convenient for me. That though can also work using the clipboard feature by setting set mouse=a and set clipboard=autoselect,autoselectplus, see :help 'clipboard'.
I use tabs for indentation in all my files. However, some bigger projects still use spaces, so I also need to follow those guidelines when I contribute.
This issue could easily be solved if the editor would detect the indent character used in the edited file, and use that one when e.g. autoindenting.
Sadly, vim forces spaces for indent, even when I am editing a file which otherwise only uses tabs.
How can I tell vim to always just use what the file is using (and use tabs if the file isn't using anything)?
I tried adding the following line (as I understand it, this should be forcing tabs - not exactly what I want, but better than inserting spaces everywhere) to ~/.vimrc and reopening the file I was editing, but this failed to take effect.
I am running vim-8.0.0386.
It looks like tpope/sleuth plugin is exactly what you want.
Otherwise, DetectIndent works too.
Clone the DetectIndent repo in your .vim/bundle/ directory (I use pathogen to install plugins), then open any file and type: :DetectIndent
Now shiftwidth, expandtab and tabstop should be adjusted to your file.
Here's another plugin recommendation: My IndentConsistencyCop plugin. It does not only detect the used indent setting, but also warns you if inconsistent settings are used within the same file.
In my vimrc file I have the options set wrap and set lbr which are telling Vim to wrap lines and to do so at whitespace / certain punctuation marks. Functionally this works fine on new files. Writing my name over and over wraps the text between names without inserting a newline.
If I open an older file from when I had some different settings (which I don't remember) Vim inserts newlines whenever it wraps. Old wrapped text remains, wrapping correctly but remaining on its own line 'number'. I can set lbr and Vim correctly wraps all the old lines at the end of the line rather than whitespace as expected, set nowrap will remove all my wraps, putting each line on a new 'numbered' line. Setting these two commands back again puts the file back how it was. For some reason any new wrap in this file is just misbehaving.
Is there a logical reason for this seemingly random behaviour?
Do you use sessions or views, or related plugins? With the default option values, the 'wrap' and 'lbr' settings may have been persisted and recalled. In general, you can find out where the option got set via
:verbose setlocal wrap? lbr?
Testing the behaviour on a number of files, the behaviour is caused by the ".txt" file extension.
Creating a new file in Vim with no extension behaves correctly. When the file is saved with ".txt" on the end and re-opened, it misbehaves, removing ".txt" corrects the behaviour
The problem is being caused by Vim's filetype detection and its preference to wrap text in an 'intelligent' method that I imagine preserves the wrapping when the file is opened in another text editor which doesn't support wrapping.
Opening a file in vim or Notepad++ allows you to see a guess as to what file encoding a file
might have.
I have a file that I recently used vim under Linux to replace the line endings with \r and then later determined that I needed to know what type of encoding it was in.
I attempted to determine the encoding of the file using VIM (for Linux) and Notepad++ (for windows).
vim determines it to be fileencoding=latin1 and Notepad++ determines it to be ANSI
Do line endings have anything to do with determining the encoding? Would the fact that I changed the line endings have an effect on the detected character encoding?
Absent a byte order mark (BOM) at the beginning of the text file, the editor has to apply some heuristics to determine the file encoding. In Vim, this is controlled by the 'fileencodings' setting.
It is unlikely that the file's line endings (CR vs. CR-LF) influence the heuristics. Rather, the encoding names are not standardized, so different editors and tools come up with their own names.
You can find out about Vim's naming scheme via :help encoding-values. Presumably, the latin1 corresponds to what is called ANSI in Notepad++, and is frequently referred to as ISO 8859-1.
Every encodings related question I've found is about how to recode files.
However, mine is quite contrary one - is it possible to make vim not to recode files at all? (and how, if so?)
Sometimes it is writing [converted] at the status line, and always miss. However, I have my terminal set at the same encoding as edited file, so, I don't need no recoding at all.
Use
vim -b "myfile.type"
to edit in binary mode. You can also set
:set binary
or if you're lazy like me
:se bin
before editing a file in vim (applies to the current buffer)
:he `binary`
*'binary'* *'bin'* *'nobinary'* *'nobin'*
'binary' 'bin' boolean (default off)
local to buffer
{not in Vi}
This option should be set before editing a binary file. You can also
use the |-b| Vim argument. When this option is switched on a few
options will be changed (also when it already was on):
'textwidth' will be set to 0
'wrapmargin' will be set to 0
'modeline' will be off
'expandtab' will be off
Also, 'fileformat' and 'fileformats' options will not be used, the
file is read and written like 'fileformat' was "unix" (a single <NL>
separates lines).
The 'fileencoding' and 'fileencodings' options will not be used, the
file is read without conversion.
If you are editing binary files you want what sehe suggests, binary.
If you're editing text files, then you probably need to change fileencodings, or if the problem is that vim hasn't detected the terminal encoding correctly, encoding.