The following is the contents of the Windows System Clipboard
:function CurrentLineLength
: len = strlen(getline("."))
: return len
:endfunction
I hit the colon and then control r
I then hit shift 8 to paste the contents of the system clipboard.
I hit return and vim comes back with
E488: Trailing Characters
I see some ^M characters in there and removing them does not help. I do know that I can paste the functions into a .vim file and read them that way so its not crippling but as I work through some examples of vim script this would be nice to have.
Is there something special about how functions are entered in or is it possible to paste them from the system clipboard?
Thanks!
I'm not sure about pasting multiple lines to command mode, but you can achieve the same thing by simply putting the function in a register and executing the register (same as a macro).
Also, Vim doesn't seem to like that function as you've pasted it, I've made a couple of changes below. If you copy the below to the system clipboard and then press #* from normal mode, it works.
:function CurrentLineLength()
: let len = strlen(getline("."))
: return len
:endfunction
Vim should not have any problems with carriage returns in command mode (that's what the ^M characters are). I would guess that there are some other characters in the code you're pasting - this is quite possibly the problem if you're pasting from a web page. Try putting the contents of your clipboard into a file and see if it's really what you expect it to be (including all whitespace characters).
Related
I have cygwin installed on my Windows 7 box and I have been running into a problem where when I type a command it will occasionally be wrapped back onto the same line, deleting the bash prompt. Here is an example:
The command in question is command "201" (4 lines from the bottom). I included the others for context.
The text of the command I was typing was
git commit -m "Forced LF line endings."
(Note: I am posting this with mostly git commands, but the problem occurs with any command. I have not noticed a pattern yet.)
It jumped to the start of the line and started to overwrite my prompt.
When I push the up arrow (to view the history) the result is even weirder:
(Note the cursor is many characters past the end of the command.)
When I try to backspace the cursor from that position, I can only go back this far:
Then when I go up into the history from that backspaced line, I get this:
The command starts from the end of the text that is displayed. (This is consistent for the entire history) But when I go up in the history to the faulty git commit ... it displays as it did before with the overwritten text but when I go past it, it deletes a line of the prompt and displays the previous entry in the history the same way it was doing it before (a la image 2).
When I was creating my PS1 variable I has odd output like this, but I have since closed my brackets and things and don't think that is causing the issue. However if you would like to see my .bash_profile (that sets the PS1) feel free to see it on GitHub. It is really short.
I have tried searching for the issue and can only find a few cygwin email archives about the line wrapping in xterm, but no solutions.
PS: As I was pushing the latest .bash_profile, in order to link it, I ran into the problem again when I typed git add .bash_profile and hit enter, it ran the command but returned the cursor to the start of the same command instead of printing a new prompt.
Then when I as writing another commit line, it did the same as the first image, but it blacked out the rest of the line (It wrapped the line, but overwrote the entire line and not just the first few chars.)
See http://manpages.ubuntu.com/manpages/lucid/man1/bash.1.html#contenttoc26:
\[
begin a sequence of non-printing characters, which could be used to embed a terminal control sequence into the prompt
\]
end a sequence of non-printing characters
If you don't enclose non-printing characters (e.g. color sequences) in your prompt with these their length is counted as part of the prompt's length, eventually resulting in the symptoms that you describe.
It doesn't occur frequently to me. When it does, I just type in 'kill -WINCH $$' into the cygwin terminal and it fixes the problem. link to source
I've just started using Terminal (the CLI for Mac OS X).
When I run a command, get some information back, run another command, get more info etc., it is hard (on the eyes) to find a certain point on the screen (e.g. the output for the command before last).
Is there a way of adding a vertical empty space to the end of each output/ after each command is run that has no output?
Each new command that you enter is preceded by a "prompt", and these can be customized (though the exact way to customize depends on the shell). Since you mention Mac OS X I'm assuming you are using the default bash shell, in which case the absolute simplest way to add a blank line is like this: PROMPT_COMMAND=echo. You can run that command to try it out, or add it to a startup file (like .profile in your home folder) to have it done automatically each time.
If you use Bash 4.4 and you want a blank line after your prompt, you could set the PS0 prompt to a newline:
PS0="\n"
Now, this will be inserted every time you run a command:
$ echo "Hello"
Hello
Wondering this too, I've looked at the menu options in Terminal & most of the control characters one can type in and nothing does this on a keystroke. You can however enter an echo command, it alone to leave a single blank line below it before the next prompt. echo \n will add an extra blank line to that, echo \n\n to do 2 extra, ie. 3 blank lines, etc. (you can also do echo;echo;echo getting the same effect)
You can create a shell alias like alias b='echo;echo' (i couldn't seem to get the \n notation to work in a alias), then entering b on a prompt will leave a double-blank line, not bad. Then you gotta figure out how to save aliases in your .profile script.
I tried making an alias for the command ' ' ie. space character, which I though you could type like \ (hmm, stack overflow not formatting this well, that's backslash followed by a space, then return to execute it), but the bash shell doesn't seem to allow an alias with that name. It probably wouldn't allow a function named that either (similar to alias), though I didn't check.
I often use the fish shell, and I found that it does allow a function with that name! Created with function ' '; echo \n; end and indeed it works; at the shell prompt, typing the command \ (again backslash space) leaves a double blank line.
Cool, but.. I tried saving this function using funcsave ' ' (how you save functions in fish, no messing with startup scripts!) and afterwards the function no longer works :^( This is probably a bug in the fish shell. It's in active development right now though, I think I'll report this as a bug since I would kind of like this to work myself.
One could also send Apple a feature request through their bug reporter for an Insert Blank Line menu/keyboard command in Terminal. If someone pays attention to your request it might be implemented in a year maybe.
I wanted to solve exactly the same, and for anyone interested in doing the same, I used what tripleee said in his comment here - I created a .bash_profile (see details here) with the line export PS1="\n\n$ ".
Hopefully that helps someone else too!
I don't have a huge amount of experience using VI. I am running it on Mac OSX.
I've copied and pasted text before in the editor using (when I say gui in the following I mean the Mac OSX gui)
Cursor to highlight and copy i using command C or the gui or the yy command in VI.
Entering insert mode where I want to paste the text and then pasting using command V or the gui
My problem is that a very long line that is split over multiple lines in the terminal becomes multiple lines as shown on the terminal when copied and pasted by any of the methods.
How do I get it to copy and paste excatly as is?
Move the cursor to the line from where you want to copy and paste contents at another place.
Hold the key v in press mode and press upper or lower arrow key according to requirements or up to lines that will be copied. you can press key V to select whole lines.
Press d to cut or y to copy.
Move the cursor to the place where you want to paste.
Press p to paste contents after the cursor or P to paste before the cursor.
You have
:set paste
Put Vim in Paste mode. This is useful if you want to cut or copy
some text from one window and paste it in Vim. This will avoid
unexpected effects.
Setting this option is useful when using Vim in a terminal, where Vim
cannot distinguish between typed text and pasted text.
Assuming your vi is actually vim, before pasting, do:
:set paste
That disables word wrapping and auto-indent and all similar things that modify typed text. After pasting, turn it off again with
:set nopaste
The reason is that while gvim can tell pasting from typing (so you don't need this when using gvim), the terminal version can't, because it's the terminal doing copy and paste and vim simply sees the text as typed. And therefore applies the transformation like it does for any other text.
Someone showed me a neat trick. In the vi editor, set to insert mode ("i"). Then middle-button click at the location where you would like to insert.
Well, if it is actually one long line the easiest way to do this is with a 'Y' in command mode. Just move to the line and do Y and then move to where you want to put the line and do a p (for paste).
After trying everything suggested here and in other answers including trying to format the file afterwards with vi(m) commands and seds, I got smart and just heredoc'd what I wanted to paste with redirection to the file. i.e.
cat << EOF > yourfile.txt
paste what you are trying to paste
another line of pasted text
yet another
foo > bar?
foo = bar??
end of the file(yay)
EOF
everything between the first line and the last line will be pasted to your file without those pesky newlines interpreted as many spaces/tabs. Just beware that what you are pasting might have its own heredoc(like mine did coincidently LOL). In that case would need to manually paste those lines in your editor which shouldn't be an issue.
I'm working with several files in gvim in Windows 7. I need to test the files (Python scripts) in linux. So apart from their original location I want to also save the files in a folder called linux. I want to do this with new files that I will be creating/modifying. That's why I want to use a mapping with the % sign to get the name of the current file Into the new path.
The problem I'm having is that the % sign is escaped with a backslash, so this doesn't work :
:w C:\projects\linux\%:t
Being the original location:
C:\projects\foo\
Is there a simple way to just save the current file in a different folder? (I have read that the % sign is a filename character, so I could erase it from the string isfname and it should work but I think I am making it more complicated than what it really is.)
Sorry, late to the party, but you could also use the workaround
:exe 'w C:\projects\linux\' . expand('%:t')
My recollection is that you can escape the backslash by doubling it (but I'm not on Windows at present so I can't confirm it immediately). You don't need to escape them all, just the one which is causing trouble:
:w C:\projects\linux\\%:t
You might be able to do this sort of thing fairly automatically using the autocmd feature.
The following (untested) line in your platform's equivalent of ~/.vimrc will update a copy of a file when gvim makes modifications:
" clear commands
autocmd!
" when writing buffers, save a copy -- see :help filename-modifiers
autocmd BufWritePost c:/path/to/source/directory w %:t
The :t will take just the tail of the pathname; if you're working with multi-level directories, perhaps :p:. would be better. See the documentation for more details.
If you change the last backslash to a forward slash it will work:
:w C:\projects\linux/%:t
I'm writing a script to check for dos line breaks, in a unix environment. however, I dont have a sample to check my test cases. How do I create one?
Load Vim, write a few lines of text, then:
:set fileformat=dos
:w
Use hexdump -C if you want to verify that the resulting file does contain CRLF.
fprintf(fp,"something\r\n");
or
data[n++]=0x0D;
data[n++]=0x0A;
fwrite(data,1,n,fp);
or have a program like this
rb=fread(datain,1,sizeof(datain),fpin);
if(rb==0) break;
rc=0;
for(ra=0;ra<rb;ra++)
{
if(datain[ra]==0x0A)
{
dataout[rc++]=0x0D;
}
dataout[rc++]=datain[ra];
}
fwrite(dataout,1,rc,fpout);
dataout has to be twice as big as datain just in case.
it is far easier just to tell your text editor to do it, open the file then save or save as after changing the format for that file. The scintilla based editors, scite, geany, notepad++, have no problem with it (geany makes it very easy on a document by document basis). looks like vi and probably emacs will work. Textpad no problem.