49253Re: VIM and NTFS streams
- Feb 4, 2008On 4 Feb., 21:10, "Matt Wozniski" <m...@...> wrote:
> On Feb 4, 2008 9:18 AM, krischik wrote:But the other 5000 applications need detection as well. I did mention
> > On the other hand use of extended attributes could solve a problem
> > with 5 lines of code where solving the same problem without could cost
> > you 50. Determine file types, text file line endings and text file
> > encoding come to my mind here. Ask Bram how many line of code he
> > needed in Vim to determine these three informations. With consequent
> > use of xattribs it would have been 6 lines:
> > char mime_type;
> > char mime_encoding;
> > char line_ending;
> > getxattr (filename, "Content-Type",mime_type, sizeof mime_type);
> > getxattr (filename, "Line-Ending", line_ending, sizeof line_ending);
> > getxattr (filename, "Content-Encoding",mime_encoding, sizeof
> > mime_encoding);
> 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.
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.
> After all, vim can't use this information unless something put itJust one example: The OS/2 version of ZIP would pack extended
> 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.
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.
> WhichAhh, indeed, there is the problem and the reason why computing has not
> 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.
advanced as much in the last 15 years as one would have expected
seeing the 15 years before: Backward compatibilty has hobbled us.
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 >>