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

Re: Telling VIM not to create 'null' files...

Expand Messages
  • Tony Mechelynck
    ... :set backup is global: it is necessary if you want backups for existing files. If you don t want any backups you should use :set nobackup , and if you
    Message 1 of 16 , Sep 1, 2008
    • 0 Attachment
      On 01/09/08 22:44, Linda W wrote:
      > Tony Mechelynck wrote:
      >> set backup
      >> augroup noemptybak
      >> au! BufNewFile *
      >> \ if filereadable(expand("<afile>:p") . "~")
      >> \ | let delstatus = delete(expand("<afile>:p") . "~")
      >> \ | if delstatus
      >> \ | echomsg "Cannot remove" expand("<afile>:p") . "~, status"
      >> \ delstatus
      >> \ | endif
      >> \ | unlet delstatus
      >> \ | endif
      >> augroup END
      >
      > ---
      > Not to seem difficult, but isn't "set backup" a global option
      > and not buffer specific?
      >
      > If I have more than one file open at a time, as I do at times
      > wouldn't the global option be toggled off/on at buffer create time
      > get out of sync, with when the buffer is written out?
      >
      > Of course if 'set backup' only applies to the existing buffer,
      > then it likely wouldn't be a problem.
      >
      > tnx,
      > linda

      ":set backup" is global: it is necessary if you want backups for
      existing files. If you don't want any backups you should use ":set
      nobackup", and if you only want temporary backups which are written
      while saving the file but removed once the file is written successfully,
      then ":set nobackup writebackup".

      The autocommand, if it works (I didn't test it) removes a backup if one
      is found when creating a new file. If you _modify_ a preexisting file
      (even a zero-length one), a backup will still be created.


      Best regards,
      Tony.
      --
      I get up each morning, gather my wits.
      Pick up the paper, read the obits.
      If I'm not there I know I'm not dead.
      So I eat a good breakfast and go back to bed.

      Oh, how do I know my youth is all spent?
      My get-up-and-go has got-up-and-went.
      But in spite of it all, I'm able to grin,
      And think of the places my get-up has been.
      -- Pete Seeger

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • John Beckett
      ... Another (good) way of handling this is to put something like the following in your vimrc: set backupdir=/temp,c:/temp,. That example is for Windows and
      Message 2 of 16 , Sep 1, 2008
      • 0 Attachment
        Linda W wrote:
        > isn't "set backup" a global option and not buffer specific?

        Another (good) way of handling this is to put something like the following in your
        vimrc:

        set backupdir=/temp,c:/temp,.

        That example is for Windows and assumes that you have a writable /temp directory,
        and you don't mind anyone with access to that directory seeing your files. The
        forward slash works on Windows. The above tells Vim to put backup files in the \temp
        directory on the current drive, or failing that, in C:\temp, or failing that, the
        current directory.

        The fact that you put all backups go in one directory means that editing two files
        with the same name (in different directories) is going to mean that one backup
        overwrites the other.

        John


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_use" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Linda W
        ... Exactly -- so turning off the backup with an aucommand , like AG suggested ... Would turn off backups for the rest of the session -- so if you edited an
        Message 3 of 16 , Sep 8, 2008
        • 0 Attachment
          Tony Mechelynck wrote:
          > ":set backup" is global: it is necessary if you want backups for
          > existing files.
          ---
          Exactly -- so turning off the "backup" with an "aucommand", like AG suggested

          > Maybe with an autocommand? Something like:
          >
          > autocmd BufNewFile set nobackup
          ---
          Would turn off backups for the rest of the session -- so if you edited
          an existing file after you had created one, you wouldn't get a backup.
          > The autocommand, if it works (I didn't test it) removes a backup if one
          > is found when creating a new file. If you _modify_ a preexisting file
          > (even a zero-length one), a backup will still be created.
          ----
          Well that's sorta the "rub"...I'm not modifying a ***pre-existing*** file --
          I am creating a new file. I don't want an *empty* file created if there was
          no file that existed before. If there *is* an empty file "foo.c", THEN I would
          expect, "foo.c~", to be created as a backup. But if there IS no file "foo.c", then
          when I save "foo.c", it's a **BUG** to create a "foo.c~".

          Reasoning: foo.c~ shows the *file* as it existed before I edited it. So it
          should only be created if there really was a "foo.c" of zero length before I
          wrote to it. If there was no "foo.c" at all, then vim is mistakenly creating a
          "foo.c~" of zero length -- meaning that the previous "tree" had foo.c in it, and was
          of zero length.

          The current behavior leaves no way to discern if, prior to editing "foo.c",
          there
          really was no "foo.c" , or if there was a "foo.c" of zero length. Vim is creating
          a bogus "backup" "foo.c~" of zero length when no such file previously existed.
          That's my "rub". You can't create a backup when the file didn't exist in the
          first
          place. If you want to create a "notation" that foo.c is a "new" file, that's
          "different",
          but you have no way to discern, (now), if there was an empty "foo.c" before your
          edit, or if there was no "foo.c".

          Does that make sense? Vim is "over-loading" the meaning of "file~" to represent
          both, a pre-existing file of zero-len, AND, the the fact that the file didn't
          previously
          exist. That's not consistent with the concept of a *backup*... i.e. you can't
          backup
          a file that doesn't exist.




          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_use" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Ben Schmidt
          ... Yeah, I agree. The thing is, my Vim doesn t do this. So either some obscure set of Vim option settings, a strange behaviour of your system libraries, or a
          Message 4 of 16 , Sep 8, 2008
          • 0 Attachment
            > Well that's sorta the "rub"...I'm not modifying a ***pre-existing***
            > file -- I am creating a new file. I don't want an *empty* file
            > created if there was no file that existed before. If there *is* an
            > empty file "foo.c", THEN I would expect, "foo.c~", to be created as a
            > backup. But if there IS no file "foo.c", then when I save "foo.c",
            > it's a **BUG** to create a "foo.c~".

            Yeah, I agree.

            The thing is, my Vim doesn't do this.

            So either some obscure set of Vim option settings, a strange behaviour
            of your system libraries, or a bug in an autocommand or plugin is
            causing this.

            What system are you on? Can you show us your :set output (help :redir
            for how to capture it)? What about your :au output (perhaps do :filetype
            off before this one to remove a huge amount of filetype-related stuff
            which probably isn't relevant)? Does it happen for all files, or only
            files of a certain type (which would suggest a filetype-related
            autocommand *is* causing problems)?

            Ben.



            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_use" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Linda W
            ... set patchmode=.orig Are you saying if you set this, then it doesn t create a 0-byte patch file to indicate that the previous version (before you edited)
            Message 5 of 16 , Sep 9, 2008
            • 0 Attachment
              Ben Schmidt wrote:
              >> Well that's sorta the "rub"...I'm not modifying a ***pre-existing***
              >> file -- I am creating a new file. I don't want an *empty* file
              >> created if there was no file that existed before. If there *is* an
              >> empty file "foo.c", THEN I would expect, "foo.c~", to be created as a
              >> backup. But if there IS no file "foo.c", then when I save "foo.c",
              >> it's a **BUG** to create a "foo.c~".
              >
              > Yeah, I agree.
              >
              > The thing is, my Vim doesn't do this.
              ---
              set "patchmode=.orig"

              Are you saying if you set this, then it doesn't create a 0-byte patch file
              to indicate that the previous version (before you edited) was a 0-byte file?

              It does on mine -- but unfortunately, it creates the "file.orig"
              whether there was a file with 0 bytes pre-existing and also creates
              the file when there was no file. Thus if you try to go through and
              to determine what files you have edited you won't absolutely know if
              there was a 0-byte file there, or if there was a null file there.

              somewhat unrelated:

              my backups generally stay out of the way with the settings:
              set backupdir=./.backups, ~/.backups
              set backup
              set backupext=.bak
              ---
              so with dirs where I want to keep backups with the dir, I can create
              a .backups dir in any directory where I want to keep them separate,
              else they goto a generic, "hidden" home dir. (Using /tmp or c:/temp would
              leave my backups in a public tmp-dir which might not be desirable),
              Whereas ".backups" dirs (in home or a subdir) are usually r/w only for me.



              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_use" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Ben Schmidt
              ... My apologies. I thought we were discussing the backup option. I didn t even know of the patchmode option. That said, the behaviour of patchmode
              Message 6 of 16 , Sep 9, 2008
              • 0 Attachment
                Linda W wrote:
                > Ben Schmidt wrote:
                >>> Well that's sorta the "rub"...I'm not modifying a ***pre-existing***
                >>> file -- I am creating a new file. I don't want an *empty* file
                >>> created if there was no file that existed before. If there *is* an
                >>> empty file "foo.c", THEN I would expect, "foo.c~", to be created as a
                >>> backup. But if there IS no file "foo.c", then when I save "foo.c",
                >>> it's a **BUG** to create a "foo.c~".
                >> Yeah, I agree.
                >>
                >> The thing is, my Vim doesn't do this.
                > ---
                > set "patchmode=.orig"

                My apologies. I thought we were discussing the 'backup' option. I didn't
                even know of the 'patchmode' option.

                That said, the behaviour of patchmode creating an empty file when none
                existed previously is consistent with its namesake, the patch utility
                (and diff) which have similar ambiguity between empty and nonexistent
                files.

                I would still probably prefer the behaviour you mention, but I don't
                think it's so wrong as if 'backup' (and 'backupext') behaved this way,
                and the behaviour you are experiencing is documented.

                On my man pages for diff/patch it's listed under 'CAVEATS' not 'BUGS',
                too, but I reckon that's pretty open to interpretation!

                Cheers,

                Ben.



                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_use" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              Your message has been successfully submitted and would be delivered to recipients shortly.