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

Help! how to check viminfo for errors?

Expand Messages
  • howard Schwartz
    I know my pleas are getting old for you veterans. But I am trying to make .viminfo work for a blind friend, and he keeps getting more and more errors. I ve
    Message 1 of 7 , Feb 26, 2011
    • 0 Attachment
      I know my pleas are getting old for you veterans. But I am trying to make
      .viminfo work for a blind friend, and he keeps getting more and more errors.

      I've scoured both the usual and unusual documentation, the scripts library,
      the web, and vim_use archives - and still can not find certain basic
      information about the .viminfo file, and how different versions of vim
      interact with it. The usual advice is to delete the file, losing all one's
      mark info., if it corrupts.

      Most error messages seem to be spawned by vim making a simple format error
      when writing this file. For example, an initial > ls left out of a line that
      specifies a new filname and path. Or, a tab is missing in setting a mark,
      i.e., there is a line like this

      z^I13^I2

      instead of,

      ^Iz^I13^I2

      When I manually edit each wrong viminfo line, the error messages disappear.
      Has anyone written a description of the required format for this file? Is
      there some script that can check the file for format errors and/or fix them?

      Apparently, vim does not dynamically check much for the current state of a
      file when it updates (overwrites) viminfo.


      --
      You received this message from the "vim_use" 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
    • Hugh Sasse
      ... Only rejoined the list recently, but searching doesn t show up any replies to your messages about this. ... Increasing? This seems a bit odd. My first
      Message 2 of 7 , Feb 26, 2011
      • 0 Attachment
        On Sat, 26 Feb 2011, howard Schwartz wrote:

        > I know my pleas are getting old for you veterans. But I am trying to make

        Only rejoined the list recently, but searching doesn't show up any replies
        to your messages about this.

        > .viminfo work for a blind friend, and he keeps getting more and more errors.

        Increasing? This seems a bit odd. My first thought would be whether
        the media he is writing to is beginning to die.
        >
        > I've scoured both the usual and unusual documentation, the scripts library,
        > the web, and vim_use archives - and still can not find certain basic
        > information about the .viminfo file, and how different versions of vim
        > interact with it. The usual advice is to delete the file, losing all one's
        > mark info., if it corrupts.

        Agrees with my searches as well. It may be something for which you'd need
        to read the source, but before we get to that....
        >
        > Most error messages seem to be spawned by vim making a simple format error
        > when writing this file. For example, an initial > ls left out of a line that

        I'm thinking that 'ls' should be 'is' there...

        > specifies a new filname and path. Or, a tab is missing in setting a mark,

        For the first case, the user may be prepared to add f0 to the viminfo option
        and suppress saving of filenames, but that's an annoying work around.

        > i.e., there is a line like this
        >
        > z^I13^I2
        >
        > instead of,
        >
        > ^Iz^I13^I2

        I was going to suggest the c flag, in order to fix encoding issues, but
        missing out a tab is unlikely to be that. Also encoding issues I think
        would only come up if the user is editing something like raw Braille,
        stored however that is. I've seen people post that to blindness lists
        in the past, and it looks rather odd. I could imagine Vim treating it
        as a different encoding.
        >
        > When I manually edit each wrong viminfo line, the error messages disappear.
        > Has anyone written a description of the required format for this file? Is
        > there some script that can check the file for format errors and/or fix them?
        >
        > Apparently, vim does not dynamically check much for the current state of a
        > file when it updates (overwrites) viminfo.

        What I saw in the docs says it attempts to merge the file, which may explain
        accumulation of errors, unless you mean that there are more errors despite
        your corrections.

        The user isn't using some kind of removable media, which is being removed
        too early? The r flag would prevent viminfo being written if that were
        the case.

        Hugh

        --
        You received this message from the "vim_use" 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
      • howard Schwartz
        ... Bad or portable media is not the culpret. My friend logs into a powerful networked computer system at Univesity of New York at Buffalo, where he is a
        Message 3 of 7 , Feb 27, 2011
        • 0 Attachment
          Hugh Sasse <hgs@...> Feb 27 01:26AM wrote:

          > My first thought would be whether the media he is writing to is beginning to
          > die.

          > The user isn't using some kind of removable media, which is being removed
          > too early?

          Bad or portable media is not the culpret. My friend logs into a powerful
          networked computer system at Univesity of New York at Buffalo, where he is a
          prefessor Emeritus. Vim is run on the Buffalo computers. True, he still uses
          dos, an ancient IBM PC monitor, and a dialup modem to log in. Buffalo sets his
          term to vt102, and keystrokes seem to be interpreted correctly by the Buffalo
          computer.

          > It may be something for which you'd need to read the source, but before we
          > get to that.

          There is a syntax highlight file, viminfo.vim which highlights lines in error.
          It does this by simply checking for all types of lines that are OK. There is
          no checking for which lines should go where, nor any coordination with the
          actual error messages in the code.

          > the user may be prepared to add f0 to the viminfo option
          > and suppress saving of filenames, but that's an annoying work around.

          Unfortunately, the only thing, so far, my blind friend likes about viminfo, it
          the ability to save persistent (lowercase) marks in files, between sessions.

          > also encoding issues I think would only come up if the user is editing
          > something like raw Braille.

          Encoding is not the problem. term is set to utf-8, and he edits only pure
          ascii text, containing the old-style troff, ascii markup codes (e.g., .ce,
          \fB etc.).

          > What I saw in the docs says it attempts to merge the file,

          The docs are not specific, but: When vim writes to viminfo it seems to add new
          info. if it is not there (e.g., marks for a new filename, jumplist for a new
          filename), and overwrite mark information for the A-Z and a-z marks, if the
          user has changed these marks. It does not update any other old information.
          For instance, the jumplist lines for a file previously edited, stay there
          forever - until .viminfo is deleted. If not changed, alphbetic marks for old
          files also stay forever.

          I know of no vim aware scripts that update viminfo, when a file is renamed,
          deleted or moved.

          It is not clear if vim counts `+' lines of the jumplist towards the limits set
          for marks. Too bad if it does, since there are often hundreds of jump lines!

          > you mean that there are more errors despite your corrections.

          Yes, I manually correct the viminfo file, and within days or hours another
          format error occurs, within a line of viminfo. My friend also reports that
          line numbers for named marks are not correctly set, as he edits. Somehow, vim
          is writing bad lines to viminfo, when my friend quits vim.

          One possibility: my friend has the (bad) habit of using unix to switch between
          edited files. That is, he runs many instances of vim, suspending one with
          Ctrl-Z to leave one file, and using the shell's jobs and fg command to enter
          another file, by bring a suspended vim back to life in the foreground.

          Off hand I do not see how this would confuse viminfo writes, although running
          many instances like these in a console is asking for trouble.

          --
          You received this message from the "vim_use" 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
        • Ben Schmidt
          ... I think this is what is baffling us. I m not sure anyone else has experienced or reported such a problem. Our viminfo files are written and read just fine
          Message 4 of 7 , Feb 27, 2011
          • 0 Attachment
            > Yes, I manually correct the viminfo file, and within days or hours
            > another format error occurs, within a line of viminfo. My friend also
            > reports that line numbers for named marks are not correctly set, as he
            > edits. Somehow, vim is writing bad lines to viminfo, when my friend
            > quits vim.

            I think this is what is baffling us. I'm not sure anyone else has
            experienced or reported such a problem. Our viminfo files are written
            and read just fine unless we experience something like a hardware
            failure.

            I wonder if it's something to do with how Vim is quit if/when the modem
            hangs up (e.g. if it hangs up unexpectedly). Maybe vim is signalled to
            quit, starts writing viminfo, and then is killed before it finishes.
            That might explain it.

            If we had a better idea what was causing the problem, we'd be in a much
            better position to solve it.

            What version of Vim is running? I suppose you're not in a position to
            run a different version, either?

            > One possibility: my friend has the (bad) habit of using unix to switch
            > between edited files. That is, he runs many instances of vim,
            > suspending one with Ctrl-Z to leave one file, and using the shell's
            > jobs and fg command to enter another file, by bring a suspended vim
            > back to life in the foreground.

            I don't think this would be the problem. I do that kind of thing all the
            time, too. Vim is meant to work in situations like that.

            Ben.



            --
            You received this message from the "vim_use" 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
          • Benjamin R. Haskell
            ... Sorry, didn t see this email before I responded to your other question. In the case of trying to fix .viminfo corruption, direct examination or
            Message 5 of 7 , Feb 27, 2011
            • 0 Attachment
              On Sat, 26 Feb 2011, howard Schwartz wrote:

              > I know my pleas are getting old for you veterans. But I am trying to
              > make .viminfo work for a blind friend, and he keeps getting more and
              > more errors.
              >
              > I've scoured both the usual and unusual documentation, the scripts
              > library, the web, and vim_use archives - and still can not find
              > certain basic information about the .viminfo file, and how different
              > versions of vim interact with it. The usual advice is to delete the
              > file, losing all one's mark info., if it corrupts.

              Sorry, didn't see this email before I responded to your other question.

              In the case of trying to fix .viminfo corruption, direct examination or
              modification of the file probably makes sense.


              > Most error messages seem to be spawned by vim making a simple format
              > error when writing this file. For example, an initial > ls left out of
              > a line that specifies a new filname and path. Or, a tab is missing in
              > setting a mark, i.e., there is a line like this
              >
              > z^I13^I2
              >
              > instead of,
              >
              > ^Iz^I13^I2
              >

              If it's really necessary to share the .viminfo file between different
              versions of Vim, I'm not sure what your best approach would be.

              If the synchronization of the file isn't important though, you could at
              least avoid the different-version corruption (if indeed that's what's
              happening) by specifying the .viminfo file on Vim invocation.

              E.g. on a system with Vim 7+, use something like:

              alias vim='vim -i /path/to/viminfo-for-vim7'

              On a system with a different Vim:

              alias vim='vim -i /path/to/viminfo-for-vim6'
              (assuming Vim 6 supports '-i', or just use the default location for the
              lowest version)

              Sorry to not have a better solution.

              --
              Best,
              Ben

              --
              You received this message from the "vim_use" 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
            • howard Schwartz
              ... Currently he is running vim 6.4 on a SunOS 5.9 machine. I tried the sunfreeware binary for vim 7.3, solaris 7 -- on his machine, but this version of vim
              Message 6 of 7 , Feb 28, 2011
              • 0 Attachment
                > What version of Vim is running? I suppose you're not in a position to
                > run a different version, either?

                Currently he is running vim 6.4 on a SunOS 5.9 machine. I tried the
                sunfreeware binary for vim 7.3, solaris 7 -- on his machine, but this version
                of vim seemed to have problems drawing the screen and understanding termimfo.

                > If it's really necessary to share the .viminfo file between different
                > versions of Vim, I'm not sure what your best approach would be.

                There is no need for this. What is needed is sharing viminfo between different
                instances of vim. That is, he has 3 or 4 instances of vim running
                simultaneously. Usually, one is actively running in the foreground and the
                others are suspended processes.

                Does my friend quit vim when quickly logging out of his remote connection? -
                No he does not. He does use perhaps 100 maps and abbreviations in vim that he
                is wedded to, and uses them to quit vim as well. I should examine these more
                closely to see if there is some strangness about them.

                --
                You received this message from the "vim_use" 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
              • Ben Schmidt
                ... Vim 6.4 is pretty ancient. The bug may well have been fixed, though I can t quickly spot a patch that addresses it. I haven t heard it reported for more
                Message 7 of 7 , Mar 2, 2011
                • 0 Attachment
                  >> What version of Vim is running? I suppose you're not in a position to
                  >> run a different version, either?
                  >
                  > Currently he is running vim 6.4 on a SunOS 5.9 machine. I tried the
                  > sunfreeware binary for vim 7.3, solaris 7 -- on his machine, but this
                  > version of vim seemed to have problems drawing the screen and
                  > understanding termimfo.

                  Vim 6.4 is pretty ancient. The bug may well have been fixed, though I
                  can't quickly spot a patch that addresses it. I haven't heard it
                  reported for more recent versions, though.

                  It's strange that Vim 7.3 isn't working well with the terminal. Maybe
                  $TERM is set wrongly or Vim is compiled to use the wrong ncurses or
                  terminfo library or something. I don't see any reason a more recent Vim
                  should work less well in this regard than an older one. It would surely
                  be better to get Vim 7.3 working than to struggle with an ancient
                  version.

                  > Does my friend quit vim when quickly logging out of his remote
                  > connection? - No he does not.

                  I didn't expect he would do it deliberately. I wondered if perhaps the
                  connection just dropped out from time to time though, and caused the
                  problem somehow.

                  Ben.

                  P.S. I don't know how you're writing your mails, but they keep appearing
                  as new threads, rather than replies to older messages, which makes the
                  conversation somewhat hard to follow. If you're able to reply to an
                  existing message in the conversation, it would be easier.

                  --
                  You received this message from the "vim_use" 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
                Your message has been successfully submitted and would be delivered to recipients shortly.