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

Re: [OT] Bug or Feature?

Expand Messages
  • Benji Fisher
    ... Maybe I have lost track and need to be reminded what the problem is. If you set cpo to $ then you have removed the F flag, so (it seems to me) this
    Message 1 of 17 , Jun 5, 2006
    • 0 Attachment
      On Sun, Jun 04, 2006 at 08:03:09PM +0200, Andre Berger wrote:
      > * Andre Berger (2006-06-04):
      > > * Andre Berger (2006-05-28):
      > > > * Ned Konz (2006-05-28):
      > > > > Andre Berger wrote:
      > > > > >* Chris Allen (2006-05-26):
      > > > > >>On 5/26/06, Andre Berger <andre.berger@...> wrote:
      > > > > >>>* Chris Allen (2006-05-26):
      > > > > >>>>On 5/25/06, Andre Berger <andre.berger@...> wrote:
      > > > > >Yes. I start vim without any command line-arguments, and get a "no
      > > > > >name" (previously a "no file") buffer, about which I read in the
      > > > > >upgrade information. So far, so good. I type my text, and save it to
      > > > > >a file with ":w". Previous versions of Vim wrote the file and loaded
      > > > > >it into the initial buffer, like ":saveas" does. 7.0.17 (my huge
      > > > > >self-compiled version) just writes to the file, but keeps the noname
      > > > > >buffer. I would like to have the old behavior back. I hope it's
      > > > > >clearer what I mean now. I asked this here because I wasn't sure if
      > > > > >that's a design change, Mac related, or a local problem.
      >
      > I could track the problem down, and it looks like a bug to me: The
      > problem exists with
      >
      > set cpoptions=$ " change to $
      >
      > only, on Vim > 6

      Maybe I have lost track and need to be reminded what the problem
      is. If you set 'cpo' to "$" then you have removed the "F" flag, so (it
      seems to me) this is the expected behavior. Does vim 6.x have the "F"
      flag in 'cpo'?

      HTH --Benji Fisher
    • Andre Berger
      ... Nevermind. cpo set to the default parameters plus $, and the problem is gone. -Andre
      Message 2 of 17 , Jun 5, 2006
      • 0 Attachment
        * Benji Fisher (2006-06-05):
        > On Sun, Jun 04, 2006 at 08:03:09PM +0200, Andre Berger wrote:
        > > * Andre Berger (2006-06-04):
        > > > * Andre Berger (2006-05-28):
        > > > > * Ned Konz (2006-05-28):
        > > > > > Andre Berger wrote:
        > > > > > >* Chris Allen (2006-05-26):
        > > > > > >>On 5/26/06, Andre Berger <andre.berger@...> wrote:
        > > > > > >>>* Chris Allen (2006-05-26):
        > > > > > >>>>On 5/25/06, Andre Berger <andre.berger@...> wrote:
        > > > > > >Yes. I start vim without any command line-arguments, and get a "no
        > > > > > >name" (previously a "no file") buffer, about which I read in the
        > > > > > >upgrade information. So far, so good. I type my text, and save it to
        > > > > > >a file with ":w". Previous versions of Vim wrote the file and loaded
        > > > > > >it into the initial buffer, like ":saveas" does. 7.0.17 (my huge
        > > > > > >self-compiled version) just writes to the file, but keeps the noname
        > > > > > >buffer. I would like to have the old behavior back. I hope it's
        > > > > > >clearer what I mean now. I asked this here because I wasn't sure if
        > > > > > >that's a design change, Mac related, or a local problem.
        > >
        > > I could track the problem down, and it looks like a bug to me: The
        > > problem exists with
        > >
        > > set cpoptions=$ " change to $
        > >
        > > only, on Vim > 6
        >
        > Maybe I have lost track and need to be reminded what the problem
        > is. If you set 'cpo' to "$" then you have removed the "F" flag, so (it
        > seems to me) this is the expected behavior. Does vim 6.x have the "F"
        > flag in 'cpo'?

        Nevermind. cpo set to the default parameters plus $, and the problem
        is gone.

        -Andre
      Your message has been successfully submitted and would be delivered to recipients shortly.