From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: How to quit? Date: Thu, 26 Feb 2015 19:33:52 -0800 (PST) Message-ID: <2e492143-7154-479b-90a7-0d4d05107b23@default> References: <87y4nm3svs.fsf@wmi.amu.edu.pl> <874mq89nur.fsf@debian.uxu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1425008075 13820 80.91.229.3 (27 Feb 2015 03:34:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Feb 2015 03:34:35 +0000 (UTC) To: Emanuel Berg , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Feb 27 04:34:23 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YRBh1-0001Ez-9i for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Feb 2015 04:34:23 +0100 Original-Received: from localhost ([::1]:33769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRBh0-0003F9-4X for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Feb 2015 22:34:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRBgi-00039P-6f for help-gnu-emacs@gnu.org; Thu, 26 Feb 2015 22:34:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YRBge-00022M-5t for help-gnu-emacs@gnu.org; Thu, 26 Feb 2015 22:34:04 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YRBgd-00022B-U2 for help-gnu-emacs@gnu.org; Thu, 26 Feb 2015 22:34:00 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1R3Xuve029629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Feb 2015 03:33:57 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1R3XrCg019663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2015 03:33:54 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id t1R3XqhN010677; Fri, 27 Feb 2015 03:33:53 GMT In-Reply-To: <874mq89nur.fsf@debian.uxu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:102914 Archived-At: > > But really you will find, I think, that > > commenting-out blocks of the file is the handiest. > > I bind `C-x C-;' to `comment-region', which comments > > or (with `C-u') uncomments the region, and which > > nests and unnests such commented blocks (unlike > > `comment-dwim'). >=20 > I don't like the idea of commenting out code blocks. > The code will be hard to read as code (as a comment!?) > with no font lock (or worse: the same color as the > "real" comments which are now drowned). It'll just be > bulky and in the way. I think you are perhaps missing the point of debugging an init file this way (binary search). You should not be trying to read the code that is commented out. Binary search is essentially blind, except for noticing the result of each test to inform the next division. You don't read any code. (And that is why many of us have learned its value the hard way, over and over. We feel that we are too clever for that.) Commenting and uncommenting is just a way of making the code invisible to evaluation. If you want to also make it invisible to yourself for some reason - e.g., if you are bothered by it being "bulky and in the way", or if you are tempted to "read [it] as code (as a comment!?)" - you can do that too (see, e.g., library `hide-comnts.el', http://www.emacswiki.org/emacs/download/hide-comnt.el). As for confusion with "real" comments - no such problem. That's the point of `comment-region', which nests and unnests correctly. This nesting behavior is similar to the behavior of Common Lisp block-commenting (envelopes of `#|' + `|#'). > I have a better idea, and that is for the OP to split > his init file into several files all dedicated a > specific area of configuration and/or extention. The > OP mentioned 900 lines of Elisp - myself, I use > several files and very few are longer than 100 lines > (those which are often has ambitious documentation > inline which makes for a huge bulk of lines). Meme combat, I'm afraid. My init file is so split. So what? I still use a binary search on it - and then, if necessary, on whichever library I discover is the culprit. No matter how finely you split your mass of code, or conversely how much you clump it together in a giant sack of spaghetti, a dumb, blind binary search can often be your friend. More often than you might think. > Besides many other advantages, in this specific > situation, one could load all the files from .emacs > (with `load-file') and then just comment out a single > line to not have a specific file loaded. Which single line? That's the point. Are you going to try each one in turn? Are you going to try to guess, based on your intelligent division of subject matter into sacks that are each "dedicated [to] a specific area of configuration and/or extention"? If so, then you are being clever. For this kind of search, you will (eventually) find that you are often being too clever. Dumb binary search will beat you to the punch much of the time, I'm afraid. If the answer were so obvious as to lead you to the culprit library & line right off the bat then there would be no question of how to proceed. No one would bother to ask how to debug their init file in such an obvious case. But when things are not so obvious (and when things you thought were obvious turn out not to be what you thought), binary search can be your friend. That's the point of using a binary search - in whatever file, however big or small it might be. *You don't know which line is the culprit*, whether that line loads another library or calculates the high tides at full moon at your location.