Message-Id: <8807230245.AA17093@SELENE.MIT.EDU>
To: dmh@ATHENA.MIT.EDU, davis@ATHENA.MIT.EDU, thebeast@ATHENA.MIT.EDU,
        lerman@ATHENA.MIT.EDU, wdc@ATHENA.MIT.EDU, bgardner@ATHENA.MIT.EDU,
        mwmoor@ATHENA.MIT.EDU, steiner@ATHENA.MIT.EDU, hodges@ATHENA.MIT.EDU,
        henry@ATHENA.MIT.EDU, vanharen@ATHENA.MIT.EDU, rar@ATHENA.MIT.EDU,
        tjcoppet@ATHENA.MIT.EDU, kit@ATHENA.MIT.EDU, mackay@ATHENA.MIT.EDU,
        swick@ATHENA.MIT.EDU
Cc: treese@ATHENA.MIT.EDU
Subject: Xmh: summary of comments, with response
Date: Fri, 22 Jul 88 22:45:41 EDT
From: Win Treese <treese@ATHENA.MIT.EDU>


Thanks for your comments on xmh.  In this message, I have summarized them,
with responses to some questions or comments.  At some point, I hope to
have some changes made to xmh.  If you are *not* interested in hearing about
them, please let me know.  Otherwise, I will announce it to this group of
people.

1. Frequent rescans.  xmh often rescans your inbox for no apparent reason.

	This problem is all but eradicated in the 6.0B release.  Xmh was
	confused by NFS, since the timestamp on a file might not match the
	local machine's idea of the time.  I am interested in reports about
	this is 6.0B, but I don't think it should be a big strike against
	xmh now.

2. The print option should be improved.  That is, it should give you better
	control over where your output is going, and should be able to
	handle non-PostScript printers.

	I agree with this.  You can specify a resource that changes the
	print command, but I have had trouble making this work.  In any
	case, I think a "print setup" command would be useful.

3. Speed.

	Always a problem.  We'll see what can be done about it.

4. Default geometry is odd.

	This is true, but can easily be fixed by changing the default
	resources.

5. Can't tell which button to press.

	The 6.0B xmh has more verbose button names, though I suspect a "help"
	button would be a useful addition.  Such a button should be
	visually very obvious. One suggestion is that there be fewer buttons;
	perhaps a "novice" mode?  Some of the buttons are admittedly not
	obvious in their function (e.g., "unmark").

6. The manual page is not clear on the button usage for scrollbars.

	True, but the scrollbars behave like any other toolkit scrollbars.

7. Support for hierarchical folders would be nice.

	I'll have to think about this one.

8. How do you refile messages into folders?

	This may not be obvious, but it is one of my favorite features.  To
	refile a message, you

	1. Click on the button of the folder in the top set of buttons.
	2. Click on the message line in the scan listing (if it is not
		already the current message).
	3. Click on the "Move" button in the middle set of buttons.
	4. When you're done refiling and deleting, click on the "Commit"
		button in the middle set of buttons.

9. The editor is slow.

	Actually, the slowness is mostly due to the overhead of running
	an MH program like "comp" or "repl", not the speed of xmh itself.

10. Have double-click on a folder open it.  Have double-click on a sequence
	open it.

	Interesting idea; maybe I'll give it a try.  I suspect the toolkit
	gets in the way on that, however.

11. What do you think of a menu interface instead of the rows of buttons?

	(that's my addition)

12. MH is inherently clunky, and this is reflected in MH.

	I don't know enough about this statement to comment now.

13. xmh requires one to fiddle with the resources.

	This is currently true, but only because the defaults aren't
	quite right yet.

14. How about a different editor interface (e.g., vi)?

	That really goes back to the toolkit.  The toolkit editor is
	pretty configurable, though I don't know that it can emulate a vi
	subset.  Frankly, I have no plans to do anything about it.

15. The buttons aren't size and shape configurable (for changing fonts).

	I think that this works in the 6.0B release, but I'll look into it.

16. It requires use of the mouse.

	Having keyboard alternatives is an interesting idea, though I
	think that it should be addressed (if at all) in the toolkit,
	not in xmh alone.

17. It should not be so sensitive to errors.

	This is definitely true.  Right now, it's really still an experimental
	version in some ways.  One of the ways is that it intentionally
	aborts in some situations rather than attempting to recover.  This
	is something I'll look at.

18. The editor isn't really emacs.

	That's true, and it's a real trade-off in building applications with
	the toolkit.  My experience has been that there is enough of emacs
	there for manipulating mail.  Cutting and pasting is best done with
	the mouse though.

19. "reply" should allow "-cc all".

	This can be set permanently in your .mh_profile file.  Poll question:
	how often do you want to give one of the programs (e.g., comp, repl,
	forw) an option?

20. A button for 'ispell' would be nice.

	That's an interesting idea.  I'll need to think about it, though.

21. It would be nice to specify which folders are given buttons.

	Another interesting idea to think about.

22. It takes up too much screen real estate.

	Agreed that it takes up a lot, but I think that almost of it is
	useful information and that it would be hard to make it more compact.
	An alternative is using menus to eliminate the boxes of buttons.

23. A way to interrupt, say,  a reply before the editor window comes up
	would be nice.

24. It loses its place in the scan listing.

	Yes, it does.  I'll try to track that down.

25. How about a summary of the suggestions?

	Here it is.


	- Win