vm team mailing list archive

[Uday Reddy <u.s.reddy@xxxxxxxxxxxxx>]

Matthew Lovell writes:

> I find I'm also still having problems with auto-autoloads.el and
> 
>   vm-decode-postponed-mime-message
> 
> my solution currently is to copy auto-autoloads.el over to
> vm-autoloads.el and add
> 
>   (provide 'vm-autoload)
> 
> at the tail.

Hi Matthew,

You probably have (provide 'vm-autoloads) in your init.el file.  Can
you change it to 

  (load-library "/path/to/vm/auto-autoloads")

and see if it solves the problem?

Cheers,
Uday

** Summary changed:

- vm-8.0.13 mapvector possibly collides with xemacs built-in function
+ vm-8.0.13 mapvector ; autoloads failing

** Changed in: vm/trunk
    Milestone: 8.1.0b => 8.1.1

** Changed in: vm/trunk
       Status: Fix Released => In Progress

-- 
vm-8.0.13 mapvector ; autoloads failing
https://bugs.launchpad.net/bugs/492117
You received this bug notification because you are a member of VM
development team, which is the registrant for VM (defunct).

Status in VM - Goto http://launchpad.net/vm for active development: Fix Released
Status in VM (View Mail) for Emacs: In Progress
Status in VM 8.0.x series: Fix Released
Status in VM trunk series: In Progress

Bug description:
vm-8.0.13 introduced a defun for mapvector in vm-folder.  This definition appears to stomp upon the function built into xemacs already:

  `mapvector' is a built-in function
  (mapvector FUNCTION SEQUENCE)

This became evident trying to invoke latex-mode on a buffer after having upgraded from vm-8.0.12 to vm-8.0.13.  This resulted in an error saying that a mapvector usage had an incorrect argument.

Changing vm-folder.el such that it defines and uses vm-mapvector appears to have fixed this behavior.

I was attempting to revert this change to obtain a back trace of the error, but I am currently unable to reproduce the exact one I am experiencing.  Nevertheless, it would seem unwise to defun a duplicate of a built-in function.