Rename jj describe's --no-edit flag to --no-editor or similar

[arxanas]

Follow-up from #5379 and #5419 (comment) and ensuing Discord discussion.

My argument was: In other contexts, --edit means "switch to the commit as the new working copy and start editing it", which is inconsistent with its usage here (and the current usage of --no-edit). Maybe it should be something like --editor/--no-editor?

Commentary:

@MrJohz:

That makes sense to me and I'm happy to make the change. To briefly play devil's advocate:

• That makes this a breaking change for anyone who's already using --no-edit in scripts etc
• Both Git and Mercurial use --edit (and --no-edit for Git) to invoke/avoid invoking the editor.

But internal consistency is more important than consistency with those other tools, so I'm happy to make the change if you/other people would prefer it that way.

@emilazy (Discord):

I'd expect --editor to take an argument and override $EDITOR

@jennings (Discord):

On the one hand, it seems better to rename it since it does something conceptually different. On the other hand, I have never noticed this discrepancy before now, so this would require me to pay attention to whether the command I'm using wants --no-edit or --no-editor. It's an easy decision, but I've never had to think about it before, and after renaming it I probably would.

@PhilipMetzger (Discord):

What about a --open-editor? I don't want a --edit, --no-edit thing.

Next steps: I'm still in favor of avoiding a consistency issue (particularly if some commands somehow get the ability to both configure opening an editor and editing the commit itself), but I don't have any immediate plans to push this forward, so I'm just archiving the discussion here for future reference.

[ahal]

What about --no-message? Fits nicely with --message and avoids the inconsistencies (both internal and external) raised above. One con I can think of is that if a message already exists, users might think it's meant to reset it to an empty one.

[arxanas]

Yeah, to me it feels like it's intended to discard the existing message, not suppress editing of the message.

[ahal]

--no-edit-message? It's verbose but this flag feels super uncommon anyway shrug

[jennings]

This is probably a dumb idea:

jj describe --interactive
jj describe -i

jj describe --no-interactive
jj describe -n         # I'm not sold on this short flag

[arxanas]

Technically speaking, there's no requirement that the editor program is interactive, but maybe it's not a meaningful distinction in practice. I guess there's no requirement that a diff editor for jj split -i is interactive, either.

[senekor]

I'm personally not in favor. To me, it seems clear and intuitive that in the context of jj describe, the --no-edit flag refers to the commit message. Natural language has a lot of context dependent terms and ours brains are good at dealing with that.

As mentioned, changing it now is breaking scripts, forces people to relearn habits and introduces a difference to other tools like git. All of these are costs we may be willing to pay if the benefit is worth it, but I don't see the benefit here.

I commented here that I'm not convinced that jj describe should have a flag that behaves like --edit. I agree that if such a flag is added, the benefit of renaming is greater, because jj describe --edit is weird.