[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 1649 - trunk/subversion/libsvn_client trunk/subversion/clients/cmdline

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-04-09 19:53:45 CEST

cmpilato@collab.net writes:
> > I'm with Ben here.
> For what it's worth, I'm with Ben, too, so long as we have a config
> option for disabling pop-up editors. If that is in place, I'm fine
> with VI/NOTEPAD as defaults (though I really think they should be in
> the svn_private_configs.h/.hw files as a compile time #define,
> something like SVN_DEFAULT_TEXT_EDITOR or something).

Sorry, still a strong -1 on defaulting to vi/notepad.

First: the claim that "10 million other programs on Unix" pop up
editors is not really true. Maybe there are zillions of such
programs, but they are not commonly used programs. Except for CVS, I
don't recall ever running into one, in more than 10 years of almost
daily Unix use.

Another bit of evidence contributing to my opinion is: I've helped
train tons of newbie CVS users, and by far the most common reaction to
editor pop-up is confusion. "Why did it do that? I just wanted to
commit something!" (And a user who is surprised by this is *not*
going to know what to do when confronted with vi, let's face it. The
failure mode here is awful because it targets precisely the people
least likely to have the experience to handle it.)

Mike Pilato's initial reasoning was spot on: if people's environment
indicates that they have a default editor for such situations (and
we'll just have to trust $EDITOR here), then we pop it up. If there's
no such indication, then we error out, and the error explains the
various ways (including $EDITOR) that one can specify a log message.

This is preferable because it doesn't leave the user in a "state" that
they then have to get out of before they feel safe. Seeing an error
on your screen may be a surprise, but you know what to do -- namely,
read it -- and in the meantime, you've got your prompt back (by
prompt, I just mean "your prior state", IOW, this reasoning applies to
GUIs as well). Whereas having an editor pop up in your face means you
don't necessarily know what to do next. Something truly unexpected
has happened, and now you'll have to spend an arbitrary amount of time
figuring it out. Blecch.

Tossing people into that kind of state is exactly what makes computers

It's irrelevant to offer a configuration option for turning off pop-up
behavior. If a person knew enough to set that option, then they'd
probably know enough not to be bothered by pop-up behavior. But we
need a default behavior that works for people who *don't* know about
this whole question.

(This doesn't mean that such a config option is a bad idea. Users who
know the available options may still want to suppress pop-up behavior.
All I'm saying is that the config option is useless *as a solution for
those who don't already know*, and therefore this discussion must
still be about the right default behavior.)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 9 19:49:01 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.