Hi
re: isValid Perhaps we should be more specific and make it talk about illegal file name characters if that is indeed the use case. Perhaps we should provide a system-dependent list of characters that are not allowed in file names. For example, on windows that would include '?'.
Then an application can decide for itself what to do about that depending on the context. It might be able to tell the user to pick a different name, or in the wget case replace it with a different character or remove it or something.
Unfortunately thats too much work for the user of the API. Since it tends to work on Posix, people probably won't go to the hassle of fixing it up. If they have a "simple fix" then there is at least a chance that they'll accept a patch that fixes the behaviour on Windows. The only options that I can see are either you want it fixed, or you want to get the user to fix it manually - both are catered for. And on Windows its more complex, LPT1.txt is also an invalid file, but LPT1.txt.txt isn't. Trying to express the weirdness of Windows is probably beyond the chances of an API :)
So maybe we should keep isValid but specify exactly what it checks. I'm happy to specify things in more detail, at the moment its pretty much a no-op on Posix, but if any Posix user suggests thats wrong I'll happily fix it up.
Sorry, I meant to say what I think wget should do. IMO, it should have a conservative set of allowed characters, encode the filename into that
Not enough, because of the LPT1 issue - unless you add L as a disallowed letter :)
Haskell makes the difference, runInteractiveCommand vs runInteractiveProcess I'm not following.
Having some considerations towards a real path, one that can be used on the command is reasonable, I think, because Haskell has functions within it that distinguish between firing something at the underlying filepath vs at the console. I don't however think its worth having a special type for working with emacs, unless you have System.FilePath.Emacs, given that Emacs is almost an operating system :)
But the trouble is that if you silently drop the '/', then the only way for me to implement a correct cp(1) in Haskell is to not use your proposed interface for pathname handling, which drops this information. Ok, now I remember the reasons I kept the trailing slash, I'll leave it in. Esp the risers4 issue.
Thanks Neil