Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encodeFS is not documented #248

Open
joeyh opened this issue Jan 20, 2025 · 1 comment
Open

encodeFS is not documented #248

joeyh opened this issue Jan 20, 2025 · 1 comment

Comments

@joeyh
Copy link

joeyh commented Jan 20, 2025

I noticed that encodeFS lacks haddock documentation about what it does, eg see here:
https://hackage.haskell.org/package/filepath-1.5.4.0/docs/System-OsPath.html#v:encodeFS

By process of elimination on the 3 strategies that the documentation discusses, I was able to guess that it mimics the behavior of the base library.

I think this should be documented, like decodeFS is.

@hasufell
Copy link
Member

Hmm

-- | Like 'encodeUtf', except this mimics the behavior of the base library when doing filesystem
-- operations, which is:
--
-- 1. on unix, uses shady PEP 383 style encoding (based on the current locale,
-- but PEP 383 only works properly on UTF-8 encodings, so good luck)
-- 2. on windows does permissive UTF-16 encoding, where coding errors generate
-- Chars in the surrogate range
--
-- Looking up the locale requires IO. If you're not worried about calls
-- to 'setFileSystemEncoding', then 'unsafePerformIO' may be feasible (make sure
-- to deeply evaluate the result to catch exceptions).
encodeFS :: FilePath -> IO OsPath

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants