gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] missing feature: text file handling


From: tomas
Subject: Re: [Gnu-arch-users] missing feature: text file handling
Date: Thu, 7 Oct 2004 15:47:42 +0200
User-agent: Mutt/1.5.3i

On Thu, Oct 07, 2004 at 02:02:01PM +0200, Robin Farine wrote:
> On Thursday 07 October 2004 13.41, address@hidden wrote:
> > On Thu, Oct 07, 2004 at 01:30:27PM +0200, address@hidden 
> wrote:
> 
> > > So, it would be nice to classify a file as being
> > > "dos text", "unix text", "mac text", "portable text", binary.
> > > or "CR/LF", "LF", "CR", "native", binary.
> 
> > This might be an application of Robin's `generalized attributes'
> > thing.
> 
> As part of the files, line termination characters have a direct 
> influence on changeset operations that rely on line-oriented 
> diff/patch/merge utilities. So this falls out of the realm of the 
> 'generalized attributes' thing.

I was rather thinking of an attribute telling how a file has to
be interpreted (not how a file really *is*). So if a file is said
to be ``unix text'' and it has 1200 roughly line-sized chunks
separated by CR, then it is still a long line with roughly 1200
funny chars in it. Quite different to seeing it as a ``mac text''.
And every ``dos text'' can be seen as ``unix text'' (but there
is this pesky garbage char at the end of each line ;-).

The line termination is not implicit in the file. You can
try to guess a line termination which makes sense. Or attach
this information to the file as meta-data, which would be, by
definition, always right.

Is it worth it? I don't know[1]. I'd imagine that it might be
easier to use an editor `in the know' which respects the particular
`line termination conventions'' of a file. Then it'd be rather
a project policy thing whether the people involved care. Like
tabs/whitespaces in C source, I'd say ;-)

Having an extensible meta-data thing could leave the choice to
the people involved in the project.

------------
[1] Actually I do know for me: I wouldn't bother. But...

Regards

-- tomás

Attachment: pgpWsBT24YIpW.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]