On Wed, Apr 3, 2013 at 5:22 AM, Lech Lorens <lech.lor...@gmail.com> wrote:
>
> On 02-Apr-2013 Ben Fritz <fritzophre...@gmail.com> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Raspunde prin e-mail lui