I think this issue happens only in text file(s). So very often, but not always, when I open text file with vim, there are new line spaces inside file, even though I don't have anything inside real text file.
If I tried to remove it, or modify anything, everything will screw up, so I need to reopen file. It looks like this:
Couldn't find on the net about this issue.
Check whether this also happens in GVIM. If it only appears in the terminal, you have a wrong value of $TERM, or (less likely) corrupt / wrong termcap definitions. Most terminals should understand a value of
$ export TERM=xterm
Related
I've been using vim for a few weeks, and so far I've downloaded a few plugins including airline, nerdtree, and a colorscheme. When I downloaded some files with wget, I noticed that they weren't properly aligned. Text in the code files are normally supposed to be aligned in columns, and there generally shjouldn't be issues with indentation. As an example, when I try running the command cat filename.extension, I get this:
This is how the file is supposed to look. Everything is aligned neatly into columns without any issues. However, if I try editing the file in Vim, it instead looks like this:
The text for whatever reason is not aligned properly, and so far I am not sure how to resolve it...
The file appears to be using tabulations for indentation and alignment.
The de-facto standard width of a tabulation is 8 characters.
cat respects that "standard" to the letter, without the possibility of changing the tabulation width.
Vim also respects it by default but it allows the user to change the tabulation width and you tell it to use a tabulation width of 4 characters.
The file looks different because the two programs have different tabulation settings.
Therefore, if you want the file to look the same in the two programs, use the same tabulation settings. Since they can't be changed in cat, you will have to revert Vim's to their default values.
You didn't show us your vimrc so we don't know exactly what you did and we can't really tell you how to go about it.
So, I just realized I could use marks with capital letters to go to different files. That's great! However, I'm trying to find a way to close the buffer and return to the previous one. Say I go to my header file to change or add the declaration of the function I'm writing, and then I'd like to save the file, but only if there's changes to it, to go back to working on the contents of the function. How can I do this?
There's :x, but it also quits VIM
There's :bd!, but it doesnt save the changes
There's :bw, but that's even worse (unfortunately that's w[ipeout], not w[rite]...)
There's ctrl+O, but it doesnt seem to work when I edit the file (also, it doesnt actually close the buffer)
There's :up followed by :bd, but that's two commands and VIM's about efficiency, so I'd prefer a single command if it exists
There's a few other options and variants, but none that do what I wanted, afaik
It feels like this should be simple enough to do with one command, preferably without macros/plugins/functions/snippets/etc; as close to vanilla as possible. I get the feeling I'm missing something obvious.
You could concatenate commands like so:
:w|bd
I'd like to save the file, but only if there's changes to it
:up[date]
to go back to working on the contents of the function
Press Ctrl^, or enter the command :e[dit] #
I'd prefer a single command if it exists
Set an option :set autowrite and then Vim will save the current buffer on pressing Ctrl^ automatically.
I have been bothered by this problem for a while, which affects gdb, bash, gnuplot...etc, almost anything that uses readline. (Surprisingly, csh works without any problem).
The problem is that the backspace would delete a whole word instead of a character. I modified the ~/.inputrc file and after C-x/C-r, it correctly deletes one character. However, after enter is pressed (either to run a command or just starting a new line), the setting in inputrc seems lost again and C-x/C-r is needed again to correct the behavior. I am wondering if someone knows what happened here.
Thank you...
The title is not really specific, but I have trouble identifying the correct key words as I'm not sure what is going on here. For the same reason, it is possible that my question has a duplicate, as . If that's the case: sorry!
I have a Linux application that receive data via flat files. I don't know exactly how those files are generated, but I can read them without any problem. Those are short files, only a line each.
For test purpose, I tried to modify one of those files and reinjected it again in the application. But when I do that I can see in the log that it added a mysterious page break at the end of the message (resulting in the application not recognising the message)...
For the sake of example, let's say I receive a flat file, named original, that contains the following:
ABCDEF
I make a copy of this file and named it copy.
If I compare those two files using the "diff" command, it says they are identical (as I expect them to be)
If I open copy via Vi and then quit without changing nor saving anything and then use the "diff" command, it says they are identical (as I also expect them to be)
If I open copy via Vi and then save it without changing anything and then use the "diff" command, I have the following (I added the dot for layout purpose):
diff original copy
1c1
< ABCDEF
\ No newline at end of file
---
.> ABCDEF
And if I compare the size of my two files, I can see that original is 71 bytes when copy is 72.
It seems that the format of the file change when I save the file. I first thought of an encoding problem, so I used the ":set list" command on Vim to see the invisible characters. But for both files, I can see the following:
ABCDEF$
I have found other ways to do my test, But this problem still bugged me and I would really like to understand it. So, my two questions are:
What is happening here?
How can I modify a file like that without creating this mysterious page break?
Thank you for your help!
What happens is that Vim is set by default to assume that the files you edit end with a "newline" character. That's normal behavior in UNIX-land. But the "files" your program is reading look more like "streams" to me because they don't end with a newline character.
To ensure that those "files" are written without a newline character, set the following options before writing:
:set binary noeol
See :help 'eol'.
I was editing a file with vim. I started another vim to edit the same file, it said that the /tmp/file.swp exits, press "R" to recover it. I chose to recover. But after that, syntax highlight didn't work on that file (other files still ok). I tried :syntax on and some commands but not worked.
You may try to use the following command to specify the type type. For example for c file:
:set filetype=c
I just solve it, in a simple way.
I find the folder which ~/.vim/view/ and remove the record about the py file which i just recovered...
cd ~/.vim/view && ls -alh | grep filename_1 | awk '{print $9}' | xargs rm
You can change that as you like ... just a demo.
:)
I had to recover a vim buffer after a sudden crash. Whilst the file was correctly recovered, I could not say the same for the syntax highlighting. (I am pretty sure this is not language-dependent, but for completeness sake my file was a python script.)
To my knowledge this issue is often due to either sessions, as stated in this similar question, or syntax highlighting which was incorrectly loaded. However vim views also affect how the file is displayed in the editor. This is especially true for those, like me, who tend to automatise the loading of previously stored views. Following this hunch I deleted my stored view file and solved the problem.
Please note this solution obviously comes at a cost: the file will be opened with a fresh view, i.e. no previous layouts (cursor position, opened/closed fols, etc.) will be remembered by vim. This is pretty obvious but I thought I'd mention it nonetheless.
Might need to set the file type for the correct syntax:
" C syntax:
:set ft=c
" Java syntax:
:set ft=java
" Python syntax:
:set ft=py
" ... etc.
You can re-run the buffer open process to run all autocommands again by typing :e % which edits the current file. This will make all bufread* auto commands run and you'll get everything back. I believe they are deliberately disabled in case there's something bad in the recovered file and custom autocommands may do something bad with a corrupted file.