Modify

Ticket #242 (closed defect: wontfix)

Opened 6 years ago

Last modified 5 years ago

unexpected help output

Reported by: wingo@… Owned by: wingo@…
Priority: major Milestone:
Component: moap Version: TRUNK
Keywords: Cc:

Description

Steps to reproduce: moap --help changelog

Expected output: help on changelog commands

Actual output: general help

Bzr's help accepts lots of different combinations of things. I find it helpful!

Attachments

Change History

comment:1 Changed 6 years ago by thomas

moap is tree-based. an option to the moap command applies to the moap command. To get help on changelog, you do moap changelog --help.

moap --help mentions this too: Moap gives you a tree of subcommands to work with. You can get help on subcommands by using the -h option to the subcommand.

I'm not a fan of adding three different ways of getting help personally. the GNU style is the one with wider use.

comment:2 Changed 6 years ago by anonymous

I am aware that the implementation might structure your way of thinking about the problem. My thesis is that since moap's goal is to make the project maintainer's life easier, that it should do so to the degree that it is able. Given that you have the available information to e.g. give a message "you should have typed XXXX", you should just go ahead and do that thing.

Not to tout bzr as the be-all and end-all, but I believe that their perspective on this matter is particularly intuitive.

Another point is that the maintainer's expectations are largely determined by what they are used to typing, and that a tool to make life easy for the maintainer should adapt to that.

I am trying hard not to say something like "if you want to make your tool more difficult that's fine, but it is not in your interests if you want it to be accepted", but it seems that I have failed ;)

Final point: kathy sierra's "helping your users kick ass". Think about that when e.g. getting a suggestion and responding, "this does not fit into my worldview" vs "i acknowledge your desires, let's work together to fix this." As it is now I do not feel motivated to discuss much more on this.

comment:3 Changed 6 years ago by thomas

  • Owner changed from thomas to wingo@…
  • Milestone 0.2.5 deleted

I think you overargue this too much. Let's look at this in simple terms.

a) all GNU programs support at least -h or --help b) some programs also support "help" as a command c) beside bzr I know of no other program that supports (program name) --help (subcommand name) and I frankly find that syntax appalling. I don't think you can make a reasonable argument d) I think fixing #240 is enough towards being intuitive e) I do not think bzr is neither usable nor intuitive, though it beats the pants off tla and git f) to counter your Sierra, here's a quote from an article that I read the day before you asked for this: "As the saying goes, users ask for features like kids ask for candy — and like candy too many features are bad for you." ( http://richardsona.squarespace.com/main/2007/5/23/why-feature-creep-occurs.html) You filed heaps of tickets in one day, they can't all be equally reasonable :)

In short, I'd like to close this ticket as WONTFIX unless you disagree.

comment:4 Changed 5 years ago by thomas

  • Status changed from new to closed
  • Resolution set to wontfix
View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.