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