On Fri, Aug 30, 2013 at 04:09:21AM +0200, Óscar Fuentes wrote:
> I strongly oppose this change. For committing 99% of the time you want
> what now is `c c' but for other commands (log, branch) it is common to
> use a command variant (actually, `b' is a gateway for a group of
> different commands.) Pressing `C-u b v' for entering the branch manager
> or `C-u l L' for Long Log is anything but efficient.
>
> The key-groups
> design already allowed for the "most common variant" by assigning it the
> same letter as the key-group trigger (`l l', `b b', etc.) This
> introduced a negligible delay in exchange for lots of flexibility and
> grow space.
>
> Seriously, I can't see what's so inefficient with pressing an extra `c'
> for committing. Two tenths of a second for an operation that culminates
> a task that typically takes a minimum of several minutes? C'mon!
>
> It is true that `c c' faced enough resistance to ditch it. But the whole
> key-groups feature faced that same resistance and it survived, simply
> because Magit was running out of keys and there was a nightmare of
> command-prefix tricks (uh!) for accessing just a few of the most common
> options (all the rest be damned, as well as their combinations.) It
> could be said that `c c' was reverted to plain `c' just because
> committing has no variants (as logging does) and the options for `git
> commit' were not popular enough.
I agree that a popup menu is much nicer than arcane prefix tricks.
For me, the big issue is not so much whether it is required to press
`c' once or twice, since that's mainly a muscle memory thing which can
be re-learned. The real issue is how magit invokes git. Triggering
emacsclient via git commit *before* the user starts composing the log
message creates all kinds of problems, some of which are detailed in
the issue I filed yesterday:
https://github.com/magit/magit/issues/827
These issues could perhaps be characterized by observing that the new
commit workflow sets an expectation that once the commit log buffer
opens for editing, magit expects that you will complete or abort the
commit before you do *anything* else. In other words, it's a bit like
popping up a modal dialog box which stops you interacting with any of
the windows behind it, except it's worse, because in this case it
*doesn't* stop you switching windows even though that can result in
broken behaviour.
The emacs UI is famously non-modal in design, and this is a Good
Thing. For example, read what Steve Yegge has to say about dialog
boxes in item 6 of this article:
https://sites.google.com/site/steveyegge2/effective-emacs
I guess these considerations are probably the root cause of my
instinctive "ugh" reaction to the use of emacsclient. Using
emacsclient to invoke emacs from within emacs just seems pretty insane
to me - an ugly hack done to avoid some cleaner solution. It's a bit
like some kind of network-based daemon which talks to itself via TCP.
(No doubt someone will now produce a counter-example where this is
actually a good idea ;-)
Like Marius points out, if you want git to prepare the content of the
commit message, that can be done by piping "git commit --dry-run" into
the buffer. So I simply don't understand the motivation for using
emacsclient and this pseudo-modal approach. What am I missing?
Whilst the commit log buffer is pseudo-modal, the popup menus are also
modal - even more so. Ideally that should be fixed in the future so
that the popups appear in a 1st class buffer and do not stop you
performing other operations whilst a popup menu is visible. But IMHO
this is not too evil as it stands right now for tasks like 'push'
which cannot possibly proceed without specifying further parameters
for how the push should be done.
--
---
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.
