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

49250Re: VIM and NTFS streams

Expand Messages
  • Matt Wozniski
    Feb 4, 2008
    • 0 Attachment
      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.
      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. 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.

      That being said, if vim had a convenient way to see if extended
      attributes support was available on the filesystem, it might be worth
      caching things like the fileformat in the extended attributes, so it
      only needed to be computed once... Though that might open up a whole
      new can of worms, since someone could easily change the line endings
      with another tool between two vim runs, confusing the n00b user with a
      bunch of ^M's show up everywhere... all in all, this is one place
      where manual detection seems the best idea.

      For things like content encoding, it might be more useful - but again,
      since every other tool doesn't create it, vim would still need to fall
      back on autodetection if it couldn't find an attribute for it.

      ~Matt

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