all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* log full path of magically loaded files?
@ 2013-03-25 16:49 danmbox
  2013-03-25 17:10 ` Alan Mackenzie
  2013-03-26 14:48 ` W. Greenhouse
  0 siblings, 2 replies; 7+ messages in thread
From: danmbox @ 2013-03-25 16:49 UTC (permalink / raw)
  To: help-gnu-emacs

I suspect emacs is loading the wrong version of some file (an autoloaded major mode). However, I see no relevant trace in *Messages* when opening a file that triggers the autoload.

If I (require 'some-mode) (from the *scratch* buffer), still nothing appears in *Messages*. If I (load "some-mode"), I finally get the useless

Loading some-mode... done.

(useless because I want the full path). Is there a way to enable more extensive logging of implicit emacs actions?


Thanks,
Dan


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

* Re: log full path of magically loaded files?
  2013-03-25 16:49 log full path of magically loaded files? danmbox
@ 2013-03-25 17:10 ` Alan Mackenzie
  2013-03-25 19:42   ` danmbox
  2013-03-26 14:48 ` W. Greenhouse
  1 sibling, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2013-03-25 17:10 UTC (permalink / raw)
  To: help-gnu-emacs

danmbox@gmail.com wrote:
> I suspect emacs is loading the wrong version of some file (an autoloaded
> major mode). However, I see no relevant trace in *Messages* when opening
> a file that triggers the autoload.

> If I (require 'some-mode) (from the *scratch* buffer), still nothing
> appears in *Messages*. If I (load "some-mode"), I finally get the useless

> Loading some-mode... done.

> (useless because I want the full path). Is there a way to enable more
> extensive logging of implicit emacs actions?

Not exactly what you're asking, but M-x locate-library <CR> some-mode <CR>
should help for this special case.

> Thanks,
> Dan

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: log full path of magically loaded files?
  2013-03-25 17:10 ` Alan Mackenzie
@ 2013-03-25 19:42   ` danmbox
  2013-03-25 19:56     ` Alan Mackenzie
  0 siblings, 1 reply; 7+ messages in thread
From: danmbox @ 2013-03-25 19:42 UTC (permalink / raw)
  To: help-gnu-emacs

> Not exactly what you're asking, but M-x locate-library <CR> some-mode <CR>
> 
> should help for this special case.

Thanks, that helps.

It's strange the *Messages* buffer doesn't record such events when it records so many other trivialities. I suppose I could look into wrapping (load) or such, but not if I can help it.

-- Dan


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

* Re: log full path of magically loaded files?
  2013-03-25 19:42   ` danmbox
@ 2013-03-25 19:56     ` Alan Mackenzie
  2013-03-25 20:50       ` danmbox
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2013-03-25 19:56 UTC (permalink / raw)
  To: help-gnu-emacs

danmbox@gmail.com wrote:
>> Not exactly what you're asking, but M-x locate-library <CR> some-mode <CR>
>> 
>> should help for this special case.

> Thanks, that helps.

> It's strange the *Messages* buffer doesn't record such events when it
> records so many other trivialities. I suppose I could look into wrapping
> (load) or such, but not if I can help it.

It's not all that strange.  *Messages* records the stream of predominantly
1-line messages which appear in the echo area.  It's not intended as a
general system log.  Too much uninteresting stuff in the echo area could
be distracting and a nuisance.  Usually the exact path of a loaded library
is uninteresting.

> -- Dan

-- 
Alan Mackenzie (Nuremberg, Germany).



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

* Re: log full path of magically loaded files?
  2013-03-25 19:56     ` Alan Mackenzie
@ 2013-03-25 20:50       ` danmbox
  2013-03-26  3:35         ` Barry Margolin
  0 siblings, 1 reply; 7+ messages in thread
From: danmbox @ 2013-03-25 20:50 UTC (permalink / raw)
  To: help-gnu-emacs

> It's not all that strange.  *Messages* records the stream of predominantly
> 1-line messages which appear in the echo area.  It's not intended as a
> general system log.  Too much uninteresting stuff in the echo area could
> be distracting and a nuisance.  Usually the exact path of a loaded library
> is uninteresting.

I'm not going to argue with "it is the way it is"; but the argument that an automagically triggered action is "uninteresting" and thus not to be logged (while a command explicitly issued by the user somehow deserves to be logged) isn't very convincing. Thanks anyway!

-- Dan


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

* Re: log full path of magically loaded files?
  2013-03-25 20:50       ` danmbox
@ 2013-03-26  3:35         ` Barry Margolin
  0 siblings, 0 replies; 7+ messages in thread
From: Barry Margolin @ 2013-03-26  3:35 UTC (permalink / raw)
  To: help-gnu-emacs

In article <5315d3ad-be2e-4ec9-9acb-87aa7d92bd71@googlegroups.com>,
 danmbox@gmail.com wrote:

> > It's not all that strange.  *Messages* records the stream of predominantly
> > 1-line messages which appear in the echo area.  It's not intended as a
> > general system log.  Too much uninteresting stuff in the echo area could
> > be distracting and a nuisance.  Usually the exact path of a loaded library
> > is uninteresting.
> 
> I'm not going to argue with "it is the way it is"; but the argument that an 
> automagically triggered action is "uninteresting" and thus not to be logged 
> (while a command explicitly issued by the user somehow deserves to be logged) 
> isn't very convincing. Thanks anyway!

One of the documented differences between load and require is that 
require doesn't display a message saying what it's doing. If it doesn't 
display anything, it won't go in *Messages*.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***


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

* Re: log full path of magically loaded files?
  2013-03-25 16:49 log full path of magically loaded files? danmbox
  2013-03-25 17:10 ` Alan Mackenzie
@ 2013-03-26 14:48 ` W. Greenhouse
  1 sibling, 0 replies; 7+ messages in thread
From: W. Greenhouse @ 2013-03-26 14:48 UTC (permalink / raw)
  To: help-gnu-emacs-mXXj517/zsQ

Dan,

danmbox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org writes:

> I suspect emacs is loading the wrong version of some file (an
> autoloaded major mode). However, I see no relevant trace in *Messages*
> when opening a file that triggers the autoload.
>
> If I (require 'some-mode) (from the *scratch* buffer), still nothing
> appears in *Messages*. If I (load "some-mode"), I finally get the
> useless
>
> Loading some-mode... done.
>
> (useless because I want the full path). Is there a way to enable more
> extensive logging of implicit emacs actions?

The `load-history' variable documents every `load' and `require' event
(and a lot else besides), with full paths, back to the initialization of
Emacs.

Since that's probably *too much* information, a quicker path to the
problem you're actually trying to tackle with relation to major modes is
M-x list-load-path-shadows, which shows you when the same library was
eligible to be loaded from more than one directory and some versions are
now being ignored due to the load-path setting (i.e. "shadowed").

Best,
Will

-- 
BOFH excuse #378:

Operators killed by year 2000 bug bite.




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

end of thread, other threads:[~2013-03-26 14:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-25 16:49 log full path of magically loaded files? danmbox
2013-03-25 17:10 ` Alan Mackenzie
2013-03-25 19:42   ` danmbox
2013-03-25 19:56     ` Alan Mackenzie
2013-03-25 20:50       ` danmbox
2013-03-26  3:35         ` Barry Margolin
2013-03-26 14:48 ` W. Greenhouse

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.