Original issue 19 created by powerman on 2014-01-13T15:20:00.000Z:

Hello,

Please consider adding support for "fallback" help providers.
I have attached (a diff between current trunk and) a working implementation you might want to use.

It works by examining additional variables named g:ViewDoc_{ft}_{num} where num specifies priority.

For example usage see attached config for bash that defines a handler for bash builtins (using bash's help builtin) and falls back to man for everything else.

Additionally the patch sets b:topic that can be used for status line display.

This might be able to be added through the usage of cppman:

https://github.com/aitjcize/cppman

Original issue 20 created by powerman on 2014-01-15T15:19:17.000Z:

Hi,

Perldoc actually outputs documentation in man format (using groff, just like man does). This means that
(1) it needs postprocessing with col -b, just like man
(2) setting ft=man will make it look prettier

Attached is a patch that fixes it.

Good day, I wish there were an option to hava a single window designated for docs opened in a splitwindow. I.e. like current mode with g:viewdoc_open="belowright vnew" but on entering a yet another :ViewDoc* command the content of the already opened page would be replaced by the requested doc.

I thought

g:viewdoc_open="belowright vnew"
g:viewdoc_only=1

will get this result, but it works as in single window mode.

Original issue 14 created by powerman on 2013-07-25T10:45:37.000Z:

There seems to be an issue with how the plugin formats spaces/tabs in help files. I'm working on file which uses spaces, not tabs and display tabs as "|".

For reference, here's my vimrc.local that i use on Ubuntu:

https://gist.github.com/mikehaertl/1612035

This is how the output of "pman isset" looks with viewdoc. Note, how the table on the bottom is also completely messed up with tabs.

ISSET(3)| | | | | | 1| | | | | | | ISSET(3)

isset - Determine if a variable is set and is not NULL

SYNOPSIS
bool isset (mixed $var, [mixed $...])

DESCRIPTION
| Determine if a variable is set and is not NULL.

| If a variable has been unset with unset(3), it will no longer be set. isset(3) will return FALSE if testing a
variable that has been set to NULL. Also note that a NULL byte ( "\0") is not equivalent to the PHP NULL constant.

| If multiple parameters are supplied then isset(3) will return TRUE only if all of the parameters are set. Evalua‐
tion goes from left to right and stops as soon as an unset variable is encountered.

PARAMETERS
| · $var
| | - The variable to be checked.

| · $...
| | - Another variable ...

RETURN VALUES
| Returns TRUE if $var exists and has value other than NULL, FALSE otherwise.

CHANGELOG
┌────────┬──────────────────────────────────────────┐
│Version │| | | | | │
│| │| | | | | │
│| │| | Description|| │
│| │| | | | | │
├────────┼──────────────────────────────────────────┤

Original issue 23 created by powerman on 2014-01-19T02:34:29.000Z:

Please consider adding support for GNU info manuals to ViewDoc.
I have attached a script with proper handler(s).

It defines 3 separate handlers for: navigation inside info dcuments, keyword search, command line.

It defines 1 new command (:ViewDocInfo with abbreviation :info), that can be called with any number of parameters:

• with no parameters it will load info directory (dir)Top
• with one parameter it will load a named node (if parameter is in (file)node format) or top node of named manual
• with two or more parameters it will load specified node, 1st parameter is used as manual name, the rest are used as node name
  Example invocations are:
  :ViewDocInfo
  :ViewDocInfo gawk
  :ViewDocInfo (gawk)Functions
  :ViewDocInfo gawk Functions
  :ViewDocInfo gawk Getting Started
  Provided completion script completes info manual names for 1st parameter and node names for the other.

For keyword search one needs to set two variables per filetype:
let g:ViewDoc_{ft} = function('ViewDoc_info_search')
let g:ViewDocInfoIndex_{ft} = '{index node}'
{index node} can be either a string (name of index node of manual, eg. "(gawk)Index") or a list (if there are multiple indices that should be used).
Settings are insluded for awk, make, m4 and automake.

Two vriables define module settings:
g:viewdoc_info_cmd defines path of "info" binary (defaults to "/usr/bin/info")
g:viewdoc_infopath defines directories to search for info files (defaults to '/usr/share/info")

Note that this handler requires:

• a syntax file for info documents (attached),
• support for b:topic in ViewDoc (included in patches for issue# 19)

Original issue 22 created by powerman on 2014-01-16T21:20:43.000Z:

Currently when viewdoc is opened in reusable buffer (eg. with ViewDoc!) it is always named "[Doc]", which makes it easy to identify it by other plugins (eg. statusline plugins, bufferline, etc.). This is not the case when opening of new buffer is requested (eg. by calling ViewDoc* commands without a bang).

I propose to create such buffers with a generated name starting with "[Doc]", for example by using the attached patch.

Hi,

I am very impressed with the plugin. One minor issue: When viewing man pages, pydoc, perldoc, etc., vim-plugin-viewdoc doesn't seem to respect $MANWIDTH or &winwidth. Is there anyway I can narrow the output of vim-plugin-viewdoc to 80 columns for all doc types?

Hi, it worked under windows, but now stopped with message "System cannot find the path specified".
Is it possible to fix this, pls?

Original issue 12 created by powerman on 2013-07-22T06:54:32.000Z:

In the help it says:

You can have several documentation sources for same file type,
and choose which one should be used on-the-fly.

I couldn't really figure out how to do this. The help is probably relating to the file type handlers:

ViewDoc_{filetype}(topic, filetype, synid, have_context)

But i could not really figure out, how to achieve what i want.

My goal is, that when I'm editing PHP files I want to use help files from two sources:

• vim help files in /etc/vim/bundle/yii-api-vim/doc/*.txt, or if none exists
• PHP man pages with pman

It would be great to see an example for something like this.

Original issue 18 created by powerman on 2013-08-23T10:24:09.000Z:

Latest code stop working and produce following error on any :help command:

Error detected while processing function ViewDoc:
line 36:
E485: Can't read file d:/tmp/VIo8675.tmp

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 22 2013 21:56:27)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-7
Compiled by zdm@zdm-vaio
Huge version with GUI. Features included (+) or not (-):
+arabic +ex_extra +mouseshape +syntax
+autocmd +extra_search +multi_byte_ime/dyn +tag_binary
+balloon_eval +farsi +multi_lang +tag_old_static
+browse +file_in_path -mzscheme -tag_any_white
++builtin_terms +find_in_path +netbeans_intg -tcl
+byte_offset +float +ole -tgetent
+cindent +folding +path_extra -termresponse
+clientserver -footer +perl/dyn +textobjects
+clipboard +gettext/dyn +persistent_undo +title
+cmdline_compl -hangul_input -postscript +toolbar
+cmdline_hist +iconv/dyn +printer +user_commands
+cmdline_info +insert_expand +profile +vertsplit
+comments +jumplist +python/dyn +virtualedit
+conceal +keymap +python3/dyn +visual
+cryptv +langmap +quickfix +visualextra
+cscope +libcall +reltime +viminfo
+cursorbind +linebreak +rightleft +vreplace
+cursorshape +lispindent -ruby +wildignore
+dialog_con_gui +listcmds +scrollbind +wildmenu
+diff +localmap +signs +windows
+digraphs -lua +smartindent +writebackup
-dnd +menu -sniff -xfontset
-ebcdic +mksession +startuptime -xim
+emacs_tags +modify_fname +statusline -xterm_save
+eval +mouse -sun_workshop +xpm_w32
system vimrc file: "$VIM\vimrc"
user vimrc file: "$HOME_vimrc"
2nd user vimrc file: "$HOME\vimfiles\vimrc"
3rd user vimrc file: "$VIM_vimrc"
user exrc file: "$HOME_exrc"
2nd user exrc file: "$VIM_exrc"
system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM_gvimrc"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: gcc -Iproto -DWIN32 -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -DHAVE_PATHDEF
-DFEAT_HUGE -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE
-DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE
-DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=x86-64 -Wall -Id:/utils/perl/lib/Core

Original issue 25 created by powerman on 2014-04-23T21:53:38.000Z:

Привет. Я знаю, что ты говоришь на русском.

Плагин перестал работать с vim >= 7.4.264.

Это изменения, которые были добавлены в данном патче:

updated for version 7.4.264
Problem: Can't define a function starting with "g:". Can't assign a
funcref to a buffer-local variable.
Solution: Skip "g:" at the start of a function name. Don't check for colons
when assigning to a variable.

ViewDocInfo ls gives error Sorry, no doc for (ls)Top

Only top-level nodes can be directly accessed like ViewDocInfo coreutils

ViewDocInfo coreutils Directory listing also works but that's not shown in tab-completion list (besides that's not very useful -- nobody looking for info ls would even think about that)...

Original issue 15 created by powerman on 2013-08-08T22:11:23.000Z:

What steps will reproduce the problem?

1. Edit a python source code
   class A:
   def method(self):
   pass

a = A()
a.method()

1. Put cursor | at
   a.met|hod()
2. Press * in normal mode

What is the expected output? What do you see instead?
I expected "method" word to be selected, and to be able to navigate to function declaration

Instead 'a.method' is selected

What version of the product are you using? On what operating system?
Vim 7.3 (patched to 1314), Fedora

Please provide any additional information below.
In python case, it is the consequence of adding '.' to 'iskeyword',
but it also affects other languages (same issue for 'vim' because of the addition of ':')

Considering python case, and some former issue you had to face:
module.function => pydoc can work
instance.method() => since instance type cannot easily be guessed,
accessing to method documentation is not trivial
so it is debatable if adding '.' was a good choice.

Some possible hints:

• don't force iskeyword change, provide a way for the user to decide
• document the 'feature'
• consider some function that could be called whenever a simple keyword documentation lookup fails (you don't have to provide the function because
  it will be different for each language, but at least people could consider extending it according to the availability of some context)

Example for python
aaaa.bbbb.ccc|ccc
try: pydoc cccccc
if failed: try: pydoc bbbb.ccccc
if failed: try: pydoc aaaa.bbbb.ccccc

d|ddd
    try: pydoc dddd
    if failed: if some 'import dddd from mmmm' exists, try: pydoc mmmm.dddd
    if failed: if some 'from mmmm import eeee as dddd' exists: try: pydoc mmmm.eeee

When I open a man page with :ViewDocMan I get the following error:

:ViewDocMan pipe
Error detected while processing function man#init_pager:
line    2:
E21: Cannot make changes, 'modifiable' is off
E21: Cannot make changes, 'modifiable' is off
Error detected while processing /usr/share/nvim/runtime/syntax/man.vim:
line   29:
E121: Undefined variable: b:man_sect
E15: Invalid expression: b:man_sect =~# '^[23]'

This also happens when I pass a section, e.g. :ViewDocMan 2 pipe or :ViewDocMan pipe(2) (which I thought might solve it, because the error is that b:man_sect is not set), when I use the :ViewDoc command, e.g. :ViewDoc pipe man or using the K keybinding on the word pipe in a C file. Other filetypes than man seem to work just fine.

Oddly enough, when I press any key to close the error message, the requested man page shows just fine...

Versions

• viewdoc: the master branch
• Neovim: 0.2.0 (from the Arch Linux repository)

Viewdoc config

let g:viewdoc_open = 'topleft new'
let g:viewdoc_openempty = 0

Original issue 3 created by powerman on 2012-01-20T17:27:31.000Z:

There are no references in vim docs that such names are legal, all you have is

        Define a new function by the name {name}.  The name
        must be made of alphanumeric characters and '_', and
        must start with a capital or "s:" (see above).

under “:h :function” and

"filename.vim".  For example "~/.vim/autoload/filename.vim".  That file should
then define the function like this: >

    function filename#funcname()
       echo "Done!"
    endfunction

under “:h autoload”. Thus you can’t rely on this behavior of “:function”.

Original issue 17 created by powerman on 2013-08-10T07:53:48.000Z:

The usual behavior of :bn is, to go to the next buffer. From the help:

  If you are in a help buffer, this takes you to the next help
  buffer (if there is one).  Similarly, if you are in a normal
  (non-help) buffer, this takes you to the next normal buffer.

This doesn't work with the viewdoc plugin. If you are in a normal buffer and enter :bn several times, it will not ignore the viewdoc help buffers. It doesn't matter whether a [Scratch] or [Doc] buffer is used.

If it's not possible to ignore the buffers with :bn (and :bp, etc.), maybe we could get custom command:

:ViewDocBn
:ViewDocBp
...

Original issue 24 created by powerman on 2014-01-29T11:25:33.000Z:

Documentation for LaTeX can be added using ViewDoc_help_custom.

Download URL for help file: http://vim-latex.sourceforge.net/download/latexhelp.txt (comes from VIM-LaTeX project).

In order to correctly search for LaTeX keywords update of &iskeyword is needed, proper ftplugin/tex_viewdoc.vim is attached.

Hello, thanks for this plugin, I've been using it for quite a long time, but there was something that started to annoying me but never tried to solve it, until now...

I do like that viewdoc opens the help on a new tab, when I'm done reading the doc, I close the tab, this gets me back to where I was before opening viewdoc, (this is fine), but what I don't want is that the Doc buffer is still open, even that the tab was closed, the doc is still in the buffer list thus me changing buffers I'll change back to the viewdoc buffer which I don't want to see.

Is there a way to kill the doc buffer when closing the tab? something like:

on :tabclose if filetype is one of ["help", "man" "pman"] then :bd Doc1

Thanks!

Original issue 13 created by powerman on 2013-07-25T07:09:44.000Z:

If i try to create a custom handler in .vimrc it's never used.

I tried this for a test:

function ViewDoc_php_my(topic,filetype,synid,ctx)
echo "hello"
return { 'ft' : 'help', 'topic' : a:topic }
endfunction

let g:ViewDoc_php = function('ViewDoc_php_my')

If i open any PHP file the above handler is never used. For debugging i checked the value of g:ViewDoc_php:

:echo ViewDoc_php
ViewDoc_pman

So how exactly are custom handlers supposed to be configured?

I use vim's sessions quite a lot, and this is one big disadvantage that I see in my testing of vim-plugin-viewdoc: The help file opened by it does not survive session save and restore. This disadvantage does not exist for vim help documentation opened using inbuilt :help command. User can detect the filetype upon restoring a session and make it behave exactly as if it was opened using :help and not opened as a file with :e <path_to_file> (which does not guarantee jumps to work for all references).

There are multiple ways to go about creating a perception that vim-plugin-viewdoc's buffer survives across sessions.

At the very least, it would be good to know 2 things:

1. Full path of file that is actually open at the time of exiting vim.
2. A way of knowing that current buffer is a vim-plugin-viewdoc buffer, &filetype correctly says "help". Trying to do a regex match on file name \[Doc[0-9]+\] does not look the cleanest.

I think this would be sufficient for users who care about making vim-plugin-viewdoc's buffers survive across sessions.

AND perhaps you could add full support by using SessionLoadPost auto command to iterate over buffers and convert them to respective vim-plugin-viewdoc buffers & give users a new global variable to enable/disable that functionality.

Original issue 9 created by powerman on 2012-08-11T09:25:46.000Z:

check out this pull request:
#1

Original issue 21 created by powerman on 2014-01-16T21:06:20.000Z:

What steps will reproduce the problem?

1. Open vim, type :ViewDocHelp usr_41
2. Move cursor to one of menu items, eg. 41.6
3. Press Enter or <C-]>

What is the expected output? What do you see instead?
Help jumps to chapter 41.1 istead of 41.6 because only "41" treate as a keyword (instead of "4.16").
ViewDoc removes dot and comma from &iskeyword for help files.

Original issue 11 created by powerman on 2012-11-07T16:05:49.000Z:

I'm trying to add support for PHP manual pages (pear:doc.php.net/pman) to this plugin. I've got everything working (code below), except of the tiny little annoying problem: when I navigate back through simulated tag stack (with C-t) syntax gets reset to "pman" (the &filetype value) even though I set it to "man" in my ftplugin.

viewdoc_pman.vim:
function ViewDoc_pman(topic, ...)
let args = g:ViewDoc_ParseMan(a:topic) " calls the man string parsing code refactored from ViewDoc_man
return {
\ 'cmd' : printf('pman %s %s', args['sect'], shellescape(args['name'], 1)),
\ 'ft' : 'pman',
\ }
endfunction
let g:ViewDoc_php = function('ViewDoc_pman')
let g:ViewDoc_pman = function('ViewDoc_pman')

$VIMRUNTIME/ftplugin/pman.vim:
set syntax=man

What steps will reproduce the problem?

1. Open a php file, find any internal function call (like error_reporting) and press K while the cursor is over it
2. On the manual page find a reference to any other function (like ini_set(3)) and press C-], the man page for that function will get loaded
3. Press C-t to get back to previous man page

What is the expected output? What do you see instead?
Expected: &syntax has "man" as its value
Actual: &syntax has "pman" as its value

Workaround: commenting out the following line: https://code.google.com/p/vim-plugin-viewdoc/source/browse/plugin/viewdoc.vim#&nbsp;180 fixes the problem.

Original issue 6 created by powerman on 2012-02-08T13:48:02.000Z:

vim help files in Fedora rpm are zipped into a single file /usr/share/vim/vim73/doc/helphelp.txt.gz. In this case simple 'cat' in g:ViewDoc_help() does not properly work. Simple fix is to use:

    if helpfile =~? 'gz$'
        let h.cmd   = printf('zcat %s', shellescape(helpfile,1))
    else
        let h.cmd   = printf('cat %s', shellescape(helpfile,1))
    endif

instead

    let h.cmd   = printf('cat %s', shellescape(helpfile,0))

in g:ViewDoc_help()

Original issue 16 created by powerman on 2013-08-10T07:44:45.000Z:

I'm very used to call help with the ":h" abbreviation:

:h viewdoc

Unfortunately this will not use the viewdoc plugin. So i end up in an ordinary Vim help window.

Is it possible to make this work somehow?

Original issue 5 created by powerman on 2012-01-22T12:41:04.000Z:

Hi.

Subj.

Original issue 10 created by powerman on 2012-09-10T00:31:42.000Z:

pydoc3 dbus 's result is different with pydoc dbus.
Please give out an option (like let g:viewdoc_pydoc_version = 2 / 3) to let user select which pydoc version to checkout.

Original issue 4 created by powerman on 2012-01-20T17:48:51.000Z:

I have at least one of them: my own implementation of “autochdir” which makes ViewDocHelp always complain about not found topic.

Solution: use “:noautocmd”.

Original issue 26 created by powerman on 2014-05-15T14:52:04.000Z:

This change here has introduced a problem for me:

https://code.google.com/p/vim-plugin-viewdoc/source/detail?r=d087ffa3b3b84fd4ce686c4dc65efe9b5f73d745

I've used a setup as described here:

http://stackoverflow.com/questions/17670134/how-to-use-both-pman-and-custom-help-files-in-vim-with-the-viewdoc-plugin#answer-17843349

So in my vimrc I have this:

" viewdoc
let g:viewdoc_open = 'new'
let g:viewdoc_openempty = 0
" Custom help handler that tries Yii help and PHP help, in this order.
function ViewDoc_pman_custom(topic, filetype, synid, ctx)
let l:tagpath = '/etc/vim/bundle/yii-api-vim/doc/tags'
let l:shell = printf('grep %s %s', shellescape(a:topic,1), l:tagpath)
let l:output = system(l:shell)

if !v:shell_error
return g:ViewDoc_help(a:topic, a:filetype, a:synid, a:ctx)
else
let l:ViewDoc_pman_old = function('ViewDoc_pman')
return l:ViewDoc_pman_old(a:topic, a:filetype, a:synid, a:ctx)
endif
endfunction
autocmd VimEnter * let g:ViewDoc_pman = function('ViewDoc_pman_custom')

autocmd VimEnter * let g:ViewDoc_php = function('ViewDoc_pman_custom')

This now gives me an error, that 'ViewDoc_pman' is not defined. I've also tried with 'g:ViewDoc_pman' but no success.

Original issue 1 created by powerman on 2012-01-20T17:02:33.000Z:

I guess you know why it is bad to depend on user setup, especially on that part of it. Attached patch should fix the issue.

Some plugins, such as easymotion, use <Plug> to map to commands, and then the user can map any key to such <Plug>.

For instance, in case o easymotion, I can write this on my .vimrc:

map s <Plug>(easymotion-prefix)
map sa <Plug>(easymotion-jumptoanywhere)
map sl <Plug>(easymotion-bd-jk)
map sn <Plug>(easymotion-bd-n)
map sN <Plug>(easymotion-bd-n)
map s. <Plug>(easymotion-repeat)
map s, <Plug>(easymotion-next)
map s; <Plug>(easymotion-prev)

I wish I could do the same for viewdoc. But I can't, unless I copy a very large and convoluted piece of code inside my .vimrc.

I have not tried this code, but I expected something like this:

if g:viewdoc_copy_to_search_reg
    inoremap <silent><Plug>(viewdoc-new) <C-O>:let @/ = '\<'.expand('<cword>').'\>'<CR><C-O>:call ViewDoc('new', '<cword>')<CR>
    nnoremap <silent><Plug>(viewdoc-new)      :let @/ = '\<'.expand('<cword>').'\>'<CR>:call ViewDoc('new', '<cword>')<CR>
    nnoremap <silent><Plug>(viewdoc-doc)      :let @/ = '\<'.expand('<cword>').'\>'<CR>:call ViewDoc('doc', '<cword>')<CR>
else
    inoremap <silent><Plug>(viewdoc-new) <C-O>:call ViewDoc('new', '<cword>')<CR>
    nnoremap <silent><Plug>(viewdoc-new)      :call ViewDoc('new', '<cword>')<CR>
    nnoremap <silent><Plug>(viewdoc-doc)      :call ViewDoc('doc', '<cword>')<CR>
endif
if !exists('g:no_plugin_maps') && !exists('g:no_viewdoc_maps')
    inoremap <F1> <Plug>(viewdoc-new)
    nnoremap <F1> <Plug>(viewdoc-new)
    nnoremap K    <Plug>(viewdoc-doc)
endif

Can you please experiment with this and see if this works? I wish to use viewdoc, but I want to change the default mappings.

In your readme you list that I can use this for my manpager but I have been unable to locate instructions on how to do so using :ViewDocHelp viewdoc

I have done the following export
export MANPAGER="/bin/sh -c "col -b | nvim -c 'set ft=man ts=8 nomod nolist nonu noma' -""
which when I enter man into my terminal does launch nvim into man page, it does not appear to be using viewdoc to read the man file. Do you have any suggestions on how to do so? Is it already mentioned in the help documentation?

Been using this plugin for about two weeks and love it.

Although I could just use the bang variations of the commands, e.g. :h! foo to open documentation in an already existing help window, I think users are used to :h foo opening in a dedicated buffer by default. That is, instead of opening in another "DocN" buffer, there would only be one "Doc" buffer.

I request that a setting be provided that makes the commands open in a dedicated buffer as expected. Yes, I could just get used to :h! foo, but that's one more keystroke than usual.

Original issue 7 created by powerman on 2012-05-20T08:50:57.000Z:

In python, viewdoc can not access help for module's function. like bellowing:

import random
x = random.randin|t(1, 6)

my cursor is at "|", I press "K", viewdoc can not access python's help doc.

but I can access it with command:
$ pydoc random.randint

Steps to reproduce:

1. Execute :ViewDocInfo (without args)
2. Find psktool under System Administration section
3. Press enter.

In my system, it wasn't able to find that page, which is fine (GNU Info wasn't able to either -- simply opens its man page instead).

But now, my Vim (also Neovim) performance gets bad. Pressing j and k keys have a noticeable lag (50-100ms maybe).

If I execute :ViewDocInfo again, everything gets back to normal.

This strange phenomena might even be a vim-bug!

Update: Even executing :ViewDocHelp or :ViewDocMan man can get everything back to normal. I guess anything ViewDoc related will do... (Opening a random file has no effect)

first of all: thank you for all your work on viewdoc!

I have a super minor issue with displaying pydocs using viewdoc:
is there any option to preserve the function name highlighting from pydoc?
below is the comparison between viewdoc vim output / pydoc terminal output

would that involve creating a new syntax file? or maybe just modifying plugin/viewdoc_pydoc.vim?

I get the following error message when I try to launch vim or neovim on macOS with this plugin enabled:

Error detected while processing /Users/amanmehra/.vim/plugged/vim-plugin-viewdoc/plugin/viewdoc.vim:
line   60:
E227: mapping already exists for <80>k1
Press ENTER or type command to continue

Also, pressing just q does not exit the help page, I need to press one more key after that for it to exit the help page.

Original issue 2 created by powerman on 2012-01-20T17:07:27.000Z:

I think it is much better if you do like

:help some-unknown-tag

does: display the error, but do not open anything. Closing empty tab back is annoying.

Original issue 8 created by powerman on 2012-05-20T12:09:25.000Z:

Use viewdoc open a window to view help.
Then I press "K" on another topic, viewdoc will open a new window. I hope viewdoc can have option for this whether override previous window.