From: Austin Clements <amdragon@MIT.EDU>
To: Mark Walters <markwalters1009@gmail.com>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH 0/4] emacs: Part command improvements
Date: Wed, 29 May 2013 21:01:33 -0400 [thread overview]
Message-ID: <20130530010133.GY5999@mit.edu> (raw)
In-Reply-To: <87zjvghx82.fsf@qmul.ac.uk>
Quoth Mark Walters on May 27 at 11:30 pm:
> Austin Clements <amdragon@MIT.EDU> writes:
>
> > This is a follow-up of sorts to id:"8761ycc19t.fsf@qmul.ac.uk", where
> > Mark suggested that the part handling commands could all use the
> > correponding mm-* functions. I ran with the idea and wound up with
> > this series, which, in addition to standardizing on the mm-* functions
> > for everything and simplifying the implementation overall, decouples
> > the part commands from part buttons, which removes an entire layer
> > from the implementation and adds the ability to invoke part commands
> > with point anywhere in a part (something I often find myself wanting).
>
> Overall I really like this series. In addition to the clean up etc it
> makes it easy to export the text/plain part (which doesn't have a part
> button). I have recollection of this being difficult if it is base64
> encoded.
Right. That's one of the reasons I wanted a global part keymap (and
this series happened to be a convenient place to introduce that).
Also helpful is that the part bindings now appear in the show help,
which is good because I can never remember which key used the default
viewer and which prompted for a viewer.
> I have a few small comments
>
> As mentioned on irc (just included here in case other people are
> testing) make-composed-keymap is emacs 24 only.
I've removed the button map entirely, so this is no longer a problem.
> This does change the default directory for saving: not serious but it's
> probably worth deciding do we want to use mailcap-download-directory or
> home or where emacs was started or?
I don't really care what the default directory is, as long as we're
consistent, which we currently aren't. mm-default-directory seems
like a fine thing to be consistent with, since we use mm for
everything else.
> I don't know if we want to keep a special keymap for the button or just
> always use the . prefix; the advantage is that you don't have 's' on a
> button acting differently from 's' in the text (which has annoyed me
> several times) otoh it is the extra keystroke which may annoy people
> too. Let the bikeshedding begin! (obviously return for the default
> action would remain.
I'm all for removing the special button keymap. The less hidden
functionality the better.
> Would it be worth having . return in the part body as the default
> action ?
I played with this for a while and eventually decided it wasn't worth
the effort. Maybe in a followup.
> Finally, with message indenting it's the start/end of the part are a
> little unclear. I think it's the [ of the part button at the start of
> the part to the character before the [ of the next part button. In
> particular on the line of a new part but before the button is still the
> old part. Since parts are whole lines it would be nice if the region
> were line based but I don't know if that is easy.
Fixed in v2.
> Best wishes
>
> Mark
prev parent reply other threads:[~2013-05-30 1:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-27 20:46 [PATCH 0/4] emacs: Part command improvements Austin Clements
2013-05-27 20:46 ` [PATCH 1/4] emacs: Retain text properties when toggling buttons Austin Clements
2013-05-27 20:46 ` [PATCH 2/4] emacs: Record part p-list in a text property Austin Clements
2013-05-27 22:19 ` Mark Walters
2013-05-27 20:46 ` [PATCH 3/4] emacs: Simplify MIME part command implementation Austin Clements
2013-05-27 20:46 ` [PATCH 4/4] emacs: Bind MIME part commands to "." submap Austin Clements
2013-05-27 22:30 ` [PATCH 0/4] emacs: Part command improvements Mark Walters
2013-05-30 1:01 ` Austin Clements [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130530010133.GY5999@mit.edu \
--to=amdragon@mit.edu \
--cc=markwalters1009@gmail.com \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).