Results of C-x C-q poll

Results of C-x C-q poll

[Andre Spiegel]

Here are the results of the poll on C-x C-q.  For your reference,
this was the text of the poll:

    Should C-x C-q do version control operations?

    The key C-x C-q's primary meaning is to toggle the read-only status of
    a buffer.  When the buffer visits a file under version control, C-x
    C-q also checks the file in or out (vc-toggle-read-only).  This
    feature was designed so that you cannot accidentally edit a file
    without properly checking it out from the version control system.

    Arguably, this feature makes sense for version control backends such
    as RCS where the version control state is tied to whether a file is
    writable or not.  It makes less sense for CVS, at least in its default
    mode, where working files are always writable anyway.  So we are
    considering changing it.

    Here are three alternatives we are considering.  In your reply, please
    indicate which of these you would prefer, and, most importantly, why
    you think so.

    The options are:

      (1) For a file under version control, let C-x C-q check it in or
          out. [The present behavior.]

      (2) Let C-x C-q check a file in or out, but only if it is under
          version control AND its version control state is reflected in
          its file permissions (as with RCS in its default mode, and CVS
          when the CVSREAD variable is set).

      (3) Remove the version-control meaning of C-x C-q, so that it only
          controls the buffer read-only flag and never does check-in or
          check-out.

    Please start your reply with the sentence "I prefer option (x).",
    where x is 1, 2, or 3.  Then, please explain your reasons for this
    preference.  Please also describe the concrete situations where you
    find it convenient.  We are not going to make our decision by simply
    counting "votes"; we want to see what we can learn from the reasons
    that people report.

    Feel free to propose another alternative if you think it would
    be better than those three.

                                * * *

We received 47 replies.  I'll start with the plain numbers, and then
give a more detailed analysis of the reasons people reported.

        (1)   18 replies   (38%)

        (2)    9 replies   (19%)

        (3)   20 replies   (43%)

The general picture is that people are about evenly split, with a
slight majority of those who want to keep the present behavior
(option 1), possibly in a modified form (option 2).  However, those
who *don't* want a version control meaning for C-x C-q are a
non-negligible (and vocal) group, too.

Many people also gave secondary preferences.  Of those who preferred
option (1), 7 people (38%) said that option (2) would also be fine
for them, while 2 people (11%) had reservations about (2), and one
person (6%) explicitly didn't want (2).

None of those who preferred option (2) gave a secondary preference.

Among those who preferred option (3), 5 people (25%) said they do want
a warning or a question in the minibuffer when they use C-x C-q on a
version-controlled file.

So, taking these secondary preferences into account, we see that
there is considerable overlap between those who prefer options (1) or
(2), and there are actually more users who would be happy with (2)
than what the primary preferences suggest.  On the other hand, among
those who prefer option (3), there is a considerable group that does
not want C-x C-q to be totally independent from version control; they
at least want a warning message or a question in the minibuffer.

Let's look at the reasons that people gave for their preference.

Among those who want option (1), several said that they are used to
the existing behavior, and don't see anything fundamentally broken
with it (4 people, 22% of those who want option (1)).  "Don't fix it
-- it isn't broken," says Jeff Mincy <jeff@delphioutpost.com>.

However, there is a much larger group that likes the C-x C-q binding
very much, not just out of habit, but because of its elegance (7
people, 39%).  They find the relation between version control state
and read-onlyness appealing, to the point of being "addictive" (Simon
Josefsson <jas@extundo.com>).  It stimulates people to use version
control, says Johan Vromans <jvromans@squirrel.nl>, and he finds it
makes it "soooo easy" to use CVS/RCS for everything.  Two people
simply seconded that particular response.  "Checking files in/out is a
breeze this way" (Stephen Eglen <eglen@pcg.wustl.edu>).  Perhaps the
best explanation in favour of option (1) is what Ben Mesander
<bam@dimensional.com> writes:

   Binding checkin/checkout to to C-x C-q makes the file's version
   control state clearly visible in the modeline, and makes it trivial
   to modify it.  It also makes using CVSREAD completely transparent
   to the user, and has allowed me to convince other developers to use
   it, since it is so simple and intuitive (file is read only, use C-x
   C-q to make it writeable is easy to remember for an emacs user,
   because of the other meaning, toggle-read-only). Since we've all
   started using CVSREAD along with C-x C-q, our number of CVS
   conflicts has fallen to practically zero.

Of those who prefer option (2), most people say they agree that the
existing binding doesn't make sense for CVS in its default mode, but
they want to retain it for the cases where it does make sense.  Other
users are concerned that (2) is too complicated, and that Emacs might
sometimes get the condition wrong (5 people, 11% of all replies).

Those who prefer option (3) generally say that they sometimes want to
change the read-only flag of a buffer without actually doing a version
control operation.  Four people (20%) say that they want to protect
themselves against accidentally modifying a file, and one user says
that he sometimes wants to make temporary changes to a file without
checking it out.  Six users (30%) simply say that they want
independent control of a buffer's read-only state.  Jay Berkenbilt
<ejb@ql.org> gives examples for both directions (make a writable
buffer read-only and vice versa) and adds:

  Just like some people prefer to declare variables const if they are
  not going to modify them, some people, myself included, prefer to
  make buffers I don't intend to edit explicitly read-only. [...]

  When my brain wants to tell emacs to make a buffer writable, that
  should translate into a different set of key sequences from when it
  wants to tell emacs to check in or out a file.

There is another group of people that don't like the inconsistency
between buffers with and without version control.  They often use C-x
C-q to change a buffer's read-only flag, and they are confused or
annoyed when it does something different if a file happens to be under
version control.  Lane A. Hemaspaandra <lane@cs.rochester.edu> says
that he is not an Emacs expert, and doesn't want to "bump into strange
commands" by accident.  Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
writes:

  I've always used C-x C-q to protect myself against accidentally
  modifying a file -- in particular files that are not mine.  The
  current behaviour does nearly the exact opposite, and it doesn't
  even make the buffer read-only.

Two users add that on a file under remote CVS control, an accidental
C-x C-q can cause Emacs to hang when they are offline (Michael Sperber
<sperber@informatik.uni-tuebingen.de>, and Samuel Mikes
<smikes@cubane.com>).

Several people also say that it is bad practice to put two related,
but distinct functions onto a single key stroke; commands should do
one thing, and do it well (4 people, 9% of all replies).

Independent of their preference, 5 users (11% of all replies) say that
they want a separate key stroke that only controls a buffer's
read-only flag.  Kim F. Storm <storm@cua.dk> suggests that it should
go on C-u C-x C-q, seconded by chad <y@mit.edu>.  Don Bashford
<bashford@scripps.edu> protests against this, saying that it breaks
the principle that C-u is an argument passing mechanism.

On the other hand, three users (6%) say that they rarely, if ever,
need a plain toggle-read-only, and for those few cases, they are
content to access it with M-x.

On a related note, it is noteworthy that several users suggest to have
a separate key stroke for plain check-in/out, not being aware that
this is already bound to C-x v v (4 users, 9%).  This may be due to
the fact that C-x C-q is advertized in the documentation as the main
version control command, and C-x v v is only marginally mentioned.
Paul Eggert <eggert@twinsun.com> stresses the need for this, saying "I
want my fingers to get used to a single way to check files in and out,
regardless of version control method."

Several users have written quite elaborate replies, analyzing the
situation from both practical and abstract perspectives.  I have
integrated their conclusions into my analysis above, but for those who
are interested, it may be worthwhile to have a separate look at these
replies: Jeff Mincy <jeff@delphioutpost.com>, Ben Mesander
<bam@dimensional.com>, Francesco Potorti` <pot@gnu.org>, and Jay
Berkenbilt <ejb@ql.org>.  The full replies are accessible for all who
have fencepost accounts, under /com/archive/emacs-vc-poll.

Re: Results of C-x C-q poll

[Richard Stallman]

It seems to me that the solution of making C-x C-q do
toggle-read-only, and having it print a message in the case of a
VC-controlled file, does the best to satisfy all the various wishes
users expressed.

Re: Results of C-x C-q poll

[Andre Spiegel]

On Mon, 2002-07-01 at 16:10, Richard Stallman wrote:

> It seems to me that the solution of making C-x C-q do
> toggle-read-only, and having it print a message in the case of a
> VC-controlled file, does the best to satisfy all the various wishes
> users expressed.

What if we make this the default, but add an option that lets you have a
stronger binding (ask a question, or do check-in/out without asking)?  I
think that would be important for those who like the existing binding
very much.

Re: Results of C-x C-q poll

[Richard Stallman]

    What if we make this the default, but add an option that lets you have a
    stronger binding (ask a question, or do check-in/out without asking)?

It seems like creeping featurism, and unnecessary, and potentially
quite annoying.  People who want to do it the other way can rebind C-x
C-q to vc-toggle-read-only.

Re: Results of C-x C-q poll

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> It seems to me that the solution of making C-x C-q do
> toggle-read-only, and having it print a message in the case of a
> VC-controlled file, does the best to satisfy all the various wishes
> users expressed.

More than half of those who responded prefer the existing behaviour,
so I don't see how removing the functionality will satify their
wishes.  I didn't see any clear conclusion from the poll, except
that people disagree on this feature.

IMO, the compromise solution must be to make this configurable:

- C-x C-q is option (3), but warns if VC-controlled file
- C-x C-q is option (2) [only if CVSREAD=y] *)
- C-x C-q is option (1) [current behaviour] *)

*) But C-u C-x C-q still just does toggle-read-only.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Results of C-x C-q poll

[Alan Shutko]

storm@cua.dk (Kim F. Storm) writes:

> - C-x C-q is option (2) [only if CVSREAD=y] *)

Note that you can also do "cvs watch on <file>", so ideally it should
check that as well as CVSREAD.  (I think this is more important than
CVSREAD, since afail CVSREAD doesn't do anything respository side when
you C-x C-q right now, but with cvs watch it'll execute cvs edit and
notify watchers.)

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
You will obey or molten silver will be poured into your ears.

Re: Results of C-x C-q poll

[Andre Spiegel]

On Mon, 2002-07-01 at 22:26, Alan Shutko wrote:

> Note that you can also do "cvs watch on <file>", so ideally it should
> check that as well as CVSREAD.  (I think this is more important than
> CVSREAD, since afail CVSREAD doesn't do anything respository side when
> you C-x C-q right now, but with cvs watch it'll execute cvs edit and
> notify watchers.)

VC should handle "cvs watch" fine already.  I'm aware of this feature. 
When I say CVSREAD, that is just an example of those modes where you
must issue a VC command before you can edit the file.  VC should
recognize all of them correctly.  If it doesn't, that is a bug.

Re: Results of C-x C-q poll

[Richard Stallman]

    More than half of those who responded prefer the existing behaviour,
    so I don't see how removing the functionality will satify their
    wishes.

Each alternative, including the status quo, was disliked by more than
half the respondents.  People advanced various reasons for what they
liked or disliked, showing us various kinds of problems in various
situations.  These problems are all different--they have different
severity.  The point here is to choose something that leaves the
smallest remaining problems, and in fewer cases.  The solution I
stated appears to be that.

In years of experience I've found that "let's give the user an option"
often acts as an easy way out, a way to avoid thinking hard about
doing the right thing by default.  Therefore I'm on guard against it;
I resist the pressure and insist on continuing to work on a good
default that will mean not so many people need to customize it.

In this case, "make it configurable" is not just a way of avoiding the
issue, it is a no-op.  This is already configurable; you can bind C-x
C-q to toggle-read-only or vc-toggle-read-only.  Providing a good
default is the only issue here.

Re: Results of C-x C-q poll

[Stefan Monnier]

> Here are the results of the poll on C-x C-q.  For your reference,
> this was the text of the poll:

Interesting reading.
I think that if we're going to change C-x C-q so as not to be completely
linked to VC, we should keep some link between the two.

Some people suggested to print a message when invoking C-x C-q
in a VC-controlled file.  I think it's a good idea.

In my case, I think I'd be even more happy if I could make C-x C-q
do the checkout if:
- the buffer was read-only (i.e. we're making the buffer readable)
- the file was in the `up-to-date' state

I don't actually need the C-x C-q to do the checkin (aka commit).

But then again, maybe just popping a message is enough,
and I'll just have to get used to hitting `C-x v v' (instead of
C-x C-q) in order to make my VC-controlled buffers writable.


	Stefan

Re: Results of C-x C-q poll

[Andre Spiegel]

On Sun, 2002-07-07 at 00:04, Stefan Monnier wrote:

> But then again, maybe just popping a message is enough,
> and I'll just have to get used to hitting `C-x v v' (instead of
> C-x C-q) in order to make my VC-controlled buffers writable.

I will install such a change.  Although I like the C-x C-q binding very
much, I think I have to agree with Richard that removing it (and only
displaying a message) is the solution that does the best to reconcile
the conflicting opinions.

For those die-hard C-x C-q users (and I'm one of them), there will still
be the option to bind it to vc-toggle-read-only, which will continue to
exist.

Re: Results of C-x C-q poll

[Kim F. Storm]

Andre Spiegel <spiegel@gnu.org> writes:

> On Sun, 2002-07-07 at 00:04, Stefan Monnier wrote:
> 
> > But then again, maybe just popping a message is enough,
> > and I'll just have to get used to hitting `C-x v v' (instead of
> > C-x C-q) in order to make my VC-controlled buffers writable.
> 
> I will install such a change.  Although I like the C-x C-q binding very
> much, I think I have to agree with Richard that removing it (and only
> displaying a message) is the solution that does the best to reconcile
> the conflicting opinions.
> 
> For those die-hard C-x C-q users (and I'm one of them), there will still
> be the option to bind it to vc-toggle-read-only, which will continue to
> exist.

That will be fine with me.

But what about my suggestion that C-u C-x C-q does just toggle-read-only
instead of the current behaviour which is also available on C-u C-x v v
in case it is needed (I rarely - if ever - needed it myself).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Results of C-x C-q poll

[Andre Spiegel]

On Tue, 2002-07-09 at 00:06, Kim F. Storm wrote:

> But what about my suggestion that C-u C-x C-q does just toggle-read-only
> instead of the current behaviour which is also available on C-u C-x v v
> in case it is needed (I rarely - if ever - needed it myself).

I do see some merit in this idea, but now that we've agreed on a
somewhat "minimalist" solution, I hesitate to change the old command as
well.  Some people surely won't like this, and we'll have another
discussion about a possible user option...

If we're resorting to global-set-key here, anyway, then I think a simple
solution for you would be to put vc-toggle-read-only on C-x C-q, and
plain toggle-read-only on C-c q or something that is equally easy to
type.

Thoughts?

Re: Results of C-x C-q poll

[Kim F. Storm]

Andre Spiegel <spiegel@gnu.org> writes:

> On Tue, 2002-07-09 at 00:06, Kim F. Storm wrote:
> 
> > But what about my suggestion that C-u C-x C-q does just toggle-read-only
> > instead of the current behaviour which is also available on C-u C-x v v
> > in case it is needed (I rarely - if ever - needed it myself).
> 
> I do see some merit in this idea, but now that we've agreed on a
> somewhat "minimalist" solution, I hesitate to change the old command as
> well.  Some people surely won't like this, and we'll have another
> discussion about a possible user option...

Ok.  I rest my case.

I can always defadvice vc-toggle-read-only to do what I want.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk