all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Mauger <mmaug@yahoo.com>
Subject: Re: Customizing recentf
Date: Tue, 29 Aug 2006 23:09:45 +0000 (UTC)	[thread overview]
Message-ID: <loom.20060830T001252-230@post.gmane.org> (raw)
In-Reply-To: jwvveobqs8g.fsf-monnier+emacs@gnu.org

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> 
> >     I think we should first figure out why this one needs it.  It doesn't
> >     seem particularly special.  There may simply be a bug elsewhere,
> 
> > Well, mmaug already sent an explanation of why it fails.
> > Do you see a bug in the chain of events he described?
> 
> Not really, but the chain is incomplete.  See the part where he says "owwie":
> 
> >> I dug a little deeper, and saw that activation of minor modes under
> >> customize should be delayed to address just this issue, but the process
> >> of trying to  figure out what went wrong began to make my brain go
> >> "owwwie".  
> 

Okay, I think I've figured out what is happening, not sure how best to fix it...

This is probably not a problem with just recentf.  I'm seeing a problem only 
because this is a minor mode which hasn't been loaded yet and there are mode 
related settings that are alphabetically sorted after the minor mode variable 
name.  On top of that, this particular mode uses the later variable when it 
starts.  My guess is that there are other minor modes out there with similar 
problems but which may be far more subtle and finding them is a challenge.

Some background:

* the define-minor-mode of recentf-mode is Autoloaded
* minor mode variables or variables having a require list (the 4th element in 
the custom-set-varaiables entry) are moved to the end of the list to be set.

RMS solution was to force the creation of the 4th element in the custom-set-
variables entry by adding the :require recentf property to the define-minor-
mode command.  When custom is next updated, "nil (recentf)" is added to the 
entry automatically.  This fixes recentf but doesn't address the underlying 
problem.

The issue is that when custom-set-variable checks to see if a symbol is a minor-
mode, it looks at the custom-set property which isn't set until the module is 
loaded.  Once the module has been loaded, custom properly detects that recentf-
mode is a minor mode variable.

If I look at the plist of recentf-mode prior to the custom-set-variable, it 
looks like:

  (variable-documentation 1424541 
   custom-autoload t 
   custom-loads ("recentf"))

The custom-autoload and custom-loads properties are used once the c-s-v entries 
have been sorted, what I'm wondering is, if processing these before the sort 
makes sense, so that the optional minor mode modules get loaded before checking 
their properties?  

Here's an attempt (basically I moved the code to autoload out of the main loop 
and put it before the sort).  This did fix the problem for me and would seem to 
fix the problem for other, more subtle, situations.  I didn't move the code to 
handle explicit requires in the c-s-v entries since I figured that should be 
reserved for very special situations.  This patch should allow us to remove 
most of the :require settings in autoloaded minor modes.

*** emacs/lisp/custom.el.orig   Wed Aug 23 20:21:04 2006
--- emacs/lisp/custom.el        Tue Aug 29 18:56:36 2006
***************
*** 874,879 ****
--- 874,891 ----
  EXP itself is saved unevaluated as SYMBOL property `saved-value' and
  in SYMBOL's list property `theme-value' \(using `custom-push-theme')."
    (custom-check-theme theme)
+ 
+   ;; Load any modules referred to by symbols in the set-variable list
+   ;; This allows us to detect minor modes even if they hadn't been
+   ;; loaded yet.
+   (dolist (entry args)
+     (let* ((symbol (indirect-variable (nth 0 entry))))
+       (unless (or (get symbol 'standard-value)
+                 (memq (get symbol 'custom-autoload) '(nil noset)))
+       ;; This symbol needs to be autoloaded, even just for a `set'.
+       (custom-load-symbol symbol))))
+ 
+   ;; Move minor modes and variables with explicit requires to the end
    (setq args
        (sort args
              (lambda (a1 a2)
***************
*** 904,913 ****
            (when requests
              (put symbol 'custom-requests requests)
              (mapc 'require requests))
-             (unless (or (get symbol 'standard-value)
-                         (memq (get symbol 'custom-autoload) '(nil noset)))
-               ;; This symbol needs to be autoloaded, even just for a `set'.
-               (custom-load-symbol symbol))
            (setq set (or (get symbol 'custom-set) 'custom-set-default))
            (put symbol 'saved-value (list value))
            (put symbol 'saved-variable-comment comment)
--- 916,921 ----

  reply	other threads:[~2006-08-29 23:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-25 15:53 Customizing recentf Michael Mauger
2006-08-28  9:52 ` Richard Stallman
2006-08-28 15:02   ` Stefan Monnier
2006-08-29 11:47     ` Richard Stallman
2006-08-29 19:04       ` Stefan Monnier
2006-08-29 23:09         ` Michael Mauger [this message]
2006-08-30  0:32           ` Michael Mauger
2006-08-30 17:17           ` Stefan Monnier
2006-08-30 17:58           ` Richard Stallman
2006-08-31 17:11           ` Stefan Monnier

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=loom.20060830T001252-230@post.gmane.org \
    --to=mmaug@yahoo.com \
    /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.