On Thu, Aug 29, 2013 at 12:31:41PM -0400, Tom Davis wrote:
> [email protected] writes:
> > On Thu, Aug 29, 2013 at 10:13:31AM -0400, Tom Davis wrote:
> >> [email protected] writes:
> >> > On 27 August 2013 14:40, Phil Jackson <[email protected]> wrote:
> >> >> Hey all,
> >> >>
> >> >> When I wrote the current menu-popup system in Magit I implemented
> >> >> a popup for commiting just like the one that's been built
> >> >> here. People were generally happy with the popup menus elsewhere
> >> >> but I pulled it out of commit because there was so much
> >> >> resistance.
> >> >>
> >> >> Before I quit Magit I had intended to keep the current workflow
> >> >> but have a slightly nicer implementation of the
> >> >> header-for-options system that served us reasonably well for all
> >> >> this time.
> >> >>
> >> >> My two cents; I'm not sure I like the new way. I find the menu is
> >> >> obstructive in this instance.
> >> >
> >> > Agreed Phil. The most common commit use case by far is surely "commit
> >> > without needing any special options", so to always pop up a menu
> >> > offering options is suboptimal for the majority of cases. Presumably
> >> > this is why there was so much resistance when you first introduced it.
> >>
> >> Overall I'd call it a great addition despite the annoyance of having to
> >> hit "c c" because, for the times when I *did* need options, I simply
> >> couldn't use magit at all for that commit.
> >
> > Why not?
>
> Because when you need to pass "-n" to "git commit" and you can't, you
> can't commit.
I see. I never needed that personally, but totally understand ;-)
> >> There are definitely still
> >> bugs (first line of commit message is in the wrong place, the commit
> >> buffer doesn't close when the commit finishes, etc.) but all of these
> >> are minor compared with the use cases enabled by the new commit
> >> mechanism.
> >
> > Which new use cases? I guess there are some which I missed. But even
> > so, that does not in itself justify introducing a popup menu, because
> > surely the new use cases could have been added to the old style of
> > interface?
>
> Perhaps, but the header-style interface to commits was different from
> all other commands that include options, AFAIK.
True, but we shouldn't let the quest for consistency get in the way of
the quest for the best interface :-)
> Discovery is also a concern; if you add, e.g., "C-c C-n" as another
> commit header thingy, the only way to find that would be via the
> mode help. Hell, maybe it did get added and I never knew ;)
That's a very good point. However, it should be easy to discover such
things by reading the manual, and prioritising catering for newbies
over catering for experienced users is a slippery slope. Almost by
definition, anyone who uses git + emacs + magit is an advanced user
who is likely to invest time in learning their tools properly ;-)
I think the most telling evidence is that Phil mentioned he already
added a popup menu for commit in the past, but then had to withdraw it
due to large resistance. Surely we can learn from previous
experiences?
That said, the ideal world would be a M-x customize-option allowing a
choice between `c' immediately progressing to the commit buffer, or
popping up a menu. If that existed, I wouldn't really mind what the
default setting was :-) This is very similar to the request here:
https://github.com/magit/magit/issues/826
although personally I would prefer to see both options use
git-commit-mode. Having to maintain two separate commit modes
indefinitely would seem like the worst possible outcome.
--
---
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
