From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: fancy-splash-screen customize group... Date: Wed, 7 Dec 2005 21:21:35 -0600 (CST) Message-ID: <200512080321.jB83LZv04680@raven.dms.auburn.edu> References: <200512072349.jB7Nn5fB031485@brains.moreideas.ca> <878xuwwdp4.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1134012251 17545 80.91.229.2 (8 Dec 2005 03:24:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2005 03:24:11 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 08 04:24:08 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EkCNG-0001xS-88 for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2005 04:23:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkCNW-0008L9-CM for ged-emacs-devel@m.gmane.org; Wed, 07 Dec 2005 22:23:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EkCNJ-0008JM-1K for emacs-devel@gnu.org; Wed, 07 Dec 2005 22:23:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EkCNH-0008Ij-CB for emacs-devel@gnu.org; Wed, 07 Dec 2005 22:23:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EkCNH-0008Ig-8C for emacs-devel@gnu.org; Wed, 07 Dec 2005 22:23:15 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EkCOE-0005Kc-8H for emacs-devel@gnu.org; Wed, 07 Dec 2005 22:24:14 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id jB83Mujq001158; Wed, 7 Dec 2005 21:22:56 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id jB83LZv04680; Wed, 7 Dec 2005 21:21:35 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: juri@jurta.org In-reply-to: <878xuwwdp4.fsf@jurta.org> (message from Juri Linkov on Thu, 08 Dec 2005 03:00:04 +0200) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Wed, 07 Dec 2005 21:22:56 -0600 (CST) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:47197 Archived-At: >>From my previous message: One should under no circumstances encourage anybody, certainly not beginners, to use these buttons. They are completely untested: nobody uses them. Their code is fragile. Any apparently unrelated change in Custom can easily badly break them badly without warning (and nobody will notice, because nobody uses them). Let me give one example of what I mean with: Their code is fragile. Any apparently unrelated change in Custom can easily badly break them badly without warning These whole buffer buttons do not operate on options whose value is "hidden". That is, options whose value is hidden will not be saved, set or reset by these buttons. A while ago somebody suggested that this was counterintuitive and that beginners would expect them to operate on options with hidden values. It was suggested by some to make the whole buffer buttons operate on such options. Fortunately, that was never implemented. The correct functioning of the whole buffer buttons relies heavily on the fact that they do not operate on options whose values is hidden. This is not at all obvious, unless you study the code carefully: nobody involved in the discussion about these options apparently realized it. (I did not realize it myself at the time.) If the suggested change would have been implemented, the whole buffer buttons would have started to operate on child groups and recursively on their "offspring" groups. The results would have been disastrous to users of these buttons. In general, any change in the way hidden values are implemented or treated could easily badly mess up these whole buffer buttons in a very non-obvious way. Sincerely, Luc.