Thanks for coding this up, Mats!
Mats Lidell writes:
-DEFUN ("file-attributes", Ffile_attributes, 1, 1, 0, /*
+DEFUN ("file-attributes", Ffile_attributes, 1, 2, 0, /*
Note that the second argument is optional.
Return a list of attributes of file FILENAME.
Value is nil if specified file cannot be opened.
+
+ID-FORMAT specifies the preferred format of attributes uid and gid (see
+below) - valid values are 'string and 'integer. The latter is the
+default, but we plan to change that, so you should specify a non-nil value
+for ID-FORMAT if you use the returned uid or gid.
I assume the "we plan to change that" statement comes from GNU?
But before that happens, we'd want to have a period where the second
attribute is mandatory, so I don't think we need that statement. I
also have to wonder if it will actually happen.
+ 2. File uid as a string or a number. If a string value cannot be
+ looked up, a numeric value, either an integer or a float, is returned.
+ 3. File gid, likewise.
Do you know if there was any discussion about alternative changes to
the API, like just adding two more elements at the end the list? The
GNU API requires two calls to get both values, which is probably an
unusual use case, but you could get it for free. Note that since all
calls to file-attributes "should" be changed anyway, you just change
`(nth 2 atts)' to `(or (nth 12 atts) (nth 2 atts))'.
I think we should consider a more coherent API (which, unfortunately,
would need a new name) on the following principles:
1. All information that might be useful should be returned.
2. Use an array, rather than a list.
3. Clients should be warned not to depend on the size of the array,
for forward compatibility (new attributes will be added at the end
of the list).
This approach would also allow a natural extension to reporting
extended attributes on file systems that support them (probably as a
property list?)
+ if (NILP(id_format))
+ return call2 (handler, Qfile_attributes, filename);
+ else
+ return call3 (handler, Qfile_attributes, filename, id_format);
As you suspected, this is horrible. The idea is apparently to allow
handlers to detect whether `file-attributes' was called with 2 or 3
arguments, but that's (a) a bad idea and (b) implemented incorrectly
(an explicit nil argument will be treated as if it is missing).
diff -r ec3712ffd0e6 tests/automated/dired-tests.el
New file? Ask Mike if he has any tests that could be converted for
use here.
+;; Test tag support.
Oops.:-)
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches