Loading ...
Sorry, an error occurred while loading the content.

49253Re: VIM and NTFS streams

Expand Messages
  • krischik
    Feb 4, 2008
    • 0 Attachment
      On 4 Feb., 21:10, "Matt Wozniski" <m...@...> wrote:
      > On Feb 4, 2008 9:18 AM, krischik wrote:
      >
      >
      >
      > > 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[64];
      > > char mime_encoding[64];
      > > char line_ending[64];
      >
      > > 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.

      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.

      > 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.

      > 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.

      Martin
      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Show all 25 messages in this topic