bug#11569: 24.1.50; Defadvice fails after IDO load ("Cannot open doc string file")

bug#11569: 24.1.50; Defadvice fails after IDO load ("Cannot open doc string file")

[Vitalie Spinu]

Hi, 

Recent emacs-snapshot fails to load my .emacs with several occurrences
of defadvice in it. The weird part of it is that I cannot easily
reproduce that with emacs-snapshot -Q. This is a back-trace:

Debugger entered--Lisp error: (error "Cannot open doc string file \"/usr/share/emacs/24.1.50/etc/DOC-24.1.50.1\"")
  ad-real-documentation(#[(n &optional killflag) "\b\250\204\f\305\306\307\bD\"\210\310 \203.	\203.\b\311U\203.	\312=\203(\313\314 \315 \"\207\314 \315 |\207\n\203]\b\316X\204]`Sf\317>\204]m\204]\320f\321=\204]i\322\b[\f\"\210\212\323\324\viZ\320#*\207\322\b[\f\"\207" [n delete-active-region overwrite-mode ocol killflag signal wrong-type-argument integerp use-region-p 1 kill kill-region region-beginning region-end 0 (9 10) nil 10 delete-char insert-char 32] 4 1928790 "p\nP"] t)
  ad-make-advised-docstring(delete-backward-char)
  ad-real-documentation(#[(n &optional killflag) "\303\304	\n\"\211)\207" [ad-return-value n killflag nil ad-Orig-delete-backward-char] 4 #("Advice doc string" 0 17 (ad-advice-info delete-backward-char)) "p\nP"] t)
  ad-docstring(#[(n &optional killflag) "\303\304	\n\"\211)\207" [ad-return-value n killflag nil ad-Orig-delete-backward-char] 4 #("Advice doc string" 0 17 (ad-advice-info delete-backward-char)) "p\nP"])
  ad-advised-definition-p(#[(n &optional killflag) "\303\304	\n\"\211)\207" [ad-return-value n killflag nil ad-Orig-delete-backward-char] 4 #("Advice doc string" 0 17 (ad-advice-info delete-backward-char)) "p\nP"])
  ad-handle-definition(delete-backward-char)
  ad-activate(delete-backward-char nil)
  (progn (ad-add-advice (quote delete-backward-char) (quote (delete-empty-pair nil t (advice lambda nil nil))) (quote before) (quote nil)) (ad-activate (quote delete-backward-char) nil) (quote delete-backward-char))
  (defadvice delete-backward-char (before delete-empty-pair activate) nil)
  eval((defadvice delete-backward-char (before delete-empty-pair activate) nil) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)


How to interactively reproduce:

Start with -Q and load this:
   
   (require 'ido)
   (ido-mode t)
   (setq ido-use-virtual-buffers t)
   

Now do C-x b and select an unloaded buffer.  Evaluate the following
*twice*:
   
   (defadvice delete-backward-char (before delete-empty-pair activate) 
     ())
   
This is the only way I could reproduce the error interactively.

I've been loading the same .emacs with previous emacs snapshots with no
trouble. It might have something to do with this recent issue
http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00472.html

Thanks, 
Vitalie.

===============================================================

In GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.1)
 of 2012-05-24 on lansones, modified by Debian
 (emacs-snapshot package, version 2:20120524-1~ppa1~precise1)
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
Configured using:
 `configure '--build' 'i686-linux-gnu' '--host' 'i686-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.1.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.1.50/site-lisp:/usr/share/emacs/site-lisp'
 '--without-compress-info' '--with-crt-dir=/usr/lib/i386-linux-gnu/'
 '--with-x=yes' '--with-x-toolkit=gtk3' '--with-imagemagick=yes'
 'build_alias=i686-linux-gnu' 'host_alias=i686-linux-gnu'
 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g
 -Wl,--as-needed -znocombreloc' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  recentf-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-y C-p C-p C-p C-p C-p C-p C-p C-e C-x C-e C-n C-x 
C-e C-n C-x C-e C-g q C-e C-e C-x C-e C-g C-x C-e C-n 
C-n C-x b t e x <return> C-x b s c <return> C-n C-n 
C-e C-x C-e C-x C-e M-x r e p o r <tab> <return>

Recent messages:
Quit
Back to top level.
t
Quit
t
Loading /home/vitoshka/.recentf...done
Cleaning up the recentf list...done (0 removed)
Loading vc-git...done
delete-backward-char
Entering debugger...

Load-path shadows:


To: 
Subject: 
Gcc: nnfolder+archive:sent-2012-May

bug#11569: 24.1.50; Defadvice fails after IDO load ("Cannot open doc string file")

[Glenn Morris]

severity 11569 minor
retitle 11569 defadvice fails if DOC file is missing
stop

Vitalie Spinu wrote:

> http://lists.gnu.org/archive/html/emacs-devel/2012-05/msg00472.html

To clarify, the missing DOC file is a problem for whoever supplied your
pre-built binary (sounds like they already know about it).

Stefan feels it is an advice.el bug that it fails to work without a DOC
file. (IMO, an Emacs missing a DOC file is basically broken, and I
imagine it is likely to fail in various ways, so I think this is only a
minor issue.)

bug#11569: 24.1.50; Defadvice fails after IDO load ("Cannot open doc string file")

[Glenn Morris]

I'm guessing that the new nadvice.el in Emacs trunk doesn't have this
problem.

bug#11569: 24.1.50; Defadvice fails after IDO load ("Cannot open doc string file")

[Vitalie Spinu]

  >> Glenn Morris <rgm@gnu.org>
  >> on Sat, 05 Jan 2013 14:54:21 -0500 wrote:

  GM> I'm guessing that the new nadvice.el in Emacs trunk doesn't have this
  GM> problem.

Yes, it was fixed long back. Thanks.

    Vitalie