Re: Notmuch Emacs 0.31.2 documentation and keybinding suggestions

[David Bremner <david@tethera.net>]

"Jorge P. de Morais Neto" <jorge+list@disroot.org> writes:

> Hi.  I would like to report the following documentation and keybinding
> imperfections:
>
> The info page
> [[info:notmuch-emacs.info#notmuch-hello key bindings]] says that
> <backspace> moves to the previous widget, but that key is actually bound
> to `delete-backward-char'.  To move to the previous widget I use <C-M-i>
> or <S-iso-lefttab>.  And why does <S-iso-lefttab> move backward but
> <S-C-i> (which ought to be equivalent to <S-iso-lefttab>, no?) moves forward?
>
> Also, it seems that <SPC> moves forward and <DEL> moves backward, but
> <S-SPC> does nothing useful.  For consistency with Emacs Info Mode,
> Emacs View Mode, and some other applications such as Firefox, perhaps
> <S-SPC> should move backward too.
>
> The introduction of help buffer for Notmuch-Show (reached by hitting
> <?>) describes the <SPC> command without mentioning that it can archive
> the thread; only in <SPC> specific description (which does not fit in
> the same window; one has to scroll) does it mention the archiving
> behavior.  I believe the archiving behavior should also be mentioned in
> the introduction, lest the user unwittingly archive a thread she wasn't
> supposed to.  Also, the description for <u> is empty (this also happens
> in the help buffer for Notmuch-Hello).
>
> In the same help buffer, the description of <c ?> says "Show help for a
> subkeymap."  Would it not be better to drop the "a", leaving "Show help
> for subkeymap." ?
>
> Finally, the binding for <C-tab> in Notmuch-Show and Notmuch-Hello
> inconveniently clobbers the tab-bar-mode binding for that key.  Should
> not Notmuch be content with <C-M-i>/<ESC tab>/<S-iso-lefttab> (and
> possibly <S-C-i>) and leave <C-Tab> alone?
>

I think I've fixed all I'm going to in 0.34.1-37-gc0115288 (should be
part of 0.35). If you think there are specific things that important and
still unresolved, please send one message per issue, it's much easier to
keep track of that way.

d