49254Re: VIM and NTFS streams
- Feb 4, 2008On Feb 4, 2008 4:29 PM, krischik wrote:
>I'm not sure that most other apps do need detection. wget, for
> On 4 Feb., 21:10, "Matt Wozniski" wrote:
> > While this would be nice, it would require support code from every
> > application you have. It may only be 6 lines, but 6 lines * 5000
> > binaries is much more code than is in vim for line ending detection.
> But the other 5000 applications need detection as well. I did mention
> webserver and browser getting detection wrong. konquror/nautilus/
> explorer needs detection and far more complex then vim. And sure OS/2
> needed detection. But there you could always overwrite faulty detected
> value by manualy correcting the EA's.
instance, doesn't have to care what line endings the data it saves
has. But, for what you want, it would have to detect and save it,
even though it doesn't use it. Shell redirection has no idea what's
going through it, so it has no way to possibly say what Content-type
it is... or dd... or tar extracting files that were created on a
filesystem that didn't track extended attributes...
> > After all, vim can't use this information unless something put itThe issue isn't waiting for it to catch on, it's that until it's
> > there, which requires that everything that can create a file - from
> > touch to wget to shell redirection - needs to be able to put that
> > attribute into the file. And, AFAIK, there's no way for those wget or
> > shell redirection to even know what type of line ending the data that
> > they wrote out had. Which means they'd need to detect it.
> Just one example: The OS/2 version of ZIP would pack extended
> attributes. Once it catches on then more application will support it.
> But I know that this won't happen. We went down the "worse is better"
> way for far to long.
universally available it only increases the amount of code and
maintenance burden. And, there's no way that it would ever be
universally available for things like line endings style, because most
applications just don't know or need to care, so have no reason to set
that attribute. Things like marking the content encoding might be
more useful, but still, not good to work with... If, for example, you
had a file "test.txt" encoded in UTF-16 and with extended attributes
marking it as such, and your locale is set to use UTF-8, what would
you expect the result of "cp test.txt test2.txt" to be? What about
"cat text.txt >text2.txt"? If you expect those two commands to have
the same effect, I don't see how it can be done without changes to cp
(mark attrs on dest), cat (mark attrs on stdout), and the kernel
itself (allow extended attributes on streams).
> > WhichThe problem with this idea isn't the limitations inherent in backwards
> > would require that just about every program out there that is
> > transcribing a data stream from one spot to another, rather than
> > authoring it itself, would need to duplicate the sort of EOL detection
> > code in vim in itself. And vim would still need to continue
> > supporting the old way since it's designed to run on filesystems that
> > still don't support extended attributes - or it would need to come up
> > with a way to fake extended attributes on those FS types. No one is
> > saying that extended attributes can't do useful things - just that
> > without being in any way standardized, it's unreasonable to expect
> > that any attributes will ever be set by anyone but you.
> Ahh, indeed, there is the problem and the reason why computing has not
> advanced as much in the last 15 years as one would have expected
> seeing the 15 years before: Backward compatibilty has hobbled us.
compatibility - if it were worthwhile to do, it's no problem to have
code that uses attributes if possible and the old, backwards
compatible method if not. The problem is that creating this standard
and tying it properly into a POSIX OS would require a lot of low-level
changes. If we can agree on the requirements - that there must be
some number of predefined attributes that are set on every regular
file (and what about special files?), that the operating system must
handle initializing these attributes correctly when a file is created,
that streams would also need to have attributes, and that copying,
extracting, and in general "moving around" data will "just work", can
you see how difficult this would be to implement? To fully implement
this, the very least that's required is an operating system that only
supports filesystems that have some way of storing extended
attributes, a kernel that's able to initialize each of those
attributes on every file created, a shell that knows how to get/set
these attributes (and which it needs to set), and a copy of the
coreutils that are aware of the changes (so that "cp file1 file2"
creates file2 with the attrs of file1, not the defaults), at the very
least? And that work is just the baseline - the point where other
software can start counting on a base set of attributes that will
always exist, and trusting that they're correct. On a quick glance, I
see absolutely no way to do this properly without support from the OS.
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>