3 ms·
Eh, the code is not that bad but it's weird that they don't scan from the right instead of the left to find 'xxx//yyy//zzz' (which means ignore 'xxx/' because y
by jhallenworld 11y ago
Eh, the code is not that bad but it's weird that they don't scan from the right instead of the left to find 'xxx//yyy//zzz' (which means ignore 'xxx/' because you began a new path with '/yyy', but ignore '/yyy' also because you began a new path with '/zzz').
Here is the same code in JOE (which has no VMS support and which treats foo/../bar and bar as different files - the original emacs code was written before symlinks!). JOE has a variable length string library, so you see 'vsncpy' instead of the alloca / strcpy / strcat / make_string.
http://sourceforge.net/p/joe-editor/mercurial/ci/default/tree/joe/b.c#l2534 http://sourceforge.net/p/joe-editor/mercurial/ci/default/tre...
Edit: Holy Cow! The new version in emacs is much more involved: https://github.com/emacs-mirror/emacs/blob/master/src/fileio.c#L757 https://github.com/emacs-mirror/emacs/blob/master/src/fileio...
"For technical reasons, this function can return correct but
non-intuitive results for the root directory; for instance,
(expand-file-name ".." "/") returns "/.."... " :-)
- JoshTriplett 11y ago> Eh, the code is not that bad but it's weird that they don't scan from the right instead of the left to find 'xxx//yyy//zzz' (which means ignore 'xxx/' because you began a new path with '/yyy', but ignore '/yyy' also because you began a new path with '/zzz'). expand-file-name doesn't do that; (expand-file-name "/foo//bar") produces "/foo/bar", just like any other pathname canonicalization. I can't help but wonder why emacs doesn't write that function in lisp, rather than C.
- jhallenworld 11y agoYou are right, there must be some other function which does that. Maybe the code predates the lisp interpreter.