all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
Cc: Juri Linkov <juri@jurta.org>,
	teirllm@dms.auburn.edu, emacs-devel@gnu.org
Subject: Re: Problems with whole buffer Custom functions.
Date: Mon, 23 Jan 2006 19:04:43 +0100	[thread overview]
Message-ID: <43D51ABB.9020802@gmx.at> (raw)
In-Reply-To: <E1F0jFy-00063z-MG@fencepost.gnu.org>

 > 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.

  parent reply	other threads:[~2006-01-23 18:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-13  3:32 Problems with whole buffer Custom functions Luc Teirlinck
2006-01-17  1:27 ` Juri Linkov
2006-01-17  4:13   ` Luc Teirlinck
2006-01-17 21:54     ` Juri Linkov
2006-01-18  0:29       ` Kevin Rodgers
2006-01-23  0:10       ` Richard M. Stallman
2006-01-22  0:45     ` Juri Linkov
2006-01-22  1:46       ` Luc Teirlinck
2006-01-23  1:42         ` Juri Linkov
2006-01-24 16:46           ` Richard M. Stallman
2006-01-24 21:45             ` Juri Linkov
2006-01-24 23:11               ` Lennart Borgman
2006-01-25  7:55                 ` Juri Linkov
2006-01-25 15:45               ` Richard M. Stallman
2006-01-22  1:55       ` Luc Teirlinck
2006-01-23  1:43         ` Juri Linkov
2006-01-22  0:45     ` Juri Linkov
2006-01-22 17:44       ` Richard M. Stallman
2006-01-19 17:44   ` Richard M. Stallman
2006-01-22  0:45     ` Juri Linkov
2006-01-22 17:44       ` Richard M. Stallman
2006-01-22 21:28         ` Drew Adams
2006-01-23  1:47           ` Juri Linkov
2006-01-23  2:58             ` Drew Adams
2006-01-23  6:17               ` Juri Linkov
2006-01-24 16:47           ` Richard M. Stallman
2006-01-23  1:47         ` Juri Linkov
2006-01-24 16:46           ` Richard M. Stallman
2006-01-23 18:04         ` martin rudalics [this message]
2006-01-25  3:28           ` Richard M. Stallman
2006-01-22 17:44       ` Richard M. Stallman
  -- strict thread matches above, loose matches on Subject: below --
2006-01-25  8:58 LENNART BORGMAN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D51ABB.9020802@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    --cc=teirllm@dms.auburn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.