Incompatible change to file-attributes - this is how it can look (was: [PATCH 21.5] Add ID-FORMAT to file-attributes (Suggestions are welcome))
8:31 p.m.
Background: making file-attributes compatible with the GNU version
triggered an idea of changing the interface to file attributes into
something incompatible. The discussion has taken place in
xemacs-patches which might not attract so many readers so I move this
to xemacs-beta now.
>>>> Mats Lidell <matsl(a)xemacs.org> writes:
OK. I'll see what I can come up with then! Stay tuned.
I did this to try the idea out.
* Core
Since file-attributes more or less is what stat(2) delivers I renamed
file-attribute to file-stat in XEmacs core. file-stat further returns
a vector instead of a list. It is not a 100% match to stat but good
enough to warrant that name I think.
Since we use file-attribute internally in elisp files in core those
where changed to use file-stat instead.
To get to the new functionality I reused the function user-login-name
that provides the conversion from uid to username. I also added a new
function get-group-name that provides the group name from the group
id.
Q: Since I don't really understand the file handler business with
packages such as tramp I don't know how this core change will
influence those. I guess file-attributes in those places would need to
be changed to use of file-stat instead!?
* xemacs-base
In xemacs-base I added a new file os.el which provides access
functions to the file-stat data. Such as "file-stat/uid". So for
getting the uid of a file you would write:
(file-stat/uid (file-stat "file"))
I also introduced there the vectorized file-attributes function called
file-attr that returns in a vector everything that file-stat does plus
two more fields, user-login-name and group-name. (This is the
interface that has been described as backwards compatible since the
new fields are added instead of replacing fields.)
* fsf-compat
Finally in fsf-compat I added file-attributes with the GNU
compatibility interface.
* Conclusion?
This can be done in other ways and it can be improved but now you see
more how it will turn out if we do like this. Is this how you would
want it? If not, how would you like to change it?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:56 a.m.
New subject: Incompatible change to file-attributes - this is how it can look
Mats Lidell <matsl(a)xemacs.org> writes:
Q: Since I don't really understand the file handler business
with
packages such as tramp I don't know how this core change will
influence those. I guess file-attributes in those places would need to
be changed to use of file-stat instead!?
I dislike this change. What you could do is to call the file name
handler of `file-attributes' inside `file-stat' if needed. But this is a
hack, and likely there will be problems in the future.
I do not plan to add file name handlers for `file-stat' in Tramp. Double
work for nothing, from the pov of Tramp.
Yours
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:57 a.m.
New subject: Incompatible change to file-attributes - this is how it can look
>>>> Michael Albinus <michael.albinus(a)gmx.de>
writes:
I do not plan to add file name handlers for `file-stat' in
Tramp. Double work for nothing, from the pov of Tramp.
But, for my understanding, it is correct that if the file-attributes
function would be replaced with a new API, and we do no hack solution,
all file-handlers would need to be changed accordingly.
Is the file-handler design described somewhere? I can guess what it is
doing but can I read about it somewhere?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:24 p.m.
New subject: Incompatible change to file-attributes - this is how it can look
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Michael Albinus <michael.albinus(a)gmx.de>
writes:
> I do not plan to add file name handlers for `file-stat' in
> Tramp. Double work for nothing, from the pov of Tramp.
But, for my understanding, it is correct that if the file-attributes
function would be replaced with a new API, and we do no hack solution,
all file-handlers would need to be changed accordingly.
Is the file-handler design described somewhere? I can guess what it is
doing but can I read about it somewhere?
In the GNU Emacs elisp manual, there is the section
(elisp)Top > Files > Magic File Names
Something similar shall be available for XEmacs.
I do not oppose in general adding this support in Tramp. Patches would
be welcome. However, the contributor must have signed the legal FSF papers.
Yours
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:02 a.m.
New subject: Incompatible change to file-attributes - this is how it can look
Michael Albinus writes:
Mats Lidell <matsl(a)xemacs.org> writes:
> Q: Since I don't really understand the file handler business with
> packages such as tramp I don't know how this core change will
> influence those. I guess file-attributes in those places would need to
> be changed to use of file-stat instead!?
No, we need to preserve the file-attributes API for backward
compatibility. This is especially true of APIs which support hooks
and handlers.
What I'm suggesting is that we can provide a more regular API for
people who want to use it, or perhaps for internal use.
I dislike this change. What you could do is to call the file name
handler of `file-attributes' inside `file-stat' if needed. But this is a
hack, and likely there will be problems in the future.
I agree that it's a problematic hack.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:02 p.m.
New subject: Incompatible change to file-attributes - this is how it can look
I got a little lost in this discussion. Forgive & ignore me if I'm
being stupid:
While I agree Mad's design would be superior in and off itself,
Michael's considerations are more important. So my vote is that our
`file-attributes' should be like GNU Emacs's. But I missed this
discussion:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
No, we need to preserve the file-attributes API for backward
compatibility. This is especially true of APIs which support hooks
and handlers.
Isn't the GNU API backwards compatible with ours? I read over them, and
it seemed to me it is.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:38 p.m.
New subject: Incompatible change to file-attributes - this is how it can look
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
Isn't the GNU API backwards compatible with ours? I read over
them,
and it seemed to me it is.
GNU has added an optional arg ID-FORMAT that turns the uid and gid
into their string representations. They also propose at some time make
the string representation the default, and thus break old code.
I guess that is what triggered the idea of making another interface
that would not break old code. Instead the new string values would be
added after the other old values and, while we were at it, make it
into a vector instead of a list.
In practise we are struck with file-attributes because of
file-handlers needs it. So it gets hard and, IMHO, not worth the
effort to introduce an alternative interface when we still need to
keep file-attributes!? (But I haven't thrown away the patch if it is
really wanted.)
I'd now rather go for adding ID-FORMAT to file-attributes to complete
that work since it seems we must do that anyway. That patch is almost
ready except for proper ChangeLog items and native windows
support. (Which I can't do at the moment because I have no tool
chain.)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8 a.m.
New subject: Incompatible change to file-attributes - this is how it can look
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
> Isn't the GNU API backwards compatible with ours? I read over them,
> and it seemed to me it is.
GNU has added an optional arg ID-FORMAT that turns the uid and gid
into their string representations. They also propose at some time make
the string representation the default, and thus break old code.
So at this time it would be backwards-compatible, right? And it would
stop being so in the future. Just trying to understand ...
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:22 a.m.
New subject: Incompatible change to file-attributes - this is how it can look
Michael Sperber <sperber(a)deinprogramm.de> writes:
> GNU has added an optional arg ID-FORMAT that turns the uid and
gid
> into their string representations. They also propose at some time make
> the string representation the default, and thus break old code.
So at this time it would be backwards-compatible, right? And it would
stop being so in the future. Just trying to understand ...
According to Tramp's ChangeLog, ID-FORMAT was added back in 2003. I
don't remember that is has been discussed ever to change the default
value of it. It might be changed in the future, yes, but I don't expect
it.
And, btw, I would oppose. For the same reasons I have opposed here ...
Best regards, Michael.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:36 p.m.
New subject: Incompatible change to file-attributes - this is how it can look
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> No, we need to preserve the file-attributes API for backward
> compatibility. This is especially true of APIs which support hooks
> and handlers.
Isn't the GNU API backwards compatible with ours? I read over them, and
it seemed to me it is.
No, it now nondeterministically returns strings or numbers where ours
always returns numbers. And it's just an unnecessarily yucky change.
Why throw away information you made a system call to get?
So I was proposing a more regular and extensible API, that we could
wrap with GNU-compatibility.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:05 p.m.
New subject: Incompatible change to file-attributes - this is how it can look
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
No, we need to preserve the file-attributes API for backward
compatibility. This is especially true of APIs which support hooks
and handlers.
And we need to do that in core and not in fsf-compat I guess.
What I'm suggesting is that we can provide a more regular API
for
people who want to use it, or perhaps for internal use.
Fine with me. So these would then be more or less two parallel
interfaces.
- file-attributes changed for GNU compatibility and support for file
handlers.
- And then some other function, like the file-stat and file-attr,
stuff I hacked together recently to test the design. That could
then be use internally and for anybody who prefers the alternative
interface (but not for file-handlers)
Well, if I step back, and look on this from a distance, the
alternative API does not look that promising. Internally it could be
motivated for but for packages, what upstream would prefer the
enhanced interface when they still would have to use the other
interface for GNU compatibility?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:40 p.m.
New subject: Incompatible change to file-attributes - this is how it can look
Mats Lidell writes:
what upstream would prefer the enhanced interface when they still
would have to use the other interface for GNU compatibility?
True, but they'd be ashamed of themselves. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4027
days inactive
4030
days old
11 comments
4 participants
participants (4)
-
Michael Albinus -
Michael Sperber -
Stephen J. Turnbull -
The XEmacs Package Smoketest