Glenn Morris writes:
> Glenn Morris wrote:
>
>> fresh Emacs instance. There's no reason the "package manager" could not
>> spawn a separate Emacs in batch-mode as a sub-job to do the compilation.
>
> Very lightly tested version:
This uses the Emacs executable on the exec path, which might not be
Glenn Morris wrote:
> the package has defined. Though you would have to trust the package not
> to do anything nasty.
Of course, you already have to trust it since byte-compiling can run
arbitrary code.
Stefan Monnier wrote:
> E.g. we could add to bytecomp.el the ability to force `require' to
> reload a package if it's not already loaded from the file that
> locate-library returns.
That will probably work fine most of the time, but what if a package is
restructed so that the feature names are di
Glenn Morris wrote:
>> This uses the Emacs executable on the exec path, which might not be the
>> correct one.
>
> Yes; I wondered if (car command-line-args) was a reliable way to find
> the actual name of the running Emacs binary?
Turns out I was looking for invocation-directory and invocation-n
Eli Zaretskii wrote:
> I think package.el should test with featurep whether a version of a
> package is already loaded, and refuse to load it into a running
> session, or at least display a warning to that effect, suggesting to
> restart Emacs.
Yes, that might be better.
Chong Yidong wrote:
> This uses the Emacs executable on the exec path, which might not be the
> correct one.
Yes; I wondered if (car command-line-args) was a reliable way to find
the actual name of the running Emacs binary?
>>> fresh Emacs instance. There's no reason the "package manager" could not
>>> spawn a separate Emacs in batch-mode as a sub-job to do the compilation.
>> Very lightly tested version:
> This uses the Emacs executable on the exec path, which might not be the
> correct one.
> I'm wary of making such
On Fri, Nov 25, 2011 at 04:31, Jambunathan K wrote:
>
> Stelian
>
>> I am sorry to be asking a stupid question, but then, wouldn't restart
>> Emacs fix the issue and have the new compiled org files loaded? In my
>> case, that didn't seem to happen either (even though load-library
>> showed org-com
Glenn
Glenn Morris writes:
> Glenn Morris wrote:
>
>> fresh Emacs instance. There's no reason the "package manager" could not
>> spawn a separate Emacs in batch-mode as a sub-job to do the
>> compilation.
I will let Stelian or any aggrieved future parties to test the patch.
[...context switch
> From: Glenn Morris
> Cc: Eli Zaretskii , 10...@debbugs.gnu.org,
> stelian.ia...@gmail.com
> Date: Thu, 24 Nov 2011 14:09:38 -0500
>
> I guess nobody ever expected the package manager to be used to load a
> different version of something that was already in Emacs.
Indeed. Because doing this
Stelian
> I am sorry to be asking a stupid question, but then, wouldn't restart
> Emacs fix the issue and have the new compiled org files loaded? In my
> case, that didn't seem to happen either (even though load-library
> showed org-compat to be from ELPA).
locate-library doesn't show what is *a
Stelian Iancu wrote:
> I am sorry to be asking a stupid question, but then, wouldn't restart
> Emacs fix the issue and have the new compiled org files loaded?
No, because the files get compiled with a mix of old and new code
loaded, so the compiled files are probably messed up. Restarting Emacs
w
On Thu, Nov 24, 2011 at 20:09, Glenn Morris wrote:
> Jambunathan K wrote:
>
>> When compiling with package manager, the compilation happens from within
>> a running Emacs session and very likely the "old" Org files are already
>> loaded in to the runtime "inadvertently" by the user either by looki
Glenn Morris wrote:
> fresh Emacs instance. There's no reason the "package manager" could not
> spawn a separate Emacs in batch-mode as a sub-job to do the compilation.
Very lightly tested version:
*** lisp/emacs-lisp/package.el 2011-11-20 03:48:53 +
--- lisp/emacs-lisp/package.el 2011-11-
Jambunathan K wrote:
> When compiling with package manager, the compilation happens from within
> a running Emacs session and very likely the "old" Org files are already
> loaded in to the runtime "inadvertently" by the user either by looking
> at the org agenda for the day or may be by just viewi
> Org Mode files certainly have no dependency rules in lisp/Makefile.in.
The Makefile - in devel repo of Orgmode - does define rules. Read on ...
> So the question why the problem does not happen while compiling Org in
> Emacs remains.
I believe the way the files are compiled makes a substantia
> From: Jambunathan K
> Date: Thu, 24 Nov 2011 17:42:38 +0530
> Cc: emacs-orgmode@gnu.org, Stelian Iancu
>
> 1. While building via Makefile, there is an implicit dependency that is
> *enforced* via make rules and files with macro definitions are compiled
> ahead of their consumers.
That's not t
17 matches
Mail list logo
