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 01:54:01 +0200 Message-ID: <865zrw55gm.fsf@zoho.eu> References: <86imvx5gyz.fsf@zoho.eu> <86ef6l5dwk.fsf@zoho.eu> <86a7h85ru5.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="11626"; 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 01:54:35 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 1hBTEf-0002po-Ms for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2019 01:54:33 +0200 Original-Received: from localhost ([127.0.0.1]:39805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBTEe-0000h6-OT for geh-help-gnu-emacs@m.gmane.org; Tue, 02 Apr 2019 19:54:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBTES-0000h0-ML for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 19:54:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBTER-0001PD-GE for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 19:54:20 -0400 Original-Received: from [195.159.176.226] (port=35034 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBTER-0001Nq-72 for help-gnu-emacs@gnu.org; Tue, 02 Apr 2019 19:54:19 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hBTEL-0002PK-1F for help-gnu-emacs@gnu.org; Wed, 03 Apr 2019 01:54:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Cancel-Lock: sha1:mX0qdUAtbRAx/xexl37cQfcoj/8= 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:119839 Archived-At: Drew Adams wrote: >> If it is in my init files, how come it works >> once? I type this using Emacs. > > Wrong question, I think. The right question > is this: "If it _doesn't_ happen when > I _don't_ use my init file then what part of > my init file makes it happen?" My init should by definition not be able to cause this, because Elisp shouldn't be able to crash Emacs C style - or correct me if I'm wrong, by supplying an example which I'll evaluate immediately! (crash-emacs) ! So it is rather some binary module which can only be initiated once. This could be a clue as to get there faster. Just thought someone might know or think of something... > It doesn't matter, for this, whether "it > works once". What matters is that it > (apparently) _always_ works if you don't load > your init file and it (apparently) sometimes > does not work if you do load your init file. It works once. (kill-emacs), then 'emacs', or don't (kill-emacs), then 'emacs' (i.e. another Emacs instance) causes the crash every time. >> Besides, doing a "binary search" isn't so >> easy. Many files are interconnected. To mot >> load one file does mean commenting out >> `require's in lots'a others, as well as >> functions who uses their stuff, then >> functions that uses those functions, and >> so on. > > Not sure I understand your description there. I have all my Elisp in different files, a.el, b.el, ..., n.el, tho they are not named thus, of course. All those are in a directory (with subdirs), called "emacs-init". In ~/.emacs, there is a loop that checks for files in that directory tree, which then loads 'em all. So if I add n-plus-one.el, which happens all the time, I don't edit ~/.emacs, it loads the new file along with everything else automatically. Ain't it cool stuff? Well, in cases when binary search is called for, like this one, it is still sort'a cool in theory. Because I can just make a copy of the "emacs-init" directory, move the original one OOA, and then start removing files from the test directory. Right? In principle, that's right. In practice, like I said, the files are all interconnected with `provide' and `require'. If I remove one file, all files which require that file will have to be removed as well. Those, in turn, provide to other files which require THEM, and so on. It can still be done obviously, only it takes a lot of time and isn't mechanical work. > My init file and the many files it loads are > likely more ugly and convoluted than yours > (and no, I'm not proud/bragging about that). > But binary search still helps and is not > that hard. If by "convoluted" you mean interconnected (provide/require) then do tell how you do it. Commenting out stuff until many files are virtually empty but still provide/require each other? Anyway I start this now... Now, all we need is a little Energon and a lot of luck. [1] [1] http://www.dailyscript.com/scripts/transformers.html -- underground experts united http://user.it.uu.se/~embe8573