From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Fatal error 11: Segmentation Fault Date: Wed, 03 Apr 2019 07:30:19 +0200 Message-ID: <86ftqzhd04.fsf@zoho.eu> References: <86imvx5gyz.fsf@zoho.eu> <86ef6l5dwk.fsf@zoho.eu> <86a7h85ru5.fsf@zoho.eu> <865zrw55gm.fsf@zoho.eu> <5e7fb661-c090-4893-bcab-24ee4d96bea3@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="75852"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Apr 03 07:30:46 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBYU0-000JZe-H4 for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 07:30:44 +0200 Original-Received: from localhost ([127.0.0.1]:53644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBYTz-0007lB-Ib for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 01:30:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBYTm-0007l3-UO for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:30:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBYTl-0003Ki-8j for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:30:30 -0400 Original-Received: from [195.159.176.226] (port=41132 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBYTk-0003Ii-Gl for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:30:29 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hBYTi-000JAa-MW for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 07:30:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Cancel-Lock: sha1:C/o69XxzEKCTxxodfSzrv8Pe8GI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:119850 Archived-At: 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