From: Francesco Potorti` <pot@gnu.org>
Cc: eliz@is.elta.co.il, emacs-devel@gnu.org, handa@m17n.org
Subject: Re: How is the 21.2.90 pretest going?
Date: Wed, 09 Oct 2002 11:43:09 +0200 [thread overview]
Message-ID: <E17zDMz-0008UF-00@pot.cnuce.cnr.it> (raw)
In-Reply-To: <E17zAKu-0000GU-00@fencepost.gnu.org> (rms@gnu.org)
rms:
> What is the bug in define-minor-mode in RC?
Handa's mail explains it:
> workaround. I've just installed it in RC.
>
> 2002-10-08 Kenichi Handa <handa@m17n.org>
>
> * international/ucs-tables.el (unify-8859-on-encoding-mode): Set
> :init-value to nil, and calls (unify-8859-on-encoding-mode 1)
> later.
>
> One bad result is that, the customize buffer of this
> variable says as this:
>
> Unify 8859 On Encoding Mode: Hide Toggle on (non-nil)
> State: this option has been changed outside the customize buffer.
>
> And, if you click "Erase Customization", the value is reset
> to nil.
>
> Once it is decided that this variable is removed and we
> always enable unify-8859-on-encoding, this problem
> disappears. It disappears also when define-minor-mode or
> eval-after-load is fixed in RC.
Francesco Potortì:
> Probably define-minor-mode should be fixed in RC before releasing 21.3.
> I found the following files mentioning a problem with that:
> image-file.el
> jka-compr.el
> minibuf-eldef.el
> mwheel.el
> recentf.el
In those file I can read a comment like this:
;;; Note this definition must be at the end of the file, because
;;; `define-minor-mode' actually calls the mode-function if the
;;; associated variable is non-nil, which requires that all needed
;;; functions be already defined. [This is arguably a bug in d-m-m]
;;;###autoload
(define-minor-mode auto-image-file-mode
This is not the same problem as described by Handa, but it seems to be
related. Sorry for not being more precise, but the inners of
make-minor-mode are at the edge of my elisp literacy, and I would need a
deeper study to understand it completely.
Here is a more complete description of the issue from a previous mail of
Handa's:
> In RC, if both :global and :init-value of define-minor-mode
> is non-nil, define-minor-mode calls eval-after-load as below:
> ;; If the mode is global, call the function according to the default.
> ,(if (and globalp (null init-value))
> `(if (and load-file-name ,mode)
> (eval-after-load load-file-name '(,mode 1)))))))
> And, eval-after-load calls load-symbol-file-load-history,
> and load-symbol-file-load-history loads "fns-XX.YY.ZZ.el".
> But, at bootstrapping time, as "fns-XX.YY.ZZ.el" is not yet
> generated, it signals an error. It may not be a bug of
> define-minor-mode, but a bug of eval-after-load or
> load-symbol-file-load-history. In any case, it should be
> fixed at somewhere.
> In HEAD instead, define-minor-mode now has this code:
> ;; If the mode is global, call the function according to the default.
> ,(if globalp
> `(if (and load-file-name (not (equal ,init-value ,mode)))
> (eval-after-load load-file-name '(,mode (if ,mode 1 -1))))))))
> As (equal ,init-value ,mode) is t at bootstrapping time,
> eval-after-load is not called, thus the above error is not
> revealed. But, as the result, it is now the programmer's
> responsibility to make the XXX-minor-mode's status
> synchronize to the value of XXX-minor-mode, i.e., we must do:
> (define-minor-mode 'XXX-mode "" :global t :init-value t ...)
> (XXX-mode 1)
> I don't argue that this new behaviour is good or bad. At
> least, it is not a bug if properly described in the
> docstring of define-minor-mode.
next prev parent reply other threads:[~2002-10-09 9:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <15724.59040.131183.942957@mosaics.wustl.edu>
[not found] ` <7458-Wed28Aug2002185639+0300-eliz@is.elta.co.il>
[not found] ` <E17k5iV-00060B-00@pot.cnuce.cnr.it>
[not found] ` <7458-Wed28Aug2002201929+0300-eliz@is.elta.co.il>
[not found] ` <E17kKNQ-0000VD-00@pot.cnuce.cnr.it>
[not found] ` <3405-Fri30Aug2002211052+0300-eliz@is.elta.co.il>
[not found] ` <E17kwmx-000188-00@pot.cnuce.cnr.it>
[not found] ` <8011-Sat31Aug2002090148+0300-eliz@is.elta.co.il>
[not found] ` <E17whdo-0004gz-00@pot.cnuce.cnr.it>
[not found] ` <3791-Wed02Oct2002233515+0200-eliz@is.elta.co.il>
2002-10-08 8:18 ` How is the 21.2.90 pretest going? Francesco Potorti`
2002-10-08 11:05 ` Kenichi Handa
2002-10-08 11:26 ` Francesco Potorti`
2002-10-09 6:28 ` Richard Stallman
2002-10-09 9:43 ` Francesco Potorti` [this message]
2002-10-09 15:53 ` Stefan Monnier
2002-10-11 4:41 ` Richard Stallman
2002-10-11 19:13 ` Stefan Monnier
2002-10-09 6:29 ` Richard Stallman
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=E17zDMz-0008UF-00@pot.cnuce.cnr.it \
--to=pot@gnu.org \
--cc=eliz@is.elta.co.il \
--cc=emacs-devel@gnu.org \
--cc=handa@m17n.org \
/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.