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

Re: New line not recognized

Expand Messages
  • Tony Mechelynck
    ... Depending on how the logging is done, in the case I mentioned there could very well be quite a lot of s before the first , and, let s say,
    Message 1 of 17 , Nov 17, 2012
    • 0 Attachment
      On 17/11/12 14:34, Christian Brabandt wrote:
      > Hi Tony!
      >
      > On Sa, 17 Nov 2012, Tony Mechelynck wrote:
      >
      >> On 17/11/12 09:00, jeroen wrote:
      >>> On Friday, November 16, 2012 5:09:19 PM UTC+1, Marco wrote:
      >>>> 2012-11-16 Ben Fritz:
      >>>>
      >>>>
      >>>>
      >>>>> On Friday, November 16, 2012 9:55:10 AM UTC-6, Marco wrote:
      >>>>
      >>>>>>
      >>>>
      >>>>>>> My Windows GVim opened the file exactly as you described: one long line.
      >>>>
      >>>>>>> However, by using ":e ++ff=mac" (again, no quotes) I was able to reload the
      >>>>
      >>>>>>> file correctly.
      >>>>
      >>>>>>
      >>>>
      >>>>>> Thanks a lot, that works. Can I automate this somehow, so that vim
      >>>>
      >>>>>> opens <CR> (mac) files automatically with the ff=mac setting?
      >>>>
      >>>>>>
      >>>>
      >>>>>
      >>>>
      >>>>> :help 'fileformats' (note the s at the end).
      >>>>
      >>>>
      >>>>
      >>>> Thanks
      >>>>
      >>>>
      >>>>
      >>>> set fileformats=unix,dos,mac
      >>>>
      >>>>
      >>>>
      >>>> did the trick.
      >>>>
      >>> Is there any reason why this is not the default on unix?
      >>>
      >>> Jeroen
      >>>
      >> I'm not sure, but on Unix (well, on Linux) I have occasionally met
      >> files which had a lot of lone carriage-returns and yet weren't Mac
      >> files. This happens for instance when logging the stdout of a
      >> console program which displays a text-mode "progess bar" by using a
      >> CR to go to the left margin without advancing to the next line, in
      >> order to overwrite the line just written. ISTR that rsync used to do
      >> that (when I used it to keep my Vim source in sync before there was
      >> a Mercurial repository), and maybe Mercurial (with the "progress"
      >> extension), or the command-line "ftp" utility, do too. In that case
      >> you don't want to break the line at a lone CR but you may want to
      >> delete everything that precedes a CR which is not at the end of a
      >> line (CR at the end of a line, i.e. followed by a line-feed
      >> character, can be taken care of by reading the file with ++ff=dos).
      >
      > Sure enough, but that wouldn't have triggered Vim to set the fileformat
      > to mac. As long there are some newlines in there, you would be safe.
      >
      > regards,
      > Christian
      >

      Quoting options.txt lines 2905 sqq under 'fileformats':

      > This means that "mac" is only chosen when:
      > "unix" is not present or no <NL> is found in the file, and
      > "dos" is not present or no <CR><NL> is found in the file.
      > Except: if "unix" was chosen, but there is a <CR> before
      > the first <NL>, and there appear to be more <CR>s than <NL>s in
      > the first few lines, "mac" is used.

      Depending on how the logging is done, in the case I mentioned there
      could very well be quite a lot of <CR>s before the first <NL>, and,
      let's say, something like fifty <CR>s before the fifth <NL>.


      Best regards,
      Tony.
      --
      UNIX was half a billion (500000000) seconds old on
      Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch).
      -- Andy Tannenbaum

      --
      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
    • Christian Brabandt
      Hi Tony! ... It is more likely, the file is really in MAC format rather than some obscure logfile. regards, Christian -- Es gibt problematische Naturen, die
      Message 2 of 17 , Nov 17, 2012
      • 0 Attachment
        Hi Tony!

        On Sa, 17 Nov 2012, Tony Mechelynck wrote:

        > Depending on how the logging is done, in the case I mentioned there
        > could very well be quite a lot of <CR>s before the first <NL>, and,
        > let's say, something like fifty <CR>s before the fifth <NL>.

        It is more likely, the file is really in MAC format rather than some
        obscure logfile.

        regards,
        Christian
        --
        Es gibt problematische Naturen, die keiner Lage gewachsen sind,
        in der sie sich befinden, und denen keine genugtut. Daraus entsteht
        der ungeheure Widerstreit, der das Leben ohne Genuss verzehrt.
        -- Goethe, Maximen und Reflektionen, Nr. 278

        --
        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
      • stosss
        ... Just adding a comment. A couple weeks ago I had 4 files that I created on my Linux system and did not move them or share them and some how they were
        Message 3 of 17 , Nov 17, 2012
        • 0 Attachment
          On Sat, Nov 17, 2012 at 11:39 AM, Christian Brabandt <cblists@...> wrote:
          > Hi Tony!
          >
          > On Sa, 17 Nov 2012, Tony Mechelynck wrote:
          >
          >> Depending on how the logging is done, in the case I mentioned there
          >> could very well be quite a lot of <CR>s before the first <NL>, and,
          >> let's say, something like fifty <CR>s before the fifth <NL>.
          >
          > It is more likely, the file is really in MAC format rather than some
          > obscure logfile.
          >

          Just adding a comment.

          A couple weeks ago I had 4 files that I created on my Linux system and
          did not move them or share them and some how they were showing a ^M
          when I was doing a grep and sed search and replace from the shell. So
          it must be possible to create that condition on Linux but I have no
          idea how it happened but the files are no longer showing that
          condition.

          --
          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 Fritz
          ... The problem wasn t showing a ^M , that s pretty common. The problem was that EVERY line was terminated ONLY by a ^M and there were NO linefeed characters
          Message 4 of 17 , Nov 18, 2012
          • 0 Attachment
            On Saturday, November 17, 2012 10:46:01 PM UTC-6, stosss wrote:
            >
            >
            > A couple weeks ago I had 4 files that I created on my Linux system and
            >
            > did not move them or share them and some how they were showing a ^M
            >
            > when I was doing a grep and sed search and replace from the shell.

            The problem wasn't "showing a ^M", that's pretty common. The problem was that EVERY line was terminated ONLY by a ^M and there were NO linefeed characters in the file at all, so the file was showing as one long line with a bunch of ^M characters.

            --
            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
          • stosss
            ... Okay :-) thanks. I didn t realize that happens a lot with the ^M . They showed up again in a file last night but not the continuous single line. Then they
            Message 5 of 17 , Nov 18, 2012
            • 0 Attachment
              On Sun, Nov 18, 2012 at 8:50 AM, Ben Fritz <fritzophrenic@...> wrote:
              > On Saturday, November 17, 2012 10:46:01 PM UTC-6, stosss wrote:
              >>
              >>
              >> A couple weeks ago I had 4 files that I created on my Linux system and
              >>
              >> did not move them or share them and some how they were showing a ^M
              >>
              >> when I was doing a grep and sed search and replace from the shell.
              >
              > The problem wasn't "showing a ^M", that's pretty common. The problem was that EVERY line was terminated ONLY by a ^M and there were NO linefeed characters in the file at all, so the file was showing as one long line with a bunch of ^M characters.
              >

              Okay :-) thanks. I didn't realize that happens a lot with the "^M".
              They showed up again in a file last night but not the continuous
              single line. Then they were gone without me doing anything. I have
              never actually seen them when opening the actual file. Only when doing
              a shell command that out puts to the screen. Like grep, cat, head,
              tail etc. I have also never seen them in a file created when using a
              redirect away from the screen.

              --
              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.