[VM] Key bindings from presentation buffer reappears in the reply
This feels like a bug to me, and i can report it in launchpad. But just to make sure I don't misunderstand something, I wanted to check here first. When a mail contains URL:s there is some special key bindings at the URL text. E.g., if I type return in the text, I visit the page. When I do vm-reply-include-text, it appears this keymap is applied also to the reply to be edited. If I happen to type return inside the URL when editing the reply, I will go to that URL rather than insert a newline as I would have expected. I think I've been hit by other keys behaving in unexpected ways too, though I'm not sure. As an example, put the file below in a file. Do vm-visit-folder on the file. Hit R (vm-reply-include-text). Move the cursor over the URL. Hit RET. I would expect an return character inserted. But instead my firefox tries to open the URL. This is with vm 8.2.0b and emacs 21.4. From uddeborg Thu Oct 11 10:42:35 2012 MIME-Version: 1.0 Message-ID: 507685d3.6080...@jeppesen.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: goran.uddeb...@jeppesen.com To: goran.uddeb...@jeppesen.com Subject: Test case Date: Thu, 11 Oct 2012 10:39:47 +0200 Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. http://example.com/page.html Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
[VM] Are there plans to release 8.2?
I've been waiting to upgrade the Fedora package of VM until 8.2 is declared released. After all, 8.2.0b is officially a beta, right? But there are some issues with waiting, most recently illustrated by the bug report https://bugzilla.redhat.com/show_bug.cgi?id=960295 Do you have plans to make an official 8.2.0. Or should I package 8.2.0b anyway. True, that officially released stamp doesn't make that much difference in reality. But it would feel a bit better. :-)
[VM] Problem with VM on Aquamacs 3.2 and 3.3dev
Göran Uddeborg: > (add-hook 'vm-select-message-hook > (lambda () (save-selected-window (vm-beginning-of-message Hm, that seems to have an unintended side-effect, though. Whenever I visit a virtual folder I've defined, it appears in the same window as the window, frame in emacs terms, as the one I'm currently using. Previously the virtual folder showed up in a new frame.
[VM] vm-url-decode-buffer and UTF-8
I'm occasionally calling emacsclient ... vm-mail-to-mailto-url ... from scripts. It works fine for simple mailto:user@domain URL:s. But if the URL also includes some non-ASCII, e.g. in a subject= argument, then this string gets mangled. More exactly, the UTF-8 encoded character in the string gets treated as multiple single characters. If I understand things correctly, this boils down to vm-url-decode-buffer doing the decoding in that way. It looks for one %XX escape, and does insert-char on the decoded value. That makes a UTF-8 sequence consisting of more than one byte become several characters. Has anyone else been hit by this or something similar? And, in particular, has anyone any idea how to fix the problem?
[VM] Problem with VM on Aquamacs 3.2 and 3.3dev
Piet van Oostrum: > However, I now have an annoying problem with VM. With the new > Aquamacs version, when I read an HMTL email (usually multipart/mixed), > the cursor jumps to the end of the message rather than to the beginning. > This only happens when I work from the VM Summary buffer (using the next > and previous keys n and p). When I work from the VM Presentation buffer > it works as desired. Thanks for digging into this, and suggesting a solution. The behviour has irritated me too, but not enough for me to investigate. Until I read your mail. (And a few weeks more had passed. :-)) I looked a bit into the possibility of catching the other cases too, and run across a hook, vm-select-message-hook, that seemed to fit the purpose. So what I have arrived to now is this quite simple code (add-hook 'vm-select-message-hook (lambda () (save-selected-window (vm-beginning-of-message It appears to work as far as I can tell. It does also work for the case when you move around in the summary buffer and hitting SPACE. In case it matters, I'm using GNU Emacs 25.0.94.1 on Fedora Linux. Fixing the underlying problem would of course be even better.
vm, emacs 28.2 (debian), urls in minibuffer
John Stoffel skrev: > It just shows one line of text, but I > seem to recall it recently showed more lines of text. Sigh... any > suggestions on where to look before I start ripping my .emacs to > pieces to find the problem? Not much help I'm afraid, but for what it's worth: that is how my vm behaves too. I see the whole URL if and only if I make the window wide enough to fit it. This is despite my message-truncate-lines is nil. (Fedora 39, emacs 29.1, vm 8.2.0 bzr snapshot 20220609.)
Re: vm, emacs 28.2 (debian), urls in minibuffer
John Stoffel skrev: > Whee! Here's a bunch of the errors I get in emacs 28.2 loading > vm-load.el once I added the directory into my library-path. The right thing would of course be to fix the bugs. VM is in need for someone to dare take over maintainership. At least someone to sync the various patches people come with from time to time. >From what I found VM is not currently usable with JIT-compilation. In the Fedora packaging I maintain I have disabled JIT with the code below. The list variable to add to changed name between emacs 28 and 29, that is the reason for the list with two names. ;; For some reason, native compilation breaks VM. As a workaround until the ;; problem is understood and fixed, disable native compilation of all VM ;; lisp files. (eval-after-load "comp" '(dolist (deny-list '(native-comp-deferred-compilation-deny-list native-comp-jit-compilation-deny-list)) (if (boundp deny-list) (add-to-list deny-list "/vm.*\.el"
Re: vm, emacs 28.2 (debian), urls in minibuffer
Stefan Monnier via General discussion of VM mail reader skrev: > Maybe the first thing to do would be to move it from Bazaar to Git, That would be a good idea, I agree. > maybe over on Codeberg. Launchpad itself can also host git repositories nowadays if one want to go that way. But I don't think anyone would object to a change of forge. If any new maintainer/coordinator steps up I'd say it would be up to him/her.
