From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andre Spiegel Newsgroups: gmane.emacs.devel Subject: Results of C-x C-q poll Date: 30 Jun 2002 19:48:10 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <1025459292.4840.7.camel@eagle> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1025459498 16422 127.0.0.1 (30 Jun 2002 17:51:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 30 Jun 2002 17:51:38 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17OirK-0004Gl-00 for ; Sun, 30 Jun 2002 19:51:38 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17OivT-0002qm-00 for ; Sun, 30 Jun 2002 19:55:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Oiqv-00054g-00; Sun, 30 Jun 2002 13:51:13 -0400 Original-Received: from [194.73.242.30] (helo=wmpdrc02-app.mail-store.com) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17Oio4-0004n0-00 for ; Sun, 30 Jun 2002 13:48:16 -0400 Original-Received: from localhost.localdomain ([213.182.137.210]) by wmpdrc02-app.mail-store.com (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20020630174753.RMIH24519.wmpdrc02-app.mail-store.com@localhost.localdomain> for ; Sun, 30 Jun 2002 18:47:53 +0100 Original-To: emacs-devel@gnu.org X-Mailer: Ximian Evolution 1.0.7 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5275 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5275 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 . 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 ). It stimulates people to use version control, says Johan Vromans , 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 ). Perhaps the best explanation in favour of option (1) is what Ben Mesander 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 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 says that he is not an Emacs expert, and doesn't want to "bump into strange commands" by accident. Hallvard B Furuseth 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 , and Samuel Mikes ). 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 suggests that it should go on C-u C-x C-q, seconded by chad . Don Bashford 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 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 , Ben Mesander , Francesco Potorti` , and Jay Berkenbilt . The full replies are accessible for all who have fencepost accounts, under /com/archive/emacs-vc-poll.