Loading ...
Sorry, an error occurred while loading the content.

Re: [PATCH] fix man page viewing with man-db

Expand Messages
  • Matt Wozniski
    ... Shouldn t that be ctrl-] ? -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to.
    Message 1 of 9 , Dec 2, 2010
    • 0 Attachment
      2010/11/29 Bram Moolenaar <Bram@...>:
      >
      > Pádraig wrote:
      >>     "Ensure vim is not recursively invoked (man-db does this)
      >>     "when doing ctrl-[ on a man page reference

      Shouldn't that be ctrl-] ?

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • MikeM
      This patch causes /usr/bin/man to fail on Mac OS X: sh: -c: line 0: syntax error near unexpected token `|| sh: -c: line 0: `(cd /usr/share/man && (echo .ll
      Message 2 of 9 , Feb 2, 2011
      • 0 Attachment
        This patch causes /usr/bin/man to fail on Mac OS X:

        sh: -c: line 0: syntax error near unexpected token `||'
        sh: -c: line 0: `(cd '/usr/share/man' && (echo ".ll 13.0i"; echo ".nr LL 13.0i"; /usr/bin/gunzip -c '/usr/share/man/man1/man.1.gz') | /usr/bin/tbl | /usr/bin/groff -Wall -mtty-char -Tascii -mandoc -c | ( || true))'
        Error executing formatting or display command.
        System command (cd '/usr/share/man' && (echo ".ll 13.0i"; echo ".nr LL 13.0i"; /usr/bin/gunzip -c '/usr/share/man/man1/man.1.gz') | /usr/bin/tbl | /usr/bin/groff -Wall -mtty-char -Tascii -mandoc -c | ( || true)) exited with status 512.
        No manual entry for man

        It would appear that because MANPAGER has been set to null, null is substituted in the actual command that /usr/bin/man runs (just before the '||'). Please can a more comprehensive solution be found. Unfortunately vim does not appear to allow the removal of a variable from the environment altogether, only adding or setting one.


        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • MikeM
        It s been a while since I reported a problem with the patch here and no further comment has been made. I guess the majority of users out there are probably
        Message 3 of 9 , Jul 24, 2011
        • 0 Attachment
          It's been a while since I reported a problem with the patch here and no further comment has been made. I guess the majority of users out there are probably using one of the pre-packaged versions of vim 7.3 and so this problem hasn't come down the pipeline to hit them yet. I have seen one other reference to the problem whilst browsing the web: http://crumbtrail.chesmart.in/

          I still don't think the original patch was the right solution here, but until someone comes up with a better solution, I wonder if the the following patch could be applied?

          --- a/ftplugin/man.vim 2011-07-22 19:55:14.000000000 +0100
          +++ b/ftplugin/man.vim 2011-07-24 17:55:49.000000000 +0100
          @@ -17,7 +17,9 @@
           
             " Ensure Vim is not recursively invoked (man-db does this)
             " when doing ctrl-[ on a man page reference.
          -  let $MANPAGER = ""
          +  if exists("$MANPAGER")
          +    let $MANPAGER = ""
          +  endif
           
             " allow dot and dash in manual page name.
             setlocal iskeyword+=\.,-

          This patch maintains the fix for the original problem, but limits the potential side effects to those that have a MANPAGER environment variable actually defined.  

          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • SungHyun Nam
          ... I have no objection to this patch. so, Ack. BTW, I m not sure man.vim should include such lines at all. Original reporter already found a workaround for
          Message 4 of 9 , Jul 24, 2011
          • 0 Attachment
            MikeM wrote:
            > It's been a while since I reported a problem with the patch here and no
            > further comment has been made. I guess the majority of users out there
            > are probably using one of the pre-packaged versions of vim 7.3 and so
            > this problem hasn't come down the pipeline to hit them yet. I have seen
            > one other reference to the problem whilst browsing the web:
            > http://crumbtrail.chesmart.in/
            >
            > I still don't think the original patch was the right solution here, but
            > until someone comes up with a better solution, I wonder if the the
            > following patch could be applied?
            >
            > --- a/ftplugin/man.vim2011-07-22 19:55:14.000000000 +0100
            > +++ b/ftplugin/man.vim2011-07-24 17:55:49.000000000 +0100
            > @@ -17,7 +17,9 @@
            > " Ensure Vim is not recursively invoked (man-db does this)
            > " when doing ctrl-[ on a man page reference.
            > - let $MANPAGER = ""
            > + if exists("$MANPAGER")
            > + let $MANPAGER = ""
            > + endif
            > " allow dot and dash in manual page name.
            > setlocal iskeyword+=\.,-
            >
            > This patch maintains the fix for the original problem, but limits the
            > potential side effects to those that have a MANPAGER environment
            > variable actually defined.

            I have no objection to this patch. so, Ack.

            BTW, I'm not sure man.vim should include such lines at all. Original
            reporter already found a workaround for his problem. And his patch
            caused side-effect for others.

            Regards,
            namsh

            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • Bram Moolenaar
            ... Thanks. Since SungHyun Nam agreed I ll include this. -- MORTICIAN: What? CUSTOMER: Nothing -- here s your nine pence. DEAD PERSON: I m not dead!
            Message 5 of 9 , Jul 25, 2011
            • 0 Attachment
              Mike Mcewan wrote:

              > It's been a while since I reported a problem with the patch here and no
              > further comment has been made. I guess the majority of users out there are
              > probably using one of the pre-packaged versions of vim 7.3 and so this
              > problem hasn't come down the pipeline to hit them yet. I have seen one other
              > reference to the problem whilst browsing the web:
              > http://crumbtrail.chesmart.in/
              >
              > I still don't think the original patch was the right solution here, but
              > until someone comes up with a better solution, I wonder if the the following
              > patch could be applied?
              >
              > --- a/ftplugin/man.vim 2011-07-22 19:55:14.000000000 +0100
              > +++ b/ftplugin/man.vim 2011-07-24 17:55:49.000000000 +0100
              > @@ -17,7 +17,9 @@
              >
              > " Ensure Vim is not recursively invoked (man-db does this)
              > " when doing ctrl-[ on a man page reference.
              > - let $MANPAGER = ""
              > + if exists("$MANPAGER")
              > + let $MANPAGER = ""
              > + endif
              >
              > " allow dot and dash in manual page name.
              > setlocal iskeyword+=\.,-
              >
              > This patch maintains the fix for the original problem, but limits the
              > potential side effects to those that have a MANPAGER environment variable
              > actually defined.

              Thanks. Since SungHyun Nam agreed I'll include this.

              --
              MORTICIAN: What?
              CUSTOMER: Nothing -- here's your nine pence.
              DEAD PERSON: I'm not dead!
              MORTICIAN: Here -- he says he's not dead!
              CUSTOMER: Yes, he is.
              DEAD PERSON: I'm not!
              The Quest for the Holy Grail (Monty Python)

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Elias Toivanen
              Hello, I ve also experienced man.vim crashing when $MANPAGER had been already defined to `col -b | vim -R - in .bashrc. I took a look at the man.vim file and
              Message 6 of 9 , Jul 25, 2011
              • 0 Attachment
                Hello,

                I've also experienced man.vim crashing when $MANPAGER had been already
                defined to `col -b | vim -R -' in .bashrc. I took a look at the man.vim
                file and came up with the following idea.

                Instead of asking if $MANPAGER was defined, why not define it
                temporarily for the call. It's possible to do this via

                let tmp = tempname()
                let $MANWIDTH = &tw ? &tw : 80
                let manpager = shellescape('less -s') " Fixes problems when user has defined $MANPAGER
                silent execute "!MANPAGER=".manpager." /usr/bin/man ".args."| col -b > ".tmp
                silent execute "pedit ".tmp

                See the attachment for the complete reimplementation of GetPage(). I
                also wanted to fix a couple of subtle shortcomings of the original script.

                In my opinion, viewing man pages should mimic reading help pages which
                is already reflected nicely in the mappings <C-]> and <C-t>. However, it
                would also be nice to be able to double click the topics as one can do
                in help files.

                Man pages should also be closed when the last writable buffer is closed
                in the current tab page, as is the case with help files. Now the user is
                potentially left with two windows to the same shell script. The first
                was used to spawn a man page via <Leader>K for example and the second
                appeared unintentionally when the user rewinded man pages one time too
                many.

                Finally, all man pages shouldn't be only 'readonly' but also
                'nomodifiable'.

                All of these aspects are taken care of in the script you'll find in the
                attachment. I post it to your consideration.


                On Mon, 25 Jul 2011, Bram Moolenaar wrote:

                >
                > Mike Mcewan wrote:
                >
                >> It's been a while since I reported a problem with the patch here and no
                >> further comment has been made. I guess the majority of users out there are
                >> probably using one of the pre-packaged versions of vim 7.3 and so this
                >> problem hasn't come down the pipeline to hit them yet. I have seen one other
                >> reference to the problem whilst browsing the web:
                >> http://crumbtrail.chesmart.in/
                >>
                >> I still don't think the original patch was the right solution here, but
                >> until someone comes up with a better solution, I wonder if the the following
                >> patch could be applied?
                >>
                >> --- a/ftplugin/man.vim 2011-07-22 19:55:14.000000000 +0100
                >> +++ b/ftplugin/man.vim 2011-07-24 17:55:49.000000000 +0100
                >> @@ -17,7 +17,9 @@
                >>
                >> " Ensure Vim is not recursively invoked (man-db does this)
                >> " when doing ctrl-[ on a man page reference.
                >> - let $MANPAGER = ""
                >> + if exists("$MANPAGER")
                >> + let $MANPAGER = ""
                >> + endif
                >>
                >> " allow dot and dash in manual page name.
                >> setlocal iskeyword+=\.,-

                --
                Elias Toivanen <elias.toivanen@...>

                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • James Vega
                ... Using !env MANPAGER=.... is better as not all shells support declaring environment variables to use for a command invocation like that. -- James GPG Key:
                Message 7 of 9 , Jul 25, 2011
                • 0 Attachment
                  On Mon, Jul 25, 2011 at 11:50:39PM +0300, Elias Toivanen wrote:
                  > Hello,
                  >
                  > I've also experienced man.vim crashing when $MANPAGER had been already
                  > defined to `col -b | vim -R -' in .bashrc. I took a look at the man.vim
                  > file and came up with the following idea.
                  >
                  > Instead of asking if $MANPAGER was defined, why not define it
                  > temporarily for the call. It's possible to do this via
                  >
                  > let tmp = tempname()
                  > let $MANWIDTH = &tw ? &tw : 80
                  > let manpager = shellescape('less -s') " Fixes problems when user has defined $MANPAGER
                  > silent execute "!MANPAGER=".manpager." /usr/bin/man ".args."| col -b > ".tmp

                  Using "!env MANPAGER=...." is better as not all shells support declaring
                  environment variables to use for a command invocation like that.

                  --
                  James
                  GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                Your message has been successfully submitted and would be delivered to recipients shortly.