From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Using "Emacs Configure" **and** modifying .emacs Date: Sun, 13 Aug 2017 22:16:49 +0200 Message-ID: <868tin1avi.fsf@zoho.com> References: <1502373086.1171866.1069247696.71F9FED4@webmail.messagingengine.com> <0c6d8dc0-2308-4d80-b8b4-dc3f9cf7022a@default> <861sojuzpy.fsf@zoho.com> <877ey8k8c0.fsf@ankarstrom.se> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1502655467 29977 195.159.176.226 (13 Aug 2017 20:17:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 13 Aug 2017 20:17:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Aug 13 22:17:43 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dgzKP-0007Qx-Hd for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Aug 2017 22:17:41 +0200 Original-Received: from localhost ([::1]:58577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgzKW-0004n0-32 for geh-help-gnu-emacs@m.gmane.org; Sun, 13 Aug 2017 16:17:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgzJy-0004mL-W0 for help-gnu-emacs@gnu.org; Sun, 13 Aug 2017 16:17:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgzJt-0002CE-N2 for help-gnu-emacs@gnu.org; Sun, 13 Aug 2017 16:17:14 -0400 Original-Received: from [195.159.176.226] (port=36216 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dgzJt-0002AK-GT for help-gnu-emacs@gnu.org; Sun, 13 Aug 2017 16:17:09 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dgzJb-0004kJ-9q for help-gnu-emacs@gnu.org; Sun, 13 Aug 2017 22:16:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 93 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:ry3OYF7nBu3M0NH4OCsygBlGL90= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] 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:114019 Archived-At: John Ankarström wrote: > I don't think it's good to teach newcomers > that `setq' is better, because many user > options depend on custom setters that aren't > fired by a simple `setq'. Customize is more > portable and works with everything. If I'm allowed to deliberately misunderstand, nothing is more portable than the Lisp REPL, which is why there are so many dialects of Lisp :) I don't think Customize should be recommended for newcomers, as it is so frustrating and unpleasant to deal with, to the point they might never return for a second Emacs session, thinking the whole software is like that. >> (IMO, *no one* should use Customize, an even >> better way to keep Customize away from their >> init files.) > > I'll agree that the interface of Customize is > a bit clunky, but it's a good way to learn > what values are available for each option. This aspect is confusing at best. Because it should be apparent from the context if for example the value associated with a variable should be for example a string or an integer. And step two should be even less a concern, because all strings and digits should be valid! (Not all strings or digits need to be practical, of course. But people understand this. They don't assign crazy values.) So I never had any problem whatsoever with "what values are available"! If it (the variable) should take on a data structure to be processed, that needs to be in a specific form to work - say, a list of lists, this should be explained and exemplified in the docstring. Again, no problems! For example, with `nnmail-split-methods', the docstring says: Incoming mail will be split according to this variable. If you'd like, for instance, one mail group for mail from the "4ad-l" mailing list, one group for junk mail and one for everything else, you could do something like this: (setq nnmail-split-methods '(("mail.4ad" "From:.*4ad") ("mail.junk" "From:.*Lars\\|Subject:.*buy") ("mail.misc" ""))) As you can see, this variable is a list of lists, where the first element in each "rule" is the name of the group (which, by the way, does not have to be called anything beginning with "mail", "yonka.zow" is a fine, fine name), and the second is a regexp that nnmail will try to match on the header to find a fit. The second element can also be a function. In that case, it will be called narrowed to the headers with the first element of the rule as the argument. It should return a non-nil value if it thinks that the mail belongs in that group. The last element should always have "" as the regexp. This variable can also have a function as its value, and it can also have a fancy split method as its value. See `nnmail-split-fancy' for an explanation of that syntax. You can customize this variable. -- underground experts united http://user.it.uu.se/~embe8573