Results of C-x C-q poll

[Andre Spiegel <spiegel@gnu.org>]

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.