vm-mail-to-mailto-url problems

[Göran Uddeborg]

I have a little "emacsmailer" script which I use when following mailto URL:s from other programs like Firefox. For emacs 21 it is implemented like this:

  emacs -l $HOME/vm-trunk/vm-load.el --eval "(let ((vm-frame-per-composition nil)) (vm-mail-to-mailto-url \"$1\"))"

With the latest trunk however, it fails with the error message

  vm-mail-to-mailto-url: Symbol's value as variable is void: vm-fsfemacs-mule-p

Another load order issue maybe?

This happens using emacs 21.4 and revision 1035 of vm.

(With newer versions I use emacsclient instead in the script, but emacsclient didn't support the --eval flag in version 21.)

[Uday Reddy (reddyuday)]

This was actually due to a change I made in revision 1033, noticing
that vm-vars was being loaded for FSF Emacs but not XEmacs. So, I
thought it wasn't necessary. I have now reverted the change in
revision 1042.

Cheers,
Uday

[Göran Uddeborg (goeran-uddeborg)]

It appears as this fix revived an earlier bug. After updating to revision 1044, I now get this error when I start emacs:

Symbol's function definition is void: defvaralias

Here is a stack trace:

  (defvaralias (quote vm-mime-savable-types) (quote vm-mime-saveable-types))
  require(vm-vars)
  byte-code(…)
  load("vm-autoloads")
  eval-buffer(#<buffer *load*<2>> nil "/users/uddeborg/vm-trunk/vm-load.el" nil t)
  load-with-code-conversion("/users/uddeborg/vm-trunk/vm-load.el" "/users/uddeborg/vm-trunk/vm-load.el" nil nil)
  load("/users/uddeborg/vm-trunk/vm-load.el")
  eval-buffer(#<buffer *load*> nil "~/.emacs" nil t)
  load-with-code-conversion("/users/uddeborg/.emacs" "~/.emacs" t t)
  load("~/.emacs" t t)
  #[…]
  command-line()
  normal-top-level()

[Uday Reddy (reddyuday)]

Try recompiling everything. Do
  make clean
  make
in the VM directory and see if it works.

Cheers,
Uday

[Uday Reddy (reddyuday)]

Ok, I found another problem with the defvaralias macro. Please try
the revision 1046 from the trunk.

Cheers,
Uday

[Göran Uddeborg (goeran-uddeborg)]

It doesn't The error remains. I tried rerunning configure between "make clean" and "make", but it still didnät make any difference.

[Göran Uddeborg (goeran-uddeborg)]

Note that my previous comment was about doing make clean/make. I'll test revision 1046 tomorrow.

[Göran Uddeborg (goeran-uddeborg)]

Revision 1046 doesn't give the error in comment 2 any more. When starting emacs the normal way, everything works again.

When starting it with the command line in the description, however, I get an error message that vm-session-initialization is undefined. Stack trace below.

(This might be a completely separate error. Do you want to keep order by having one bug report per issue? I'll file a new one about this if you wish.)

  vm-session-initialization()
  vm-mail-to-mailto-url("mailto:<email address hidden>")
  (let ((debug-on-error t) (vm-frame-per-composition nil)) (vm-mail-to-mailto-url "mailto:<email address hidden>"))
  eval((let ((debug-on-error t) (vm-frame-per-composition nil)) (vm-mail-to-mailto-url "mailto:<email address hidden>")))
  command-line-1(("-l" "/users/uddeborg/vm-trunk/vm-load.el" "--eval" "(let ((debug-on-error t) (vm-frame-per-composition nil)) (vm-mail-to-mailto-url \"mailto:<email address hidden>\"))"))
  command-line()
  normal-top-level()

[Uday Reddy (reddyuday)]

Ok, we at least have the Emacs 21 problem out of the way. I will have to test out the mailto-url functionality. There could also be similar issues with vm-user-agent and other non-standard ways of invoking VM.

[Uday Reddy (reddyuday)]

Göran Uddeborg writes:

> When starting it with the command line in the description, however, I
> get an error message that vm-session-initialization is undefined. Stack
> trace below.

I have this running now. I don't know how you had it working before.
The bug was present in every version of VM I have on file!

Cheers,
Uday

[Uday Reddy (reddyuday)]

Hi Goeran, I hope this issue is resolved now?

[Göran Uddeborg (goeran-uddeborg)]

> I hope this issue is resolved now?

Sorry for not replying earlier. Yes, this is resolved; it works fine now.