From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Edward Welbourne Newsgroups: gmane.emacs.bugs Subject: Re: customize Date: Thu, 11 Jul 2002 18:29:49 +0200 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: References: <200207111201.g6BC1OM16938@aztec.santafe.edu> Reply-To: eddy@opera.no NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1026404968 6678 127.0.0.1 (11 Jul 2002 16:29:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 11 Jul 2002 16:29:28 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Sgop-0001jb-00 for ; Thu, 11 Jul 2002 18:29:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17Sgpa-0007Us-00; Thu, 11 Jul 2002 12:30:14 -0400 Original-Received: from pat.opera.com ([193.69.113.22] helo=whorl.intern.opera.no) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17SgpC-0007Tq-00; Thu, 11 Jul 2002 12:29:50 -0400 Original-Received: from eddy by whorl.intern.opera.no with local (Exim 3.35 #1 (Debian)) id 17SgpB-0003rO-00; Thu, 11 Jul 2002 18:29:49 +0200 Original-To: rms@gnu.org In-Reply-To: <200207111201.g6BC1OM16938@aztec.santafe.edu> (message from Richard Stallman on Thu, 11 Jul 2002 06:01:24 -0600 (MDT)) Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:2635 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:2635 (I've calmed down now.) > Can you tell us precisely how to reproduce this? With that > information, we could fix the problem. I'll exit session in a bit and devote a session, with a trivial .emacs, to doing nothing *but* a bout of customize; then I'll be able to separate the mess from the context. For now, answers to some sensible questions you asked: >> turning off the configuration option for it merely leaves a >> (custom-set-faces '(trailing-whitespace ((t nil)))) in my .emacs >> rather than removing the entire reference; > Is this a problem? Does anything bad happen as a result of this? Yes. All customize-cruft is appended to ~/.emacs, while my own config is accessed via a line early in the file (which loads it from some byte-compiled elisp in a conveniently out-of-the-way directory). Thus my own config can't control the face, because customize insists on having the last word (and saying: suppress this face) despite my best efforts to get the fancy GUI to understand that I no longer want customize to have anything to do with the setting of this face. [Aside: the line of my .emacs which loads my own elisp has to be preceded by one which modifies my load-path. Ideally, I'd skip this by using the environment variable EMACSLOADPATH; however, setting that causes load-path to *not* include the many things in my load-path by default ... unless I put them in my EMACSLOADPATH, which would require me to change my .bash_profile when the system default changes. In the TEX* packages, the corresponding environment variables provide for ending in : to mean `and all the stuff that would be here by default'. IWBNI the same happened with EMACSLOADPATH. But I digress.] >> I'm clearly going to have to exit from emacs and vi my .emacs. > This seems to assume that if you restart Emacs the new session will > have some sort of problems, but you did not report having actually > done so and observed such problems. Is this an observation or a > guess? Had I restarted my emacs without editing .emacs in between, I'd have been left with the unwanted consequences of ((t nil)) above. Technically we can call this a guess, as I didn't do the experiment; but I can read a .emacs file and predict what it'll do based on what it's specified to do. So I needed to remove the offending customize lines from my .emacs before next session, since I wanted the face to be as specified in my own elisp (which I can, for instance, edit during sessions, re-run when I like, keep in some other file than .emacs, under source management if I want, oh, you know, it's *mine* that way, not controlled `for me' by something I neither understand nor trust). Since the customize section (i.e. all but the first two lines) of my .emacs is interspersed with repeated comments about not editing these lines by hand or etc., the only way I can get rid of them is by using *some other editor* while no emacs session is alive. This, naturally, is taking it on faith that a fresh emacs session only knows about any prior sessions via their effects in .emacs, so I can get away with editing .emacs by hand as long as no emacs is running. It may be that I can, in fact, get away with editing these lines using emacs; however, I tend to take `do not' advice at face value ... Later, I'll get round to taking `do this' instructions at face value, and produce a rather more cogent bug report. However, it remains that *every* time I've used customize I've ended up getting these perverse messages about the elisp stack ... and refusal to do things I ask emacs to do. The ensuing red mist is rather bad for cogency. Meantime, back to processing the information just gleaned via the kind offices of M-x grep-find (which I only met recently, having previously used M-x compile and a messy command-line) and rejoicing in the benefits of -print0 and -0, previously unfamiliar but *very* useful. Thanks for tools that (mostly) do what I want, Eddy.