As vim doc said, I can use the -b option to open a binary file.
-b Binary mode. File I/O will only recognize <NL> to separate
lines. The 'expandtab' option will be reset. The 'textwidth'
option is set to 0. 'modeline' is reset. The 'binary' option
is set. This is done after reading the vimrc/exrc files but
before reading any file in the arglist. See also
|edit-binary|. {not in Vi}
I use this command to open vim:
$ vim --cmd 'set et' -u NONE -b
I type this command to view options:
:set et? bin?
expandtab
binary
The et(expandtab) option wasn't reset. Why?
Thanks for your help!
Well the issue is, simply, that --cmd -c or +cmd arguments are executed after processing the other flags. This makes sense, as it would not effectively do anything otherwise.
:verbose set et?
would tell you exactly that. In case you need a workaround for your particular sample vim +'set binary' (unlikely since et != binary)
You are right on the docs for --cmd. So it comes down to the order in which command line flags are interpreted, which is basically 'undefined'. Although
This is done after reading the vimrc/exrc files but before reading any file in the arglist
could be taken to imply 'before processing other command line arguments'.
Note The '+' commands essentially go with specific files and are (AFAICT) processed in the order in which they appear, even when intermixed with filename arguments.
Related
I'm trying to use astyle as my code formatter in Vim. However, I can't seem to find how to tell vim which options to use for astyle.
The following is in my vimrc:
autocmd BufNewFile,BufRead *.cpp set formatprg=astyle\
If given no options in command line mode, astyle will try to find an options file named .astyle. However this does not seem to work here. (Ie: when I format in vim: gqG the result is totaly different than if I had called astyle from the command line !)
This is my .astyle options file:
--style=allman
--mode=c
--attach-classes # -xc
--attach-closing-while # -xV
--indent-classes # -C
--keep-one-line-blocks # -O
--keep-one-line-statements # -o
--align-pointer=name # -k3
So I tried to simply specify the options in my vimrc like in this answer:
autocmd BufNewFile,BufRead *.cpp set formatprg=astyle\ --style=allman --mode=c -xc -xV -C -O -o -k3
Saved, sourced, reloaded vim entierly: no change. The options seem to not take effect. When I format with gggqG the result is still not what my options ask for... Can anyone see why this is not working ?
(Note: I want to be able to format using gq and I don't mind reformatting the whole file entierly each time, unlike in this question)
EDIT:
After a few stupid mistakes I've escaped all the spaces as suggested in #romainl comment. However there seems to be an error comming from vim which I cannot interpret:
/bin/bash: -c: line 1: syntax error: unexpected end of file
shell returned 1
E485: Can't read file /tmp/vHXZmnp/3
Since no one is answering, I'll share what I managed to come up with.
Following the advice given in the comments I escaped all the spaces in the sequence of options passed to astyle. However, this leads to bash trying to interpret the options, failing and kindly telling us so: see question edit.
The solution that seems to work is to create a system wide astyle options file and pass the path to that using command line arguments instead of giving it the options directly.
(This can probably also be done with a project options file but requires having an options file at the root directory of every project)
Taking my options file .astylerc in my home directory this gives:
autocmd BufNewFile,BufRead *.cpp set formatprg=astyle\ --options="/home/myusername/.astylerc"\
Note that a relative path did not work, but it is possible to write the path to the options file using a 'pseudo relative' path using the $HOME environment variable as mentioned in the astyle documentation
I have a default installation of vim on linux, on a system with a vt52 terminal emulator and unicode capability.
Everything has been working fine until today when I moved my vt52 terminfo file from the temporary local user directory to the permanent system directory ... at first it seemed fine, but all the sudden, when I try to execute a colon command by pressing enter (either CTRL-J, or the key itself == decimal 10), vim just flashes the screen but doesn't execute the command or leave command entry mode.
However, If I press CTRL-M to get a carriage return character (decimal 13), vim does accept the command.
I tried copying the file back to ~/.terminfo again, but it didn't fix the problem...
I thought this might be either a tty issue or a corrupted vimrc file, so...
first I tried deleting the .viminfo and .vimrc files, and doing a stty sane before starting vim but neither helps. I just noticed that enter doesn't work in insert mode either, but CTRL-M does.
Then I checked from the bash shell, using CTRL-V, that when I press CTRL-M, it shows ^M and when I press CTRL-J, it just enters and shows nothing. So -- to double check -- I did a stty raw and cat - | hexdumpx, and sure enough pressing enter returns only 0x0a, and pressing CTRL-M returns only 0x0d ; so the keyboard driver is returning the proper character in raw mode, and I retested in sane mode which apparently maps both of them to 0x0A.
The termcap file I re-compiled with tic, and copied to both ~/.terminfo/v/vt52u where it worked fine before -- and over to /usr/share/terminfo/v/vt52u.
But I don't see anything in the termcap file which could possibly cause the problem.
vt52u|vt52 with UTF-8:\
:am:eo:rs=\Ee\Eb0\Eco:is=\EE\Ee:\
:nl=^j:sr=\EI:bl=^g:ta=^i:\
:ho=\EH:cr=^m:le=\ED:nd=\EC:do=\EB:up=\EA:ta=^i:nw=^j^m:xn:\
:cm=\EY%+ %+ :it#8:co#75:li#24:\
:sc=\Ej:rc=\Ek:\
:vi=\Ef:ve=\Ee:\
:so=\Eb0\Ec3:se=\Eb0\Eco:mh=\Eb8\Eco:mr=\Ebo\Ec0:me=\Eb0\Eco:\
:cl=\EH\EJ:cb=\Eo:cd=\EJ:ce=\EK:\
:km:kb=^h:
EDIT:
I've isolated the problem by experiment 5 listed below, as being caused by something either in or missing from the above termcap file, or in the tic compiler's conversion of it to terminfo.
So -- what termcap entry is missing or which existing one is causing the problem?
---------------------- Additional experiments as I try to figure it out -------------------
1: doing a :set term in vim reveals term=vt52u .... which is correct. So VIM should be using the above termcap file, but I don't know from where (eg: cached version, or not -- or corrupted.) and :version only reveals +termcap which says vim should be using a tic compiled termcap file which is what I've been trying to give it.
2: I recompiled ncurses-5.9, and re-installed it to make absolutely sure no corrupt files exist. Nothing changed even with: ./configure --prefix=/usr --without-cxx --without-cxx-binding --without-ada --without-manpages --without-progs --without-tests --with-build-cc=gcc --with-shared --without-debug --without-profile --without-gpm --without-dlsym --without-sysmouse --enable-sigwinch --enable-hashmap --enable-scroll-hints --build=i686-linux --host=arm-linux-gnueabi --without-pthread --enable-widec --with-fallbacks=vt52u --disable-big-core --enable-termcap --enable-getcap-cache
3: doing a :set termcap shows more keys defined than the termcap file has, which is bad... termcap only defined one key ... and that one should be ^H not ^?, so VIM's value doesn't match, but the other termcap values all match, since ^[ is the same as escape \E in the termcap file. So, I have proof that vim is definitely loading the proper termcap file because t_so 's value is unique to the vt52u. So -- it's not a corrupt termcap.... :( weird.
t_kb <BS> ^? <DecMouse> ^[[
t_kd <Down> ^# <NetMouse> ^[}
t_sr=^[I t_bc=^[D t_le=^[D t_cd=^[J t_ce=^[K t_cl=^[H^[J
t_me=^[b0^[co t_mr=^[b0^[co t_ve=^[e t_vi=^[f t_nd=^[C t_se=^[b0^[c0
t_ZH=^[bo^[c0 t_ZR=^[b0^[co t_so=^b0^[c3 t_cm=^[Y%p1%' '%+%c%p2%' '%+%c
4: Recompiled vim 7.4, to remove all built in terminals, and to insure no corrupt files. Had no effect; did not fix default value of backspace key being wrong.
echo "Please Edit feature.h so that NO_BUILTIN_TERMCAPS is always #defined."
sleep 5
vim /src/feature.h
./configure --prefix=/usr/ --build=i686-linux --host=arm-linux-gnueabi --with-features=big --disable-darwin --disable-selinux --disable-xsmp --disable-xsmp-interact --disable-mzschemeinterp --disable-tclinterp --disable-netbeans --disable-sniff --disable-gui --disable-cscope --disable-workshop --enable-multibyte --disable-gtktest --disable-gpm --disable-sysmouse --disable-xim --enable-pythoninterp=dynamic --without-x --with-tlib=ncursesw vim_cv_toupper_broken="yes" vim_cv_terminfo="yes" vim_cv_tty_group="world" vim_cv_tty_mode="0620" vim_cv_getcwd_broken="yes" vim_cv_stat_ignores_slash="yes" vim_cv_memmove_handles_overlap="yes"
echo "Please Edit src/Makefile such that STRIP=arm-linux-gnueabi-strip"
sleep 5
vim src/Makefile
make
make install
5: In bash, I changed the terminal type to generic "export TERM=VT52" rather than the unicode version, with color support which I compiled with tic. ** THE NEWLINE PROBLEM WENT AWAY WITH THE SACRIFICE OF COLOR COMMANDS, AND OTHER FEATURES OF VT52U ** I need the features, but apparently something about the termcap file I listed above is defective.
This was an ugly bug to track down by trial and error...
Vim appears to require keydown to be defined, and if not defined it assumes a default value of ^# ; for an unknown reason, it then treats the enter key as if it were a key down, rather than newline. ^# is logically the value for character code 0, null; which is the only character that would be found in an empty string in "C" which vim is written in and appears to trigger the issue/feature/bug.
But in any event in the termcap shown in the opening post, the kd symbol is not defined; and that's what is causing the problem.
Within vim, the problem can be solved by setting the termcap keydown variable as the same escape sequence which would normally exit insert mode, and then do letter j (down):
:set t_kd=\Ej
The same default can always be added to the termcap entries, too;
Since this is an input escape sequence and not a terminal output escape sequence, it doesn't conflict with the VT52's "save cursor" escape sequence defined in the termcap; eg: The VT52 will never see it since Linux tty's when in line entry mode do not echo escape sequences that come from the keyboard back to the terminal's output.
If a terminal doesn't have true arrow keys -- defining the arrow keys as escaped versions of vim's h,j,k,and l keys might be a reasonably compatible solution as long as it doesn't conflict with other programs which might want to use those input escape sequences for other things. I don't use emacs and other popular programs which might want those escape sequences for something, so if anyone else knows which (if any) programs would have problems with that solution, a comment would be appropriate.
In ncurses 5.9,there appears to be a bug in the terminfo compiler, so that on many installations (eg: slackware 14), 'tic' will not be able to compile terminfo source files -- but only termcap source files. If you want the termcap source code for an arbitrary terminal, you can run "infocmp -C fooTerminalName > fooTerminalName.tcap" to have the system generate a termcap source file for you that can be edited and recompiled with tic successfully.
I am trying to open a 200MB text file in gvim on Windows, and it's choking. The vim window opens and just remains blank and unresponsive. My system has 8GB of RAM and the file opens fine in about 2-5 seconds using notepad.
I found this SO post on editing very large text files in vim, and I tried opening the file with plugins turned off:
vim -u "NONE" my200MBfile.text
But that didn't help. Is there anything else I can do to make it work? It seems strange that vim would choke on my machine on what is not really such a large file.
Thanks!
Most likely it's the syntax plugin that makes vim halt. I never have any issues with files of Mbs-Gbs. Unless I accidentally open them with some - not-so-well-behaved - filetypes.
Press ^C while loading/hanging (interrupting plugins)
:syntax off
Does the trick. There are other options with syntax that makes it easier to work with a file without fully 'synchronized' syntax highlighting
I played around with this some more, and I found indeed some of my plugins would make operating on (very) large files very slow. I did this, for fun:
On a large input file (~600Mb):
$ wc input.txt.full
2674568 2674568 608825278 input.txt.full
I launched vim with the following tweaks:
vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full
Note this
-u NONE prevents execution of initialization (user) scripts and plugins
-n disables the writing of swapfiles (extremely important on slow/small disks)
se nonu nowrap ul=-1 disables
line numbering
line wrapping
undo history (setting undolevels to a negative value)
Basically, everything that could take a lot of CPU or memory
syn off to disables syntax highlighing (should only make a difference if syntax highlighting was in effect for the file type)
Now, I wanted to duplicate each line on the line itself (globally: copy line, join with previous):
:g/^/t.|-j
Unfortunately, the file would become too large for available memory (~3Gb)1 so I opted to act on the first 20% (~535,000 lines):
:exec "norm 20%"|1,.g/^/t.|-j
This works in a "jiffy" and without problems. Manual navigation (jumps, scrolling, mode switching, searching etc.) seems to be responsive.
Commandline Benchmark:
$ xxd -c 44 /dev/urandom | head -n 3800000 > input.txt.full
$ wc input.txt.full
3800000 91820644 627000000 input.txt.full
$ time vim -u NONE -n +'se nonu nowrap ul=-1 | syn off' input.txt.full +'exec "norm 10%"|1,.g/^/t.|-j' +wq
real 0m7.778s
user 0m6.680s
sys 0m0.952s
$ wc input.txt.full
3800000 101002757 689940307 input.txt.full
(Note that 689940307 รท 627000000 = 110.03 %, so that is exactly right).
This isn't slow in my book. For comparison, the wc invocation itself takes the same amount of time (7.7s).
1 All test performed on tmpfs to avoid cache differences.
The problem is more likely that vim doesn't like lines that long very much.
Try using a tool like json_reformat on the file first...
If you absolutely have to edit the file as-is, try :syntax off and possibly :set nowrap before you :edit the file in question.
Although Vim doesn't have a problem opening files of that size (or bigger), it is mentioned that it has a problem of opening a file with, as is your case, only one line (of that size).
You could try various workarounds, but I would suggest going with the "right tool for the right job" approach, and try EmEditor, a text editor made specifically for editing large files (amongst other things).
Note that this is not Vim bashing, but Vim is an editor for editing source code mostly. An excellent one at that, but like every other tool it has its limitations.
When building my application using the :make command in Vim, the output is not colorized. I have configured the makefile to use clang as the C compiler, and when running make outside of Vim or when running :!make, clang's output is colorized. :set makeprg returns makeprg=make, just for reference.
I have the same issue with grep: when running :grep, the output is not colorized; when running :!grep, it is. I have tried using the --color option with :grep, to no avail. :set grepprg returns grepprg=grep -n $* /dev/null.
I've read through VIM Unix commands printed in color and also How to color my vimgrep result patterns. The former seems to have the opposite problem (i.e. :!command output not colorized); the latter doesn't have any alternative to dropping down to the shell, which I don't feel is a "correct" fix for the issue.
The problem is that when Vim runs other commands via :make or :grep, those commands don't get a terminal for their standard output -- in the sense that for them isatty(STDOUT_FILENO) is false -- because Vim is capturing the output on its way to being displayed on the terminal. On the other hand, when you use :!make or :!grep, standard output is just going to the terminal.
Clang by default and grep --color=auto (which is probably how you have it aliased) use the terminalness of stdout to decide whether to colourise their output. This is convenient in that you get colourful output on your terminal but capture just the text when you redirect output to a file -- all without needing to add extra command line options.
So what you want to do is override these commands' usual smarts so that they always colourise their output.
For grep, you can use --color=always when it is run via :grep within Vim:
:set grepprg=grep\ --color=always\ -n\ $*\ /dev/null
and depending on your colour settings and version of grep this will work well enough.
For clang, you can change your Makefile to use clang -fcolor-diagnostics so as to force colourisation or more flexibly add an extra variable to $(CC) that will be overridden when run via :make within Vim:
:set makeprg=make\ EXTRA_CFLAGS=-fcolor-diagnostic
However (at least with clang 3.0 and vim 7.3) you will find that clang's style of colourisation prevents Vim from picking out filenames and line numbers from the diagnostics, so doing this wrecks the advantage of using :make rather than :!make.
You may be able to teach Vim to pick out the filenames etc from the surrounding ANSI escape sequences that do the colourisation by adding more entries to Vim's errorformat option to match the colourised clang-style diagnostics. (And similarly with grepformat if your grep colourisation colours the filenames or linenumbers.)
When you run :grep or :make (as opposed to :!grep or :!make),
the output is not only shown in the terminal,
but also sent to the quick-fix window, from which it is processed.
You can access the quick fix windo using the vim-command :copen.
The quick fix window is essentially a text file that is opened in read-only mode.
Like in any other text file, colors are not supported in the quick fix file.
Instead, they are represented with escape characters like [01;34m.
Therefore, producing colorized output from make (or grep) will
mess up the output as it is shown in the quick-fix window, even if you can get vim to process it,
and send the cursor to the selected error/warning/find message.
The question whether the output is colorized now becomes a little subtle: I suggest that the
terminal output should remain uncolored, but that the quick-fix output should be colorized.
The color scheme in the quick fix window is not defined by any color-indications in the file itself, but in the syntax highlighting
of the quick fix window, defined in the file qf.vim (/usr/share/vim/vim81/syntax/qf.vim on my computer).
The color scheme defined in qf.vim does not add much color to the quick fix window, but the syntax hightlighting
scheme may be extended by creating the file ~/.vim/syntax/after/qf.vim. I use cmake in combination with the
gnu and/or the intel compilers, and get nice-looking results with the following contents for ~/.vim/syntax/after/qf.vim:
syn match qBuilt "Built target *" nextgroup=qTarget
syn match qTarget ".*$" contained
syn match qEnteringLeaving ": \(Entering\|Leaving\) directory *" nextgroup=qdSeparator
syn match qdSeparator "'" nextgroup=qdName contained
syn match qdName "[^']*" contained
syn match qbProgress "\[ *[0-9]*%\]"
syn match qBuild "Building .* object"
syn match qWarn "warning\( *#[0-9]*\|\):"
syn match qError "error\( *#[0-9]*\|\):"
syn match qRemark "remark\( *#[0-9]*\|\):"
hi def link qTarget Constant
hi def link qError Error
hi def link qWarn Error
hi def link qRemark WarningMsg
hi def link qEnteringLeaving Keyword
hi def link qBuild Keyword
hi def link qBuilt Keyword
hi def link qdName Include
hi def link qbProgress Special
I use the :set makeprg functionality to set different make behaviour depending on files. One feature of this is that I can use % and %< in order to refer to the file in the active buffer, as well as $ for environment variables.
I'd like to echo the expanded makeprg variable, but I can't seem to achieve this.
For example, suppose I have :set makeprg=build\ %, and I'm working on file Foo.txt.
I would expect the output of echoing an expanded makeprg to be:
build Foo.txt
However, we have the following result when echoing the &makeprg variable:
:echo(&makeprg)
build\ %
The solution probably involves using expand(), except that this would involve parsing the &makeprg for escaped symbols and dealing with $ appropriately for environment variables. Is there a solution to this that I'm missing?
Why would you need this? For troubleshooting, I would probably just append echo to 'makeprg' (that's a trailing space after \):
:setl makeprg^=echo\
But the following should do what you had in mind. The trick is to split the 'makeprg' string on spaces, and process each word individually:
:echo join(map(split(&makeprg), 'expand(v:val)'))
A bit closer to the truth:
join(map(split(mystring, '\ze[<%#]'), 'expand(v:val)'), '').