key binding - editing messages

[mere user]

when trying to edit a message (e) I now get
call-interactively: Buffer is read-only: #<buffer RMAIL Presentation>
development version as of today
gnu emacs 24.0.50 or such

[Uday Reddy (reddyuday)]

Hmm.. you edit messages? you naughty man :-)

I have moved the key binding of "e" to vm-optional-keys. I didn't realize
that somebody would miss it so soon...

Please load vm-optional-keys.

Cheers,
Uday

[mere user (emacs-user)]

thanks, I just re-bounded e to edit-message. works fine now. best, E

On Wed, Apr 27, 2011 at 10:07 PM, Launchpad Bug Tracker
<email address hidden> wrote:
> ** Branch linked: lp:vm
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/771607
>
> Title:
>  key binding - editing messages
>
> Status in VM (View Mail) for Emacs:
>  In Progress
>
> Bug description:
>  when trying to edit a message (e) I now get
>  call-interactively: Buffer is read-only: #<buffer RMAIL Presentation>
>  development version as of today
>  gnu emacs 24.0.50 or such
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/vm/+bug/771607/+subscribe
>

[Uday Reddy (reddyuday)]

C-c C-e is now the new key binding for vm-edit-message.

[John Hein (xpqheqdvq4)]

I've run into three of these now that I [used to] use all the time: 'a', 'b', 'e'

'b' went away somewhere around rev 118x? Now that I'm using rev 1208, 'a' and 'e' are gone now, too. Using the old keys after executing vm-optional-keys isn't working well, but that could be related to other problems I'm seeing (bug 777174). The problems are probably unrelated to the overall key binding strategy, but I thought I'd weigh in on at least these three keys that I've noticed as missing.

'a' and 'e' are fairly obvious (vm-set-message-attributes and vm-edit-message) and the characterization in the new vm-vars.el as "infrequent" are not true for me at least.

'b' deserves a little more explanation. I often run vm in a non-windowed emacs session over ssh from within a screen (gnu screen or tmux) session and terminal differences between different platforms (linux, cygwin, bsd, etc.) variously cause meta- or ctrl- sequences to not work. Sometimes backspace works, sometimes just ctrl-h, so I got into the habit of using 'b' to page back through messages in vm.

Yes, I know I can bind them myself, but I run the risk of a key binding conflict in future versions of vm.

Anyway, just my report on some missing keys that I have now noticed which I used a lot.

[John Hein (xpqheqdvq4)]

Oh... "L" too. Not as frequent as the others, but the fingers are very familiar with it.

[John Hein (xpqheqdvq4)]

The problems I had using optional keys only surface when the conditions mentioned in bug 777174 exist (i/e/, threading is on). In non-threaded folders, there's no problem with the vm-optional-keys. Sorry for the side path red herring.

[Uday Reddy (reddyuday)]

Please note that `vm-optional-keys' is now called `vm-legacy-key-bindings' following the discussion in the newsgroup.

If you call it from your .vm file, everything should work as it used to. Even if I bind them in the default key bindings, your .vm file override them.

Can you double check that this is what you are doing?

Cheers,
Uday

[Uday Reddy (reddyuday)]

John Hein writes:

> The problems I had using optional keys only surface when the conditions
> mentioned in bug 777174 exist (i/e/, threading is on). In non-threaded
> folders, there's no problem with the vm-optional-keys. Sorry for the
> side path red herring.

Again, this should not be an issue of call `vm-legacy-key-bindings' from
your .vm file. It binds the keys globally for all VM buffers.

Cheers,
Uday

[Uday Reddy (reddyuday)]

Uday S Reddy writes:

> Again, this should not be an issue of call `vm-legacy-key-bindings' from
> your .vm file. It binds the keys globally for all VM buffers.

Sorry that was incoherent due to "typos"! I meant to say:

This should not be an issue if you call `vm-legacy-key-bindings' from
your .vm file. It binds the keys globally for all VM buffers.

Cheers,
Uday

[John Hein (xpqheqdvq4)]

Never mind how I pull in the legacy key bindings. The main reason I chimed in is to contribute feedback about what bindings should be considered legacy or not. I don't have a problem reducing the size of the default bindings list. But I just thought I'd mention that the "infrequent" characterization for 'a', 'b', 'e' and to some degree 'L' is not true in my case. If I'm an outlier, that's fine, but it's hard to determine what bindings people use on a daily basis if they don't speak up - so I did ;)

By the way, I should have mentioned that strategy of using something like the C-c C-e binding instead of 'e' is fine with me. C-c C-a would be a little less desirable since I use gnu screen a lot, but that is not a strong enough preference to stop the bindings cleanup train from going forward.

[Uday Reddy (reddyuday)]

John Hein writes:

> Never mind how I pull in the legacy key bindings. The main reason I
> chimed in is to contribute feedback about what bindings should be
> considered legacy or not. I don't have a problem reducing the size of
> the default bindings list. But I just thought I'd mention that the
> "infrequent" characterization for 'a', 'b', 'e' and to some degree 'L'
> is not true in my case. If I'm an outlier, that's fine, but it's hard
> to determine what bindings people use on a daily basis if they don't
> speak up - so I did ;)

In that case, my general principle is that the users are the best judge of
how best to bind keys for their own use. The purpose of the package's
default key bindings is firstly to help out the new users and secondly to
bring in some amount of standardization. So, the functions that are not
needed for the majority of the users the majority of the time are best to
left to the users to bind for themselves.

Some very useful functions never get used unfortunately because they are
impractical to use unless bound to keys. An excellent example is
vm-quit-just-bury, which I bind to `b' for my own use. Freeing up keys will
allow users to explore various possibilities.

Cheers,
Uday

[John Hein (xpqheqdvq4)]

Fully agree with that guideline. Just thought I'd mention my usage to help contribute to what might be construed as majority usage.

As far as vm-quit-just-bury, C-x 5 0 does the equivalent job for me (although I hardly ever do that to vm folder frames).