12:53 p.m.
[ cross-posted and MFT set to xemacs-beta list ]
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
Steve Youngs writes:
> but 2 -- package-suppress doesn't seem to work. I just built XEmacs
> 21.5 CVS HEAD, and I see no evidence that `package-suppress'
> is doing anything.
AFAICT what package-suppress is designed to do is to prevent
autoloads
of core libraries from being overwritten by the package version, and
that's all.
Well, I was under the impression that `package-suppress' would
completely suppress a given library in the packages. With all
attempts to access said library (apart from an explicit `find-file'
maybe) resulting in either the core lisp version if exists or error.
That's why I say `package-suppress' is broken. In a fresh -vanilla
21.5...
(locate-library "regexp-opt")
=> "/usr/local/lib/xemacs/xemacs-packages/lisp/xemacs-base/regexp-opt.elc"
And `find-library', `find-function', `load', `require' all seem to use
the regexp-opt.elc from packages.
So in a freshly executed XEmacs 21.5, you should see that
regexp-opt autoloads refer to the core version of regexp-opt.
How do I do that?
What would you expect to see?
I'd expect to see everything that returns an elisp library to never
return a suppressed one. I'd expect to see everything that loads an
elisp library to never load a suppressed one.
I guess we'd also want (require 'regexp-opt) to find the
core
version if the package is suppressed?
Definitely.
I'm not sure that that is correct though; the package version
should presumably be used when explicitly requiring from another
package.
That sounds like crazy talk to me. :-)
I'd really like to hear what Ben has to say, seeing as though he was
the one who wrote the suppression stuff.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<steve(a)sxemacs.org>---|
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:15 p.m.
New subject: [Q] Re: [xemacs-base] Add byte-compiler warning control library
Steve Youngs writes:
> I'm not sure that that is correct though; the package
version
> should presumably be used when explicitly requiring from another
> package.
That sounds like crazy talk to me. :-)
Not really. More like "broken by design." Consider, packages are
supposed to be version-independent, but the main use of
package-suppress is to cater to version-specific differences in
location of some libraries. So a package wants version-independent
code (unless it knows what it's doing).
This is not the same as replacing a broken function with a fixed one,
I think. This is taking a package internal because you want to change
its API and semantics. That was Ben's explicit intention.
My head hurts....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:29 a.m.
New subject: [Q] Re: [xemacs-base] Add byte-compiler warning control library
Stephen J. Turnbull writes:
This is not the same as replacing a broken function with a fixed
one,
I think. This is taking a package internal because you want to change
its API and semantics. That was Ben's explicit intention.
Oh, and there's worse: consider that unicode.el is that name of a
Mule-UCS library that is implemented completely independently of the
core's unicode.el.
My head hurts....
No more than it did before .... :-/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:13 p.m.
New subject: [Q] Re: [xemacs-base] Add byte-compiler warning control library
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
Steve Youngs writes:
> > I'm not sure that that is correct though; the package version
> > should presumably be used when explicitly requiring from another
> > package.
>
> That sounds like crazy talk to me. :-)
Not really. More like "broken by design." Consider,
packages are
supposed to be version-independent, but the main use of
package-suppress is to cater to version-specific differences in
location of some libraries. So a package wants version-independent
code (unless it knows what it's doing).
If a package knows what it is doing in that it needs a specific
version of some lib it should be implementing the needed functionality
itself to maintain version-independence.
This is not the same as replacing a broken function with a fixed
one,
I think. This is taking a package internal because you want to change
its API and semantics. That was Ben's explicit intention.
Yes, I remember him saying along those lines.
`package-suppress' first appeared on Feb 3rd, 2005, and to the best of
my knowledge, I'm the first to say anything about it not working... in
2007. Nobody else has said anything simply because nobody else has
noticed that `package-suppress' doesn't work. But that isn't
surprising...
There is currently a total of two suppressed libs in the packages,
both in xemacs-base. Namely, `regexp-opt.el' and `easy-mmode.el'.
Looking a little closer [1]
$ diff -bBU0 pkg-regexp-opt core-regexp-opt | wc -l
=> 0
$ diff -bBU0 pkg-easy-mmode core-easy-mmode | \
grep -v '\(;;;###\|＠＠\)' | wc -l
=> 12
No wonder nobody has noticed, the differences are non-existent to
trivial at best.
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen J. Turnbull writes:
Oh, and there's worse: consider that unicode.el is that name of
a
Mule-UCS library that is implemented completely independently of the
core's unicode.el.
OK, this is yet another perfect example of why `package-suppress'
needs to _completely_ suppress the library and not just its
autoloads.
Having `package-suppress' do _anything_ is the first step, though.
> My head hurts....
No more than it did before .... :-/
Take 2 aspirin, call me in the morning if pain persists. :-)
Footnotes:
[1] The grep in the 2nd command is simply to eliminate changes that
were just insertion/deletion of autoload cookies and to get rid
of "hunk headers" to give a better representation of amount of
real changes.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<steve(a)sxemacs.org>---|
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:59 p.m.
New subject: [Q] Re: [xemacs-base] Add byte-compiler warning control library
Steve Youngs writes:
Having `package-suppress' do _anything_ is the first step,
though.
The more I think about it, the more I think `package-suppress' itself
is a step backward. I'm having a very hard time seeing a genuine
use-case, and lots of theoretical ways for any definition to go wrong.
Is there really any excuse for either regexp-opt or easy-mmode to be
in core? It seems to me that this was just Ben being lazy.
Do you have other use-cases for package-suppress?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:45 p.m.
New subject: [Q] Re: [xemacs-base] Add byte-compiler warning control library
* Stephen J Turnbull <stephen(a)xemacs.org> writes:
Steve Youngs writes:
> Having `package-suppress' do _anything_ is the first step, though.
The more I think about it, the more I think `package-suppress'
itself is a step backward.
Quite possibly, yes.
Is there really any excuse for either regexp-opt or easy-mmode to
be in core?
Considering that you'd only be using the core versions of those if you
_didn't_ have the xemacs-base package installed, I'd have to say
"nope".
Do you have other use-cases for package-suppress?
There's no others in packages, and the only other I've heard of is
your suggestion originating from this thread. But as my initial query
showed, it can be handled in the lib itself easy enough.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<steve(a)sxemacs.org>---|
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6244
days inactive
6247
days old
5 comments
2 participants
participants (2)
-
Stephen J. Turnbull -
Steve Youngs