On Feb 4, 2008 4:29 PM, krischik wrote: > > 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.
I'm not sure that most other apps do need detection. wget, for 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 it > > 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. The issue isn't waiting for it to catch on, it's that until it's 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). > > Which > > 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. The problem with this idea isn't the limitations inherent in backwards 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. ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
