I would expect that scrolls one page down. Or is this an issue of my config? If yes, how can I change it?

I'm using iTerm2 on OSX 10.8 and when I use vimpager (e.g. man vim), the iTerm2 screen goes from the regular terminal display to all-black (the background color), then back to showing the regular terminal display, and then finally to vimpager. See this video for a demonstration. Note that the delay there is accentuated, perhaps due to screen recording. Sometimes the flashing happens 'twice': terminal-blank-terminal-blank-terminal-vimpager.

I'm a bit of a noob to bash and vim, so I'm not entirely sure to go about debugging this myself.

my ~/.vimpagerrc:

set noloadplugins
let vimpager_use_gvim = 0
let vimpager_disable_x11 = 1
set mouse=a

I am using MacVim with an alias set up, but if I do unalias vim, the flashing still occurs.

I installed MacVim on my system, and I use MacVim's terminal Vim, which I aliased to vim.
vimpager always uses the system vim, which is a bit troublesome since I have the YouCompleteMe plugin, which requires Vim 7.3.584+, and the system Vim is a couple versions below that. So I get an error message from YouCompleteMe everytime I run vimpager...

There should be a way to specify the path to Vim imho, with a fallback to system Vim.

Simple thing, on lines 80, 205, and 225 ${vimrc} isn't escaped, so attempting to use vimpager from a home folder with a space in the path will result in errors. If the path was /volume/foo bar/home/ for example, it'd result something along the lines of:

E282: Cannot read from "/volume/foo" 
2 files to edit
Skipping non-existing file bar/home/.vimrc
"/tmp/vimpager_659/.zshrc" "/tmp/vimpager_659/.zshrc" [readonly] 53 lines, 1456 characters
E282: Cannot read from "/volume/foo"
Press ENTER or type command to continue

It's quoted elsewhere and quoting those three instances seems to fix the problem.

Whenever I try to pipe something to vimpager, I get this error:

~/ $ echo "hi" | vimpager
sed: -: No such file or directory

Any ideas?

% man cat
sed: -: No such file or directory
Vim: Reading from stdin...

When using zsh's run-help, vimpager_ptree is not setup correctly, e.g.:

% run-help man 
man is /usr/bin/man
vimpager_ptree: []
Error detected while processing /home/user/.vimpagerrc:
line    9:
E684: list index out of range: -2
E15: Invalid expression: exists("vimpager_ptree") && vimpager_ptree[-2] == 'wman'
Press ENTER or type command to continue

vimpager_ptree is "[]" in this case.

I have not investigated much, but it appears that ps awo ... behaves strange in this situation.

Please note that it works with run-help true:
% run-help true
vimpager_ptree: ['zsh', 'bash']
Press ENTER or type command to continue

Whenever I run vimpager, I get this error:

Error detected while processing /Users/mark/.vimrc:
line    4:
E117: Unknown function: pathogen#infect 

I tried adding source $HOME/.vim/autoload/pathogen.vim to my .vimrc to no avail.

Hi!

One issue that's been slitghly annoying me when using vimpager is that whenever I try to open a big file with it, the program hangs until it has seemingly buffered the whole file and then display it. I don't know if it's a desired feature or not, but as less and vim open immediatly any large file I throw at them I suppose it's an issue to be fixed. Another inconvenience comes when we pipe stuff to vimpager, because it also hangs till the program writing to stdout terminates to display stuff (and if the said program is quite slow, it might be painful to just wait).

Steps to reproduce the issue:
dd if=/dev/urandom bs=1M count=40 | base64 | vimpager
Versus:
dd if=/dev/urandom bs=1M count=40 | base64 | less

ANSI escape sequences appear as line noise. It seems from looking at Dr. Chip's ANSIEsc plugin that there may be no clean way to handle these shy of patching vim. Please consider adding a 'col -b' or similar filtering step to remove ANSI escapes.

For example, 'PAGER=vimpager.sh git log' should show quite a bit of escaping that it would be ideal to clean up automagically.

I'm using
system: Mac OS X (10.6.8)
vim: 7.3.315 (MacVim, compiled with brew)
vimpager: 1.6
If I use vimpager to read a file or view a man page I get this error inside vim, before the contents are displayed correctly:

"/tmp/vimpager_82068/stdin" [readonly] 45 lines, 1555 characters
Error detected while processing command line:
E484: Can't open file $MYVIMRC
Press ENTER or type command to continue

I have searched the source file of vimpager but only found four occurrences of the string "MYVIMRC", all in command lines to call vim but none where the variable was set. But the variable is not described in the man page for vimpager. So do I have to put it in my environment? Because if I run MYVIMRC=/dev/null man vimpager all works fine. But then there is the VIMPAGER_RC environment variable already. Why would we need two?

If it is possible I suggest to set the variable to a meaningful value or remove it. If that is not possible I would like to see it documented in the man page.

Thanks for your effort
lucc

vimpager uses /tmp in a very insecure way, which allows another user on the system to tamper with vimpager's data. For example, an attacker can run any command in the context of a user that uses vimpager. To do that, the attacker runs

for i in $(seq 1 65535); do echo '123 | autocmd VimLeave * !echo hello world > /tmp/arbitrary_command' > /tmp/vimpager_cols_$i; done

which sets up many /tmp/vimpager_cols_XXXX files. Line 115 of the vimpager script will fail to overwrite the file (permission denied if run as normal user), but the script will keep running. Line 118 then sets

cols='123 | autocmd VimLeave * !echo hello world > /tmp/arbitrary_command'

And if you configured "gvim" to be used as your editor, lines 337-344 will run

gvim ....... -c "....... set columns=123 | autocmd VimLeave * !.............

which defines a command that is executed when gvim terminates, because it uses the $cols variable that contains the attacker's data.

The fix for this is rather simple, use code like

mkdir -m 700 /tmp/vimpager_directory_$$ || { echo failed to create tempdir; exit 1 }

to create a secure temporary directory. Then, create all your tempfiles in that directory.

After upgrading vimpager from 1.7.1 to 1.7.2, it no longer correctly displays any file or the standard input (when piped to), when ran as a root.

Typical scenario:

# less any-file
E282: Cannot read from "-E"
Press ENTER or type command to continue
2 files to edit
E282: Cannot read from "--cmd"
Press ENTER or type command to continue

Vim then opens with an empty buffer, statusbar containing:

"let vimpager=1 | runtime! macros/less.vim" [New DIRECTORY]

The second buffer contains the data to be viewed, with no syntax higlighting.

(The root user has no special configuration, not even a .vimrc file.)

In my vimrc i have the line
nnoremap :
so I'm able to enter commands faster since enter in normal mode does essentially the same thing as 'j'. However, in vimpager when I press 'j' it brings me into command mode.

I recently added the following bindings to my .vimrc and it's been interfering with Vimpager:

nnoremap j gj
nnoremap k gk

Normally, Vimpager behaves like less in that moving up and down scrolls rather than moving the cursor, but this binding messes that up.

This, I would have thought, would be an obvious one:

9/10ths of the purpose of vimpager is to have a syntax-hilighting pager. So, when I coffee --print utility.tests.coffee | vimpager for the first time after installing it, and see this …

… I'm a bit put-off. Is there really no way to have vim, or vimpager, “sniff” the file or something to try and determine file-type? Failing that, may we please have a way to specify the relevant :setf <foo> command on the command-line, so I don't have to type it every time I open my pager? (=

Vimpager right now does some basic filetype detection with do_ptree. But this feature is not easily extendable without touching vimpager itself.

The best soluion I can think of right now in terms of extensibility is to pass the result of do_ptree to a variable in vim. Then users can do whatever they want with it in .vimpagerrc or .vimrc.

Any thoughts? I would be willing to implement this.

When I try to use vimpager wth MacVim, I get a few screenfuls of "Cannot allocate color" errors before I'm able to view my file. When I open the same file in vim I have no such problems. The same executable is being used in both cases.

Any ideas how to fix this?

Was just wondering if there was a reason you were launching vim with --no-plugins. It causes a ton of errors on my end (my statusline assumes that certain plugins are loaded…)

Ubuntu has a highperformance posix dash for its /bin/sh. This means that vimcat does not work on ubuntu.
vimcat uses #!/bin/sh but explicitly states in the header comment that it is a bash script. This is incorrect behavoir. I would expect that the script should either be updated to avoid any non-posix functionality or more likely the interpreter line should be changed to /bin/bash so that it uses the interpreter it expects.

I cannot find the license information of this product.
3-clause-BSD license is in vimcat script, but it is unclear whether it affect to whole script or only AnsiHighlight part.

Could you note license information in each scripts and/or README?
.

With 1.4.5 I can use vimpager, but I have this line in my vimrc:

let vimpager_use_gvim = 1

but it keeps opening vim in the terminal. Any pointers on troubleshooting this? I'm using MacVim.

I don't like folding in a pager. It's possible to disable folding with set nofoldenable. But it has no effect within .vimpagerrc or .vimrc.

It does NOT quit vimpager and show the follow message when I press `q' (same key used in ToggleComment)

Error detected while processing function ToggleComment_toggle:
line 16:
E21: Cannot make changes, 'modifiable' is off
line 17:
E21: Cannot make changes, 'modifiable' is off
line 18:
E21: Cannot make changes, 'modifiable' is off
Press ENTER or type command to continue

There is no problem in v1.6.8

The copy of VIM that I use is located in my ~/bin directory. vimpager and vimcat completely ignore this version as it is not found in their default search path. There should be a way to customize the search path to include non-standard binary locations.

when I scroll up, I can't go more than ~2-3 lines back. This makes vimpager very difficult to use.

i don't appear to receive mouse support with the present mouse=h, mouse=a works

When opening man pages the script /usr/share/vim/vim74/macros/less.sh seems to run and setting up mappings for ^D and ^F (and others). This causes problems with scrolling using those mappings (where there now is a delay from the keystroke till the scrolling actually happens).

Is there some way of disabling that less script to run (and source less.vim in the macros directory) or any other way to just make it work as meant to work?

Edit: Disabling loading of plugins does work. That disables colorscheme etc as well though (and custom syntaxes). Maybe it's possible to just disable macros from loading somehow.

I'm using Ubuntu 12.10, vim 2:7.3.547-4ubuntu1.1

In my $VIMRC, I have nnoremap <CR> o<Esc>

This seems to clobber some of the keys in vimpager. Specifically, keys that are listed as :noxb, :noxe, :noxj, etc. I can fix this by just calling :unmap <CR> The vimpager keys work as advertised after this step.

I casually replaced instances of :noremap and :nmap to :nnoremap in the vimpager source, but that didn't help out with ignoring my <CR> mapping. I figured nnoremap should work out, but I guess those aren't the lines I'm looking for.

Any suggestions? Or should I just stick with the unmapping for now?

I just installed this (and love it), but with unchanged settings I am unable to scroll left with the h key. What happens instead is I get a help output:

<Space>   One page forward          b         One page backward
d         Half a page forward       u         Half a page backward
<Enter>   One line forward          k         One line backward
G         End of file               g         Start of file
N%        percentage in file

/pattern  Search for pattern        ?pattern  Search backward for pattern
n         next pattern match        N         Previous pattern match

:n<Enter> Next file                 :p<Enter> Previous file

q         Quit                      v         Edit file
Hit Enter to continue

l, j, and k all work as expected.

While open large string stream like git log -p will got warning message col: Illegal byte sequence, and the string-stream be cut off.
I haven't Linux, Just tested on Mac OS X Lion.

The problem is described here: https://github.com/hut/ranger/issues/149. I think it makes sense to have a -- seperator in vimpager as well. It seems to be a standard feature in other pagers. What do you think?

I normally use vim with mouse=a, so when I highlight some text with the mouse in urxvt, that selection is put into the primary X selection. However, with vimpager that is not the case. It seems that any selected text does not update the X selection. If I write the contents of the pager to a file, then open that file for editing, the X selection still does not work properly. But, if I quit vim, then open that file, the X selection does work normally.

There is no such program neither in MSYS nor in MSYS2, and it looks like Linux distributions will include uudecode under optional packages such as sharutils in Ubuntu. These distributions should however come with base64 from coreutils, which is also available in MSYS2. This is a follow-up to issue #83, according to Rafael:

The situation with base64 vs. uudecode is this. Many platforms like Solaris 10 or OpenBSD have uudecode, but not base64, because they don't use coreutils. Mac OSX has base64, but it comes from OpenSSL. Perl is another possibility that is widely available, but not universally either. On the other hand, linux distributions are more likely to have base64 (coreutils) and not uudecode, which is often in an optional package (GNU sharutils.)

Something in the lines of less -X. Free's up some vital brain-juice.

• do_ptree
• awk $2 ~ /(^|/)(man|perl(doc)?([0-9.]*)?|py(thon|doc|doc2))/ {t=1} END { exit 1-t }
  ps: comm: illegal keyword specification

extra_cmd="let vimpager_ptree=[$(do_ptree | awk '{ print """ $2 """ }' | tr '\n' ',')] | call remove(vimpager_ptree, -1)"

• do_ptree
• awk { print """ $2 """ }
• tr \n ,
  ps: comm: illegal keyword specification

tested on openbsd 5.1: comm -> command ? (man ps)

if running "PAGER=vimpager man fopen" , I'm getting additional "m" in the output for text which is supposed to be underlined:

FILE *fopen(const char *mpathm, const char * mmodem);

When trying to copy text from vimpager, I get E481: No range allowed, and nothing goes to the system pasteboard. It's the same with vim shortcuts (e.g. yy) and with mouse selection and Command C.

This is with iTerm 2 on Mac.

I use the fugitive plugin for vim (loaded via vundle), and my vim statusline includes "%{fugitive#statusline()}". Since vimpager starts vim with --noplugin, the fugitive#statusline() function doesn't exist and vim shows an error whenever it is invoked via vimpager: "E117: Unknown function: fugitive#statusline".

I tried to have a conditional "if exists()" block in my .vimrc to check whether the function exists and switch the statusline accordingly, but this didn't work.

If I remove the "--noplugin"s, fugitive is loaded as expected and everything works.

Why does vimpager use --noplugin?

As an example, do man git-stash, then /pop<enter>. Then, hit n to get to the next result - nothing happens. Instead, you have to manually scroll down to the next result, and from there it works for some reason.

Hi, I have been using vimpager more lately. Since vimpager reads vim .vimrc
it ends up with some settings that I prefer to have for text editing which I would like
to turn off when in vimpager mode.

Is there any way you can modify the script to either read an alternate vimrc file
(maybe specified in a enviroment variable VIMPAGER_RC), if this variable is null just go with the
default.
Or alternatively would it be possible to set some variable before reading the vimrc file so I could
do something like in my vimrc:
if in_vimpager_mode
do setting 1;
...
endif

thanks.

That's the error message I get with the latest git version (commit 2d80ede)

vimpager as pager doesn't work nicely with git. Maybe git is just too less specific implemented and there is no other option than making git use less instead of pager. I know the configuration option core.pager of git where I can supply any pager I want and it works if I set less there. I just thought I mention here that it doesn't play nicely in case you can and want do something about it. One good example is "git grep something", especially if it gives less results than screen lines. Then the different behaviour in paging, exiting and coloring between less and vimpager is seen best.

Add scrolloff=5 so when searching manpages (which is done a lot) we can see the context of our search hit.

Example 'man curl', search for 'directory' and press n a few times. do it again with scrolloff=5 to see the difference

I would love to be able to open a new buffer in vim with vimpager. This would allow, for example, reading documentation side-by-side with what I'm coding without having to do shenanigans with terminals.

As a related request, it would be incredibly helpful if there were a command that one could run via command-mode to open a new man page (rather than needing to close vimpager and then rerun man with the desired page).

I have no ~/.vimrc because I'm the only user on my system and I like vim to behave the same whether I'm logged in as the user or root account.

vimpager works fine for me using vim, but if I would like it to use gvim if possible.

Adding let vimpager_use_gvim = 1 to my /etc/vimrc seems to have no effect... so apparently /etc/vimrc isn't being sourced.

Creating /etc/vimpager or ~/.vimpager with contents let vimpager_use_gvim = 1 does cause vimpager to use gvim, but then it doesn't seem to be correctly source my /etc/vimrc like gvim ordinarily does.

Creating ~/.vimrc with the let vimpager_use_gvim = 1 and any theme configuration is my current workaround but I don't think this should be necessary, as the gvim spawned by vimpager should source /etc/vimrc regardless, just like normal gvim does.

I don't understand why I can't use j, k, <C-u> and <C-d> to move up and down. For instance j is mapped to <CR> which makes no sense to me..

EDIT: I can use u to go up, and d "kinda" works (it goes down after a delay).

I don't know if you consider this to be part of the scope of the program, but I always thought that it would be nice to have vim folding for the section headers (.SH).

Not really sure if this is an issue of vimpager, I just happen to notice it only with vimpager. When scrolling through a man page, I randomly use the up/down arrows or the pageup/pagedown keys. The problem is that after using the up/down keys, the pageup/pagdown change its behavior. That's the result of a vim "feature" and the way arrow keys are defined:

:nmap <up>
n <Up> * 1<C-U>

'scroll' 'scr'      number  (default: half the window height)
            local to window
    Number of lines to scroll with CTRL-U and CTRL-D commands.  Will be
    set to half the number of lines in the window when the window size
    changes.  If you give a count to the CTRL-U or CTRL-D command it will
    be used as the new value for 'scroll'.  Reset to half the window
    height with ":set scroll=0".

In my own config I have the arrow keys defined as

<Up> * gk
<Down> * gj

and I don't see this issue.
BTW, thanks for your work, I love vimpager.

Jorge

Hi,
I found a small problem around the vim-launching process of vimpager.

Although if you are setting your own highlights in your .vimrc, vimpager sets syntax highlights to the default of your colorscheme during the launching process.

See:
https://github.com/rkitover/vimpager/blob/master/vimpager#L177
(Line 177 and 186)

The problem is that since these lines call macros/less.vim after vim starts,
so the syntax on code in macros/less.vim (line 39 on my environment) resets highlights to its default.

I know this is not a big problem, but could you consider about it?
(re-executing ~/.vimrc after loading macros/less.vim might be an easy approach?)

Thanks,
rshhh