So, I have setup my .zshrc to have a basic level of syntax checking by creating bindkey lines for basically all character generating keys and pointing them to respective functions that both generate the character and then call the syntax checker.
It is otherwise working perfectly, however I want to apply it to tab so that it will take into account $BUFFER changes from compinit, however calling compinit manually within the trap_tab function I created doesn't even call compinit.
Any help is much appreciated!
Below is the relevant bit. Just uncomment and recomment the bindkey and zle -N lines. When uncommented, even though compinit is called, I do not receive any autofill options when hitting tab.
# Setup basic config stuff for history size, Vim keybindings, and the like
HISTFILE=~/.histfile
HISTSIZE=1000
SAVEHIST=1000
setopt extendedglob notify
unsetopt nomatch
# Auto-completion (double-tab tab)
zstyle :compinstall filename '/home/terminus/.zshrc'
autoload -Uz compinit
compinit
zstyle ':completion:*' menu select
function trap_tab
{
compinit
}
#bindkey ' ' trap_tab
#zle -N trap_tab
export EDITOR='vim
Turns out there is no "proper" solution, however at least one guy on GitHub figured out a self-described "hacky" solution which does appear to do what I want, albeit with some additional formatting needed: github.com/Valodim/zsh-capture-completion
Related
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.
I have a number of very long and complex Vim configuration files, but these seem to be causing some unpredictable performance slowdowns.
Is there a way of producing a logfile of Vim's internal activity (in the style of verbosefile) which also includes timestamps for each function call to allow me to debug these issues. Alternatively, are there any other tools to help me in this task?
One thing you can try is invoking vim with --startuptime some_file. This will dump the steps performed during startup, along with timestamps. Try :help --startuptime for some more information.
Unfortunately, this shows you timestamps for files, not functions. If you want to see how long a specific function takes, you could put a call to it in a file under the plugin directory, so it's executed on boot. This won't be possible in all cases and it won't give you a lot of granularity, but it might help you narrow down the problem. Someone else might have a better idea, but I'd start by trying something like this.
EDIT:
I just found two things that may help with this problem. One of them is reltime(). Here's an example from vim's help:
let start = reltime()
call MyFunction()
echo reltimestr(reltime(start))
All it does is show the time a function takes to execute. Combined with, for example, Decho, this could provide a simple log of said functions.
The second one should be a lot more powerfule, the :profile command. It lets you profile a piece of vimscript and place the results in a file. :help profile should tell you all you need to know. Unfortunately, it's only available with the +profile feature, which seems to be enabled only in the "huge" feature set. If your vim doesn't have it, you'll need to recompile. If that's a problem, or you don't want to bother, you might be able to achieve good results with reltime alone.
If --startuptime does not fit your needs, you may use the following command:
vim --cmd 'profile start profile.log' \
--cmd 'profile func *' \
--cmd 'profile file *' \
-c 'profile pause' \
-c 'qa!'
(replace --cmd with -c and add -c 'Command that causes slowdown' if problem occurs not at startup). You will get all timings in the profile.log. Table with function timings will be present at the end of the file, to get per-script timings, use the following
script:
" Open profile.log file in vim first
let timings=[]
g/^SCRIPT/call add(timings, [getline('.')[len('SCRIPT '):], matchstr(getline(line('.')+1), '^Sourced \zs\d\+')]+map(getline(line('.')+2, line('.')+3), 'matchstr(v:val, ''\d\+\.\d\+$'')'))
enew
call setline('.', ['count total (s) self (s) script']+map(copy(timings), 'printf("%5u %9s %8s %s", v:val[1], v:val[2], v:val[3], v:val[0])'))
This will open a new file containing just the same table as at the end of profile.log, but 1) for scripts, not for functions, 2) unsorted.
Better late than never? I was searching to see if I could get vim to include some timestamps in the &verbosefile, as it causes vim to append to the file with no indication of when the appending started.
I adapted the solution from ZyX's answer here and after trying some things out, found that a simple echo "foo\n" will append foo and a newline to the &verbosefile:
let s:VerboseLS = ' **** V'.'E'.'RB'.'OSE LO'.'GG'.'ING S'.'TA'.'RTED ****'
let s:VerboseLE = ' **** V'.'E'.'RB'.'OSE LO'.'GG'.'ING E'.'ND'.'ED ****'
function! ToggleVerbose()
let l:timestamp = strftime("%c")
if !&verbose
let l:msg = "\n\n" . l:timestamp . s:VerboseLS . "\n\n"
set verbosefile=~/.vim/log/verbose.log
set verbose=100
echo l:msg
else
let l:msg = "\n" . l:timestamp . s:VerboseLE . "\n"
echo l:msg
set verbose=0
set verbosefile=
endif
endfunction
nnoremap <silent> <Leader>vl :call ToggleVerbose()<CR>
Now I get nice banners in my log:
Sun Feb 17 14:18:02 2013 **** VERBOSE LOGGING STARTED ****
...[snip]...
Sun Feb 17 14:18:08 2013 **** VERBOSE LOGGING ENDED ****
I defined those banners the way I did so that if I source that script file while verbose logging is on so if I search the log for "VERBOSE LOGGING" or similar I won't match on them.
So, you could adapt this method to use reltime if your vim has('reltime') for sub-second precision and maybe make a timing wrapper to call that echos the start/end times for function calls (although you'd have to refactor when you call things inline without the call command).
Ooh, I just had an idea... I wonder if &verbosefile can be set to a named pipe that goes to util that prepends time stamps... Let's see...
I'm using VIM 7.1 on Debian. I have 9 plugins that I load via pathogen.vim. It takes around 8 sec's to load which is quite slow since this is in non-GUI/xterm mode. I ran vim -V and it shows that each module is being searched for in multiple directories.
Initially, ftoff.vim, debian.vim and other "system" related .vim files are searched for in ~/.vim/ and then in /usr/share/vim/vim71/ - I fixed this by moving my .vimrc to .vim/vimrc and: export VIM=/root/.vim, within .vimrc i did a set runtimepath=/usr/share/vim/vim71
But now, when the modules load, they alter this runtimepath and when pathogen loads it's even worse. Is there a way to specify a hash of module-name to dirPath so that this error prone lookup is avoided? Or a way to manually specify runtimepath on a per module basis within vimrc?
Here is an example of my runtimepath after pathogen loads my modules. Obviously, any further loading of a module invovles searching all those pathnames before locating the right path.
runtimepath=~/.vim,~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bu
ndle/The_NERD_Commenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/pathogen,~/.vim/bundle/vim-addon-mw-utils,
/.vim/bundle/tlib,~/.vim/bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist
~/.vim/bundle/Align294,~/.vim/bundle/minibufexpl.vim_-_Elegant_buffer_explorer,~/.vim/bundle/pathogen,~/.vim
bundle/snipMate,~/.vim/bundle/SuperTab,~/.vim/bundle/surround,~/.vim/bundle/taglist,~/.vim/bundle/The_NERD_C
mmenter,~/.vim/bundle/The_NERD_tree,~/.vim/bundle/tlib,~/.vim/bundle/vim-addon-manager,~/.vim/bundle/vim-add
n-manager-known-repositories,~/.vim/bundle/vim-addon-mw-utils,/var/lib/vim/addons,/usr/share/vim/vimfiles,/u
r/share/vim/vim71,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/bundle/snipMate/after,~/.vi
/after,~/.vim/bundle/snipMate/after
I use vim-addon-manager and have 33 paths in rtp, but it takes around 0.7-0.8 seconds to start and immideately close vim (with vim -c 'qa!'), so the problem is either one of the plugins or your system. To check how long it takes to load each plugin, try the following script:
vim --cmd 'profile start profile.log' \
--cmd 'profile func *' \
--cmd 'profile file *' \
-c 'profdel func *' \
-c 'profdel file *' \
-c 'qa!'
You will get all timings in the profile.log. Table with function timings will be
present at the end of the file, to get per-script timings, use the following
script:
" Open profile.log file in vim first
let timings=[]
g/^SCRIPT/call add(timings, [getline('.')[len('SCRIPT '):], matchstr(getline(line('.')+1), '^Sourced \zs\d\+')]+map(getline(line('.')+2, line('.')+3), 'matchstr(v:val, ''\d\+\.\d\+$'')'))
enew
call setline('.', ['count total (s) self (s) script']+map(copy(timings), 'printf("%5u %9s %8s %s", v:val[1], v:val[2], v:val[3], v:val[0])'))
This will open a new file containing just the same table as at the end of
profile.log, but 1) for scripts, not for functions, 2) unsorted.
If problem is your system, you may try the following:
When computer starts create a ram disk and mount it to ~/.vim, then copy all plugins there.
Try merging plugins into a single file, see :h scriptmanager2#MergePluginFiles() (vim-addon-manager must be activated)
Upgrade your computer
Try creating a hardlinks to all plugins in ~/.vim:
cd ~/.vim/bundle;for d in *;do cd "$d";for f in **/*.vim;do t="$HOME/.vim/$(dirname "$f")";test -d "$t"||mkdir -p "$t";ln "$f" "$t";done;cd ..;done
it might not be related, but for me the variable DISPLAY makes a big difference in the time it takes to start vim (even when I have vim compiled without gui).
Try with
DISPLAY= vim
and
DISPLAY=:0 vim
and see if you notice a difference.
http://pastebin.com/R6E4czN7
I've pasted the output of vim -V to pastebin (should be valid for 1 month). It's self explanatory. There are a gazillion searches(414 search lines - most of them are useless). I need to reduce the number of incorrect searches.
1297651453.71068: Searching for "/root/.vim/bundle/pathogen/autoload/scriptmanager.vim"[J
1297651453.71456: Searching for "/root/.vim/bundle/snipMate/autoload/scriptmanager.vim"[J
1297651453.71846: Searching for "/root/.vim/bundle/SuperTab/autoload/scriptmanager.vim"[J
1297651453.78737: Searching for "/root/.vim/bundle/surround/autoload/scriptmanager.vim"[J
1297651453.79179: Searching for "/root/.vim/bundle/taglist/autoload/scriptmanager.vim"[J
1297651453.79684: Searching for "/root/.vim/bundle/The_NERD_Commenter/autoload/scriptmanager.vim"[J
1297651453.80756: Searching for "/root/.vim/bundle/The_NERD_tree/autoload/scriptmanager.vim"[J
1297651453.83: Searching for "/root/.vim/bundle/tlib/autoload/scriptmanager.vim"[J
1297651453.86193: Searching for "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.8662: line 3: sourcing "/root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim"[J
1297651453.88259: finished sourcing /root/.vim/bundle/vim-addon-manager/autoload/scriptmanager.vim[J
diff -w command is used to create a side by side comparison diff file (instead of parallel)
i then view them using vi via ssh terminal
the changes are indicated by either "<" or "|" or ">"
Since the file i am viewing is a source code, navigating to changes alone
using above symbols is difficult since they are also in C source code.
How can i change these default symbols to desired ones ?
Kindly help. Thanks.
Instead of viewing the output of diff -w in vim, you can use vim's built-in diff:
vim -d file1 file2
This opens vim in a vertical split with both files open, and diff markings in the code. This is what it looks like:
And it works in a terminal too:
You can find a short tutorial here
According to my version of diff (2.8.1 from the GNU diffutils by the FSF) -w is used to change the width of the output; The -y parameter outputs side by side comparison. In combination, the two show no further effect than the -y parameter used alone, which means you may have an alias in your terminal profile or in the global terminal profile that aliases diff to diff -y.
I say all this because all options to change the symbols ("<", "|", and ">") conflict with the -y option. If you can live without side-by-side, you have the option of two other included output styles or defining your own. The two output styles are -c (context) and -u (unified). (For more information on what they do see the diff Wikipedia page. For more information on the options see the diff man page.)
A more in depth fix would be to use the following options:
diff --old-group-format="(deleted)---" \
--new-group-format="(added)---" \
--changed-group-format="(updated)---" \
--unchanged-group-format="(nodiff)---" \
old_file.c new_file.c
Now the old file's lines that are not present in the new file are represented by (deleted)---
The new file's lines that are not present in the old file are represented by (added)---
Lines that have been changed are represented by (updated)---
Lines common to both files are represented by (nodiff)---
Since you seem to do this often enough, you have the option of making it an alias in your terminal profile or writing a small shell script to handle it. For more options, see the manual's section on options and specifically see the section on line group formats for information on what you can put between the quotes in the format definitions.
Of course, if you must have side-by-side, try Nathan Fellman's idea above. Otherwise, there's the option of using a dedicated GUI tool for it such as Kompare.
I found a command a couple of months ago that made my bash history auto-complete on what's already on the line when pressing the up arrow:
$ vim fi
Press ↑
$ vim file.py
I'd like to set this up on my new computer, because it saves a lot of time when keeping a big history. The problem is that I can't for the life of me remember where it was mentioned and reading through endless bash references and tutorials unfortunately didn't help either.
Does anybody know the command?
Probably something like
# ~/.inputrc
"\e[A": history-search-backward
"\e[B": history-search-forward
or equivalently,
# ~/.bashrc
if [[ $- == *i* ]]
then
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
fi
(the if statement checks for interactive mode)
Normally, Up and Down are bound to the Readline functions previous-history and next-history respectively. I prefer to bind PgUp/PgDn to these functions, instead of displacing the normal operation of Up/Down.
# ~/.inputrc
"\e[5~": history-search-backward
"\e[6~": history-search-forward
After you modify ~/.inputrc, restart your shell or use Ctrl+X, Ctrl+R to tell it to re-read ~/.inputrc.
By the way, if you're looking for relevant documentation:
Bash uses The GNU Readline Library for the shell prompt and history.
Update .inputrc with the following:
"\C-[OA": history-search-backward
"\C-[[A": history-search-backward
"\C-[OB": history-search-forward
"\C-[[B": history-search-forward
If set enable-keypad on is in your ~/.inputrc as some st (suckless simple terminal) users might, be aware that the arrows keys are in keypad mode. Ubuntu ships with this useful /usr/share/doc/bash/inputrc.arrows:
# This file controls the behaviour of line input editing for
# programs that use the Gnu Readline library.
#
# Arrow keys in keypad mode
#
"\C-[OD" backward-char
"\C-[OC" forward-char
"\C-[OA" previous-history
"\C-[OB" next-history
#
# Arrow keys in ANSI mode
#
"\C-[[D" backward-char
"\C-[[C" forward-char
"\C-[[A" previous-history
"\C-[[B" next-history
#
# Arrow keys in 8 bit keypad mode
#
"\C-M-OD" backward-char
"\C-M-OC" forward-char
"\C-M-OA" previous-history
"\C-M-OB" next-history
#
# Arrow keys in 8 bit ANSI mode
#
"\C-M-[D" backward-char
"\C-M-[C" forward-char
"\C-M-[A" previous-history
"\C-M-[B" next-history
So I'm not sure if you'll need all, but it might not hurt to have in your ~/.inputrc:
# Arrow keys in keypad mode
"\C-[OA": history-search-backward
"\C-[OB": history-search-forward
"\C-[OC": forward-char
"\C-[OD": backward-char
# Arrow keys in ANSI mode
"\C-[[A": history-search-backward
"\C-[[B": history-search-forward
"\C-[[C": forward-char
"\C-[[D": backward-char
This is also on the same topic: My cursor keys do not work and also this xterm: special keys
With ohmyzsh, use this in your .zshrc :
bindkey '\e[A' history-search-backward
bindkey '\e[B' history-search-forward
To reload, source ~/.zshrc or relaunch terminal.
Source: https://superuser.com/a/418299/71680
You may need to enabled bash completion.
Check
/etc/profile
/etc/bash.bashrc
~/.bashrc
to see if any of the above files source /etc/bash_completion. i.e.
. /etc/bash_completion
If /etc/bash___completion is not sourced by any of the above files you will need to add it to one of them.
If you want all bash users on your machine to have bash completion, source /etc/bash_completion from /etc/bash.bashrc.
If it's just you who wants bash completion, source /etc/bash_completion from your ~/.bashrc.