unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* eval, load and -l
@ 2016-07-05 11:42 Stephen Berman
  2016-07-05 14:00 ` Clément Pit--Claudel
  2016-07-05 14:52 ` Eli Zaretskii
  0 siblings, 2 replies; 5+ messages in thread
From: Stephen Berman @ 2016-07-05 11:42 UTC (permalink / raw)
  To: emacs-devel

If I understand the Emacs and Lisp reference manuals correctly, I expect
that, when I have a file foo.el containing Lisp code, the following
procedures should produce the same results:

1. emacs -Q
   C-x C-f foo.el RET
   M-x eval-buffer RET

2. emacs -Q
   M-x load-file RET foo.el RET

3. emacs -Q -l foo.el

But I have code where the result of doing 1 or 2 differs from the result
of doing 3.  This is the sexp attached to this posting:

http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00154.html

As I noted there, when I evaluate the code in a running Emacs session,
i.e. as in 1 or 2, I see frame-widening; but when I load the code by
doing 3, there is no frame-widening.  Is this difference expected, and
if so could someone point me to the relevant documentation or part of
the code that makes the difference?

Steve Berman



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eval, load and -l
  2016-07-05 11:42 eval, load and -l Stephen Berman
@ 2016-07-05 14:00 ` Clément Pit--Claudel
  2016-07-05 14:52 ` Eli Zaretskii
  1 sibling, 0 replies; 5+ messages in thread
From: Clément Pit--Claudel @ 2016-07-05 14:00 UTC (permalink / raw)
  To: emacs-devel


[-- Attachment #1.1: Type: text/plain, Size: 338 bytes --]

On 2016-07-05 07:42, Stephen Berman wrote:
> 1. emacs -Q
>    C-x C-f foo.el RET
>    M-x eval-buffer RET
> 
> 2. emacs -Q
>    M-x load-file RET foo.el RET

If foo.el uses load-file-name in any way (for example to find the path to the current file and load other resources), then these two procedures won't do the same thing.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eval, load and -l
  2016-07-05 11:42 eval, load and -l Stephen Berman
  2016-07-05 14:00 ` Clément Pit--Claudel
@ 2016-07-05 14:52 ` Eli Zaretskii
  2016-07-05 15:37   ` Stephen Berman
  1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2016-07-05 14:52 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Tue, 05 Jul 2016 13:42:13 +0200
> 
> If I understand the Emacs and Lisp reference manuals correctly, I expect
> that, when I have a file foo.el containing Lisp code, the following
> procedures should produce the same results:
> 
> 1. emacs -Q
>    C-x C-f foo.el RET
>    M-x eval-buffer RET
> 
> 2. emacs -Q
>    M-x load-file RET foo.el RET
> 
> 3. emacs -Q -l foo.el

No, item 3 will always be different from the other two.

> But I have code where the result of doing 1 or 2 differs from the result
> of doing 3.

As expected.  In general, everything done by Emacs during startup
might yield different results, because the processing of the command
line and the init files is intertwined with starting a session and
initializing the various sub-systems.  The root cause of all that
complexity is that init files include customizations, some of which
need to be applied before Emacs creates some objects, some after, and
some both before and after.

That is why, for example, evaluating your (or someone else's) .emacs
in a running session doesn't produce identical results as the same
file processed during startup.

> http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00154.html
> 
> As I noted there, when I evaluate the code in a running Emacs session,
> i.e. as in 1 or 2, I see frame-widening; but when I load the code by
> doing 3, there is no frame-widening.  Is this difference expected

Yes, at least in principle.

> and if so could someone point me to the relevant documentation or
> part of the code that makes the difference?

The order of things done during startup is documented in "Startup
Summary" in the ELisp manual.  The --load command-line argument is
processed in item 21, and then item 26 we recompute frame and window
parameters and other related settings.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eval, load and -l
  2016-07-05 14:52 ` Eli Zaretskii
@ 2016-07-05 15:37   ` Stephen Berman
  2016-07-05 16:40     ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Berman @ 2016-07-05 15:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On Tue, 05 Jul 2016 17:52:23 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Tue, 05 Jul 2016 13:42:13 +0200
>> 
>> If I understand the Emacs and Lisp reference manuals correctly, I expect
>> that, when I have a file foo.el containing Lisp code, the following
>> procedures should produce the same results:
>> 
>> 1. emacs -Q
>>    C-x C-f foo.el RET
>>    M-x eval-buffer RET
>> 
>> 2. emacs -Q
>>    M-x load-file RET foo.el RET
>> 
>> 3. emacs -Q -l foo.el
>
> No, item 3 will always be different from the other two.
>
>> But I have code where the result of doing 1 or 2 differs from the result
>> of doing 3.
[...]
>> http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00154.html
>> 
>> As I noted there, when I evaluate the code in a running Emacs session,
>> i.e. as in 1 or 2, I see frame-widening; but when I load the code by
>> doing 3, there is no frame-widening.  Is this difference expected
>
> Yes, at least in principle.
>
>> and if so could someone point me to the relevant documentation or
>> part of the code that makes the difference?
>
> The order of things done during startup is documented in "Startup
> Summary" in the ELisp manual.  The --load command-line argument is
> processed in item 21, and then item 26 we recompute frame and window
> parameters and other related settings.

After Martin's reply to the above-referenced post made it clear that the
issue is related to the Gtk+ menu bar, it occurred to me that the
difference between 1/2 and 3 may be that with -l, the file is loaded
before the menu bar is created, which would account for why there is no
frame-widening in that case.  However, according to the Info node you
cite, the menu bar is created at step 9, well before -l is processed.
Can the recomputing in step 26 (or 27?) change the menu bar?  Yet step
26 only refers to modifications specified in the init files, which
doesn't seem relevant to this case.  Hmm.

Steve Berman



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: eval, load and -l
  2016-07-05 15:37   ` Stephen Berman
@ 2016-07-05 16:40     ` Eli Zaretskii
  0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2016-07-05 16:40 UTC (permalink / raw)
  To: Stephen Berman; +Cc: emacs-devel

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: emacs-devel@gnu.org
> Date: Tue, 05 Jul 2016 17:37:01 +0200
> 
> Can the recomputing in step 26 (or 27?) change the menu bar?

It can resize the frame, I think.  (27 runs a hook, so it cannot
possibly be part of the issue here.)

> Yet step 26 only refers to modifications specified in the init
> files, which doesn't seem relevant to this case.

They are relevant, because they also change the frame defaults.

But I didn't trace into the code, so maybe there's some other factor
in this specific case.  I was just explaining why --load should be
expected to produce different results in general.



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-07-05 16:40 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-07-05 11:42 eval, load and -l Stephen Berman
2016-07-05 14:00 ` Clément Pit--Claudel
2016-07-05 14:52 ` Eli Zaretskii
2016-07-05 15:37   ` Stephen Berman
2016-07-05 16:40     ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).