drafting over existing commands

[nilbus]

I think it's a problem that you can draft a command that already exists, and it just clobbers the old one without asking. At least it can be undone in git.

Do you think instead it ought to bail out with an error and suggest revise, ask if you want to overwrite or revise it, or just call revise instead?

[erichs]

Hmm... good point. I agree that silently overwriting the old definition is an error. I think draft should bail out. One approach might be to modify
https://github.com/erichs/composure/blob/master/composure.sh#L268
to read

  if type -a "$func" 2>/dev/null | grep  -qE 'is.*alias|function'; then
     printf '%s\n' "sorry, $(type -a "$func"). please choose another name."
     return
  fi

That wouldn't prompt the user to revise, as you suggest, however. I need to think about that. If you're attempting to draft a command and use a name that's already taken, a revision probably isn't what you mean or want. If you said 'draft' in error and meant to say 'revise', then a reasonable expectation from a UX point of view would probably be that the command would fail and you'd type 'revise'. What do you think, would just bailing out suffice here?

[nilbus]

If there are to be two commands, then I agree, it should bail out.

That said, I actually don't see the benefit in having two commands. You could potentially have a single compose command that executes either draft or revise depending on whether it exists or not already. What are your thoughts on that?

[erichs]

I think, overall, that would be cleaner. I have become less enamored over time with my 'composition (writing) as metaphor for composition (programming)' theme, which is in part responsible for there being two commands, draft and revise.

I've also wondered about the necessity of having two commands for glossary and reference. Sadly, although not a keyword in ksh or zsh, bash has a help command, which would be the obvious and intuitive choice. Perhaps those should stay separate for now...

Returning to your idea, I suppose that compose would have the following semantics:

Context	Action
prior alias exists	bail out, choose different name
.inc file exists	revise existing function
shell fn exists	confirm this function should be composed
otherwise	draft last command or history line number

[nilbus]

Yes, exactly.

It's too bad about the conflicts we must necessarily face in naming things since they're all globally namespaced. It might be worth considering for a future major release to make them all subcommands of something like compose, similar to how git works. I don't know that there are any conflicts though, and it may not be worth the significant change to how this works.

[erichs]

I'll consider a command "suite" for a future release. I've always wanted to keep the porcelain footprint small, and command suites really shine when they namespace an expansive command set. Like you said, it may not be worth the major change.

I'll need a few days to hack on the compose function, and get it under test properly. That work will likely take place on the testing branch.

PRs welcome there, too, of course :)

[nilbus]

Thanks!​ I'd be happy to review it, if you want.

[erichs]

sounds good!