[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added
From: |
Drew Adams |
Subject: |
RE: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added |
Date: |
Sat, 8 Oct 2016 14:58:47 +0000 (UTC) |
> >> I was referring to a user --
> >> whether developer or not -- using a release version of Emacs and that
> >> potentially doesn't even want to use package.el to install additional
> >> packages. If we stick to the Emacs directory/file layout, it is a
> >> unified layout that gets presented to her. Where distictions between
> >> core libraries and ELPA core packages aren't visible at that level.
> >> That would be worth trying to achieve, I think. (And in fact is how the
> >> directory/files organization looks like in the current release, IIUC.)
> >
> > Just what I was saying. I would like to be able to access
> > and use the distributed source files the same as in the
> > past, without needing to use package.el.
>
> We are talking cross purposes, I think.
Not that I can see.
> There are two means to "use package.el". One is "use some of the
> functions in the package.el file", and the other is "have the user
> interact either through the API or through the UI with package.el".
It should be clear that I am talking about the latter - I do
not want to _have_ to do that.
> My patch would mean that, during initialization the former would be
> happening -- that is, Emacs would be using some package.el functions.
> But not that latter -- as a user you would not need to interact with it.
>
> Actually, your emacs is already doing the former (initializing
> packages), even if there are no packages by default.
Again: Just what I was saying.
I too am talking about what _users_ do, need to do, and
want to do.
I do not object (in principle - the devil might be in the
resulting implementation) to Emacs using package.el under
the covers. But see next...
I would also like to find the Lisp sources distributed with
Emacs (meaning at least those that have been distributed
in the past and are still part of Emacs) still all under
.../lisp/.
If "under the covers" means only that I do not need to
invoke package.el functions directly, but it also means that
I cannot find (grep) all distributed Emacs Lisp files living
peacefully under .../lisp/, that does not leave me a happy
camper, a priori.
I've been clear, I think, that I do not want to _need_ to
use package.el. Myself. As a user. AND I would like to
just grep .../lisp/ and its subdirs, to find Emacs Lisp code.
That's all. To me, the latter is part of not needing to
use package.el.
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/03
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/08
- RE: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Drew Adams, 2016/10/08
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Colin Baxter, 2016/10/08
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/09
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/09
- RE: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Drew Adams, 2016/10/09
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/12