From: Emanuel Berg <moasenwood@zoho.eu>
To: help-gnu-emacs@gnu.org
Subject: Re: Fatal error 11: Segmentation Fault
Date: Wed, 03 Apr 2019 07:30:19 +0200 [thread overview]
Message-ID: <86ftqzhd04.fsf@zoho.eu> (raw)
In-Reply-To: 5e7fb661-c090-4893-bcab-24ee4d96bea3@default
Drew Adams wrote:
> If Emacs never crashes when you don't load
> your init file then something in your init
> file leads to it crashing. There's no way
> around that. [...] Only when you use your
> init file, right? [...] But if you can make
> Emacs crash without your init file, then put
> that recipe in a report
Comments: 0
> You do not need to explicitly require/load
> files that are required by other files that
> you load, as I'm sure you know. So presumably
> you loop only over the files you need to
> explicitly load. They will load the files
> they require.
I like to explicitly `require' everything and
anything any and all file need, every time,
then byte compile everything.
> "Remove" (comment out or don't include in
> your loading loop) only files that you need
> explicitly to load, not files that get loaded
> by those files. Your loop should do
> that anyway.
Again, remove one file, ~10 other files report
errors because they rely on that file.
Remove them, ~10*10 files report errors.
Binary search really is a poor choice for this
kind'a situation. It is not a list of `setq's
that do a bunch of configs independently of
each other. It is a 496 `defun's that rely on
each other to work, in 116 different files,
with 279 `require' and 62 `provide'!
> What's the alternative? Trying to reason
> about all of your code at once? Trying to
> guess what you might have changed recently
> that introduced a new problem? Tweaking this
> or that, based on some intuition?
The alternative is to *think*. The Elisp
couldn't have done it without some external
part. What is external?
- my Emacs-zsh-tmux-X stuff
- Emacs-w3m (3rd party, installed from the
distros repos)
- the packs from [M]ELPA - well, they are
external in one sense, but I always
thought them just even more Elisp, so I'm
surprised the solution was the placement
of `package-initialize' - it might has
something to do with the byte-compiler as
well, tho that doesn't make sense (?)
either. Intuition, as you say.
Investigating...
- something else?
And speaking of the byte-compiler, why didn't
it tell me about this?
Also, it could have told me about
"digit-char-p" (which I discovered should be
`cl-digit-char-p' [1], only because there was
a (require 'cl-lib) at the top of the file! [2]
[1] http://lists.gnu.org/archive/html/help-gnu-emacs/2019-04/msg00001.html
[2] http://user.it.uu.se/~embe8573/emacs-init/negative-subtraction.el
--
underground experts united
http://user.it.uu.se/~embe8573
next prev parent reply other threads:[~2019-04-03 5:30 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 1:33 Fatal error 11: Segmentation Fault Emanuel Berg
2019-04-02 2:39 ` Emanuel Berg
2019-04-02 2:48 ` Drew Adams
2019-04-02 15:50 ` Emanuel Berg
2019-04-02 16:27 ` Drew Adams
2019-04-02 23:54 ` Emanuel Berg
2019-04-03 1:37 ` Drew Adams
2019-04-03 5:30 ` Emanuel Berg [this message]
2019-04-03 6:47 ` Emanuel Berg
2019-04-03 7:08 ` Eli Zaretskii
2019-04-03 7:49 ` Emanuel Berg
2019-04-03 8:18 ` tomas
2019-04-03 10:51 ` Using 'git bisect' to pinpoint errors in .emacs. Was: " Vegard Vesterheim
2019-04-03 11:14 ` Eli Zaretskii
2019-04-03 12:47 ` Vegard Vesterheim
2019-04-03 14:48 ` Emanuel Berg
2019-04-03 12:14 ` Skip Montanaro
2019-04-03 12:30 ` Eli Zaretskii
2019-04-03 14:52 ` Emanuel Berg
2019-04-03 15:41 ` Eli Zaretskii
2019-04-03 15:47 ` Emanuel Berg
2019-04-03 14:35 ` Emanuel Berg
2019-04-04 7:40 ` Vegard Vesterheim
2019-04-03 14:34 ` Emanuel Berg
2019-04-03 16:29 ` tomas
2019-04-03 17:06 ` Drew Adams
2019-04-03 19:19 ` tomas
2019-04-03 17:41 ` Robert Thorpe
2019-04-03 21:03 ` Emanuel Berg
2019-04-03 21:07 ` Robert Thorpe
2019-04-03 21:16 ` Emanuel Berg
2019-04-03 20:56 ` Emanuel Berg
2019-04-02 17:14 ` Óscar Fuentes
2019-04-02 23:56 ` Emanuel Berg
2019-04-03 0:05 ` Emanuel Berg
2019-04-03 0:13 ` Emanuel Berg
2019-04-03 1:20 ` Óscar Fuentes
2019-04-03 1:28 ` Óscar Fuentes
2019-04-03 2:33 ` Emanuel Berg
2019-04-03 2:39 ` Emanuel Berg
2019-04-03 4:47 ` Emanuel Berg
2019-04-03 5:23 ` Eli Zaretskii
2019-04-03 5:31 ` Emanuel Berg
2019-04-03 5:56 ` Eli Zaretskii
2019-04-03 6:48 ` Emanuel Berg
2019-04-03 6:59 ` Eli Zaretskii
2019-04-03 7:51 ` Emanuel Berg
2019-04-03 8:12 ` Eli Zaretskii
2019-04-03 14:21 ` Emanuel Berg
2019-04-03 14:36 ` Eli Zaretskii
2019-04-03 14:57 ` Emanuel Berg
2019-04-03 15:48 ` Eli Zaretskii
2019-04-03 21:05 ` Emanuel Berg
2019-04-04 12:51 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86ftqzhd04.fsf@zoho.eu \
--to=moasenwood@zoho.eu \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.