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

68951Re: [patch] Handle files with mixed LF - CRLF line endings when doing tag search

Expand Messages
  • Benjamin Fritz
    Apr 3 8:01 AM
      On Wed, Apr 3, 2013 at 5:22 AM, Lech Lorens <lech.lorens@...> wrote:
      >
      > On 02-Apr-2013 Ben Fritz <fritzophrenic@...> wrote:
      > > On Monday, April 1, 2013 11:43:38 AM UTC-5, Bram Moolenaar wrote:
      > > >
      > > > I wonder how many users actually run into files where only some lines
      > > >
      > > > end in a CR. I would consider such a file broken, and first thing would
      > > >
      > > > be to strip them all off.
      > > >
      > >
      > > It's quite frequent where I work. I even have an autocmd that reloads the
      > > file in DOS format if it detects mixed line endings. It sets "nomodified"
      > > but doesn't save, so if I don't make any further changes, the file on-disk
      > > remains unchanged.
      >
      > But it is a kind of a half-solution.

      Agreed. And I didn't create the autocmd for this particular problem, I created
      it because I was tired of seeing ^M characters in my file. My first attempt
      was to use syntax highlighting to just hide them but special character
      highlighting prevented that from working.

      > When you modify a single line in
      > the file and write it, you end up with a number of changed lines.

      Yes, but I think I made my autocmd smart enough to use whichever fileformat
      will change the fewest lines.

      > How do
      > you cope with that? In this case I can't simply check in the file
      > – I have to undo the line endings modifications which is quite a tedious
      > and annoying task.

      I do just check in the file, without undoing the line ending modifications.
      Where I work we're only really concerned that all changes get peer reviewed.
      Plus, a good external diff tool will be able to ignore line ending changes.
      Maybe that doesn't work for you.

      > I'll be extremely happy to get a hint how I should go about this
      > problem.
      >

      The best solution is probably to get everybody on your team to use a
      consistent file format. But I agree Vim should not choke because they don't.

      > > The problem is that many other editors, including Visual Studio and
      > > UltraEdit, may read in Unix file format correctly, but depending on
      > > how they are configured, will insert Windows line endings on any *new*
      > > lines. UltraEdit will even preserve line ending style of any
      > > copy-pasted text. That *sounds* like a feature but in reality it is
      > > incredibly annoying.
      >
      > I beg to differ. In my opinion the real problem is that Vim refuses to
      > cooperate. The compilers can deal with it, ctags and cscope can deal
      > with it, all other editors can deal with it[1]. Vim can't and now that I'm
      > trying to make Vim more friendly, I hear Vim is fine and I should fix
      > the files. Vim may be my favourite editor but – sorry – in this
      > particular case it is inferior to everything out there.
      >

      I may not have been clear. I meant the source of the bad files was other
      editors acting stupidly. Vim could handle things fine if those editors would
      just save the file in a consistent format, or allow you to see that the lines
      are not consistent, as Vim does.

      I think Vim should accept the output of stupid editors without jumping through
      hoops. I would actually welcome this patch or a similar one. Rather than doing
      two searches couldn't we just always insert \r\? before the $ in the search
      pattern? Like Bram I don't like the idea of two searches whenever a tag is not
      found but I doubt very much that an extra single optional character will cause
      a big performance hit. Do you really need to match any number of \r
      characters?

      --
      --
      You received this message from the "vim_dev" 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

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Show all 16 messages in this topic