From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Problems with whole buffer Custom functions. Date: Mon, 23 Jan 2006 19:04:43 +0100 Message-ID: <43D51ABB.9020802@gmx.at> References: <200601130332.k0D3WKo16648@raven.dms.auburn.edu> <87psmrr3vg.fsf@jurta.org> <877j8tcsyt.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1138047864 17263 80.91.229.2 (23 Jan 2006 20:24:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2006 20:24:24 +0000 (UTC) Cc: Juri Linkov , teirllm@dms.auburn.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 21:24:21 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F18DX-0004ZQ-H7 for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 21:23:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F17xe-00064Z-8g for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 15:06:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F165v-0004Dw-G4 for emacs-devel@gnu.org; Mon, 23 Jan 2006 13:07:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F165t-0004DB-P3 for emacs-devel@gnu.org; Mon, 23 Jan 2006 13:07:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F165s-0004D5-FK for emacs-devel@gnu.org; Mon, 23 Jan 2006 13:07:09 -0500 Original-Received: from [213.165.64.21] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1F16Ae-0005iO-B2 for emacs-devel@gnu.org; Mon, 23 Jan 2006 13:12:04 -0500 Original-Received: (qmail invoked by alias); 23 Jan 2006 18:04:20 -0000 Original-Received: from N780P004.adsl.highway.telekom.at (EHLO [62.47.41.100]) [62.47.41.100] by mail.gmx.net (mp036) with SMTP; 23 Jan 2006 19:04:20 +0100 X-Authenticated: #14592706 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en Original-To: rms@gnu.org In-Reply-To: X-Y-GMX-Trusted: 0 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:49452 Archived-At: > Instead I think it should preserve the ordinary undo list when you set > the variable. Currently, setting the variable discards the undo list, > which is more or less a bug. Undo in customization buffers is peculiar in other ways as well: 1. With emacs -Q do M-x customize-group RET paren-showing-faces RET, show both faces, and set the background of `show-paren-match' to "turquoise1" and the background of `show-paren-mismatch' to "purple1". Doing C-_ twice will now get you "No further undo information" - you can't undo the change to `show-paren-match'. Now change the face of `show-paren-match' to "turquoise" and that of `show-paren-mismatch' to "purple" and do C-_ twice again. This time both modifications are undone. Hence whether a modification can be undone may depend on whether this or another modification is the first editing change for a specific option. 2. With emacs -Q do M-x customize-group RET paren-showing-faces RET, show the `show-paren-match' face, set the background of `show-paren-match' to "paleturquoise", and do C-_. At this moment point is somewhere left of the foreground color checkbox. The reason for this is that editing also changes some magic text from "STANDARD." to "EDITED, shown value does not take effect until you set or save it.". This modification is, however, not recorded in `buffer-undo-list' and the buffer position recorded before editing started becomes invalid with respect to the actual buffer contents. 3. With emacs -Q do M-x customize-group RET paren-showing-faces RET, show the `show-paren-mismatch' face, set the background of `show-paren-mismatch' to "mediumpurple4", do C-_, then C-f (to make the next undo a redo), and C-_. At this moment the line of the background color reads as [X] Background: mediumpurple4mple) It's a mildly amusing exercise to erase your customization buffer with an appropriate sequence of undos and redos. One culprit here is the mechanism adjusting field sizes in `widget-after-change'. On the other hand, wid-edit uses `before-change-functions' to detect whether the user attempts to "change text outside editable field". The corresponding check in `widget-before-change', however, is performed if and only if `inhibit-read-only' is nil. And `primitive-undo' sets this to t. Hence the undo / redo mechanism obtains control over non-editable parts of the customization buffer.