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

bug?: same file loaded multiple times

Expand Messages
  • Graham, Scott
    I normally do :find file.c to open a file, and have the root of my C project added to path. This works fine, and Vim loads a file like: d: proj ps2 src file.c
    Message 1 of 4 , Nov 30, 2000
      I normally do :find file.c to open a file, and have the root of my C project
      added to path. This works fine, and Vim loads a file like:
      d:\proj\ps2\src\file.c
      But, now, if I do a :grep and the output in the :cwindow looks like
      \proj\ps2\src\file.c|100|: blah
      and I hit tab on that line, I get a second buffer with the same file, but a
      different copy. Now when I move between them I get "warning: buffer
      changed", and I lose changes if I load/save the wrong one.

      In general usage, this doesn't happen I don't think and a buffer normally
      maps directly to a disk file.

      Using vim60l still.. I don't think this was fixed in M or N though (?).


      Also, regarding :cwindow, is it possible to have it be "reparsed" (or
      something) after the BufReadPost?

      If I do something like:
      autocmd BufReadPost quickfix :g/Binary\ file.*matches/:.d
      to delete binary file matches (or similarly to remove hits in 'tags', or
      ...)

      Now, when I tab on those lines, Vim jumps to what _was_ on that line before,
      not what's listed now.


      scott
    • Bram Moolenaar
      ... I can guess that you are using the Win32 version. A different copy of the same file? That shouldn t happen. Please use 1 CTRL-G to find out what long
      Message 2 of 4 , Dec 1, 2000
        Scott Graham wrote:

        > I normally do :find file.c to open a file, and have the root of my C project
        > added to path. This works fine, and Vim loads a file like:
        > d:\proj\ps2\src\file.c
        > But, now, if I do a :grep and the output in the :cwindow looks like
        > \proj\ps2\src\file.c|100|: blah
        > and I hit tab on that line, I get a second buffer with the same file, but a
        > different copy. Now when I move between them I get "warning: buffer
        > changed", and I lose changes if I load/save the wrong one.

        I can guess that you are using the Win32 version.

        A different copy of the same file? That shouldn't happen. Please use
        1 CTRL-G to find out what long name is used for the buffer. I suspect them to
        be different. Perhaps it's the difference between "d:\proj" and "\proj"?

        I can't find a "buffer changed" message in Vim. What is the literal text of
        the message? Do you have 'autowrite' set perhaps?

        > Using vim60l still.. I don't think this was fixed in M or N though (?).

        Probably not.

        > Also, regarding :cwindow, is it possible to have it be "reparsed" (or
        > something) after the BufReadPost?

        You can write it to a file and use ":cfile" to have it handled like an error
        file. Note that the text in the window doesn't really matter, the line number
        is used as the error number.

        > If I do something like:
        > autocmd BufReadPost quickfix :g/Binary\ file.*matches/:.d
        > to delete binary file matches (or similarly to remove hits in 'tags', or
        > ...)
        >
        > Now, when I tab on those lines, Vim jumps to what _was_ on that line before,
        > not what's listed now.

        Right. That doesn't work. Vim remembers more information about an error than
        what's displayed in the quickfix window. Thus it's not possible to change the
        errors by editing the text in the window.

        I can understand that you would want to change the error list by editing the
        quickfix window. But I don't see how this would work. Perhaps it would be
        possible to make a line empty and then issuing a command to delete it from the
        error list.

        --
        A computer programmer is a device for turning requirements into
        undocumented features. It runs on cola, pizza and Dilbert cartoons.
        Bram Moolenaar

        /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
        \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
      • Graham, Scott
        ... Right, I forgot that... ... They are in fact the same physical file, if that s what you mean. Normally, no matter how a file is opened I end up with only
        Message 3 of 4 , Dec 1, 2000
          > Scott Graham wrote:
          >
          > > I normally do :find file.c to open a file, and have the
          > root of my C project
          > > added to path. This works fine, and Vim loads a file like:
          > > d:\proj\ps2\src\file.c
          > > But, now, if I do a :grep and the output in the :cwindow looks like
          > > \proj\ps2\src\file.c|100|: blah
          > > and I hit tab on that line, I get a second buffer with the
          > same file, but a
          > > different copy. Now when I move between them I get "warning: buffer
          > > changed", and I lose changes if I load/save the wrong one.
          >
          > I can guess that you are using the Win32 version.

          Right, I forgot that...

          > A different copy of the same file? That shouldn't happen. Please use
          > 1 CTRL-G to find out what long name is used for the buffer.

          They are in fact the same physical file, if that's what you mean. Normally,
          no matter how a file is opened I end up with only one buffer.

          1^G on one buffer gives me: "D:\fifa\ps2\src\rm\rmplyr.c"
          1^G on the other gives me: "\fifa\ps2\src\rm\rmplyr.c"

          But the second one is in fact on D:.. It looks like this needs to resolve
          more "fully"?

          Sorry, the actual text was the "Warning: <filename> has changed since
          editing started" message, presumably because the file /has/ actually
          changed, it's just that vim is confused because there's two buffers
          corresponding to the same file because of the full path not being resolved
          to the same file.


          > I can understand that you would want to change the error list
          > by editing the
          > quickfix window. But I don't see how this would work.

          Does that information really need to be stored? I used to use a similar
          thing implemented in macros/script functions that just did the equivalent of
          'gf'. Are there cases for the error window where that information is too
          slow to parse out when the actual jump is requested?

          In any case, it's not important, save and :cfile is a fine solution to the
          problem (though maybe a note to that effect in the docs?)

          scott
        • Bram Moolenaar
          ... It seems the function that compares file names isn t working properly. I ll look into that. ... It s not a matter of speed. What you see in the quickfix
          Message 4 of 4 , Dec 2, 2000
            Scott Graham wrote:

            > They are in fact the same physical file, if that's what you mean. Normally,
            > no matter how a file is opened I end up with only one buffer.
            >
            > 1^G on one buffer gives me: "D:\fifa\ps2\src\rm\rmplyr.c"
            > 1^G on the other gives me: "\fifa\ps2\src\rm\rmplyr.c"
            >
            > But the second one is in fact on D:.. It looks like this needs to resolve
            > more "fully"?

            It seems the function that compares file names isn't working properly. I'll
            look into that.

            > > I can understand that you would want to change the error list
            > > by editing the quickfix window. But I don't see how this would work.
            >
            > Does that information really need to be stored? I used to use a similar
            > thing implemented in macros/script functions that just did the equivalent of
            > 'gf'. Are there cases for the error window where that information is too
            > slow to parse out when the actual jump is requested?

            It's not a matter of speed. What you see in the quickfix window is only part
            of the information. The column number isn't there, for example. Also, after
            jumping to an error, if you use ":cn", should it use the error list or the
            contents of the quickfix window? To keep this consistent I insist on keeping
            the contents of the quickfix window equal to the error list.

            > In any case, it's not important, save and :cfile is a fine solution to the
            > problem (though maybe a note to that effect in the docs?)

            I'll add a remark to the docs.

            --
            ARTHUR: I command you as King of the Britons to stand aside!
            BLACK KNIGHT: I move for no man.
            The Quest for the Holy Grail (Monty Python)

            /// Bram Moolenaar Bram@... http://www.moolenaar.net \\\
            \\\ Vim: http://www.vim.org ICCF Holland: http://iccf-holland.org ///
          Your message has been successfully submitted and would be delivered to recipients shortly.