From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#12159: 24.1.50; vc-dir: Need a way to hide unregistered files Date: Sun, 12 Aug 2012 18:35:54 -0400 Message-ID: References: <87pq71i7fy.fsf@gmail.com> <87d3312p4f.fsf@gmail.com> <871ujdpbqp.fsf@gmail.com> <87boigj2ti.fsf@gmail.com> <87zk60hqnv.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344810999 942 80.91.229.3 (12 Aug 2012 22:36:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Aug 2012 22:36:39 +0000 (UTC) Cc: 12159@debbugs.gnu.org To: Jambunathan K Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 13 00:36:40 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T0glz-0004bf-AH for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Aug 2012 00:36:39 +0200 Original-Received: from localhost ([::1]:54499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0gly-0005dY-5V for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 Aug 2012 18:36:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0glv-0005dI-QG for bug-gnu-emacs@gnu.org; Sun, 12 Aug 2012 18:36:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0glt-0001on-Kd for bug-gnu-emacs@gnu.org; Sun, 12 Aug 2012 18:36:35 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0glt-0001oR-H5 for bug-gnu-emacs@gnu.org; Sun, 12 Aug 2012 18:36:33 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T0gu5-0007Uo-OC for bug-gnu-emacs@gnu.org; Sun, 12 Aug 2012 18:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Aug 2012 22:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12159-submit@debbugs.gnu.org id=B12159.134481146728760 (code B ref 12159); Sun, 12 Aug 2012 22:45:01 +0000 Original-Received: (at 12159) by debbugs.gnu.org; 12 Aug 2012 22:44:27 +0000 Original-Received: from localhost ([127.0.0.1]:52035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0gtX-0007Tp-03 for submit@debbugs.gnu.org; Sun, 12 Aug 2012 18:44:27 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:16812) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0gtU-0007Ti-RW for 12159@debbugs.gnu.org; Sun, 12 Aug 2012 18:44:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxKJq/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUDQsNJBOIAAMGBbAqDYlSihqGKgOgEoMhgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="195540348" Original-Received: from 69-196-162-106.dsl.teksavvy.com (HELO pastel.home) ([69.196.162.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Aug 2012 18:35:55 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F040759305; Sun, 12 Aug 2012 18:35:54 -0400 (EDT) In-Reply-To: <87zk60hqnv.fsf@gmail.com> (Jambunathan K.'s message of "Mon, 13 Aug 2012 00:41:00 +0530") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63084 Archived-At: I'm really sorry you feel so frustrated. All the process (from my point of view) is trying to get the patch to be as simple and clean as it can be. First by changing the actual behavior, then by getting the details of the code right (hence my last hunk-by-hunk comments). This last message should have admittedly started with encouraging words rather than dryly jumping into the nitpicking without even warning that these are nitpicks. Hopefully the end result should be a patch of barely 10 lines including context, so while you may find it frustrating to go through this ordeal for such a tiny change, I see it as a great success to bring down the original request to such a simple change. > Reviewers have infinite time to review the patch. I don't know of any reviewer with infinite time, but if you find one, please send him up here, we'd love to have one of those. Stefan >>>>> "Jambunathan" == Jambunathan K writes: > I wish reviewers provide feedback which is comprehensive right from the > word go. Let me explain ... > When I submitted my patch it was complete i.e., I did not present it > hunk-by-hunk. I re-worked the patch based on feedback and I have > demonstrated some seriousness in making the patch acceptable. > Unfortunately, the review process here seems to have gone by "hunk by > hunk" mode. A small note here, a small note there. For something as > simple as this patch, why should we have 100 exchanges? > I can't care less if you call my patch a crap or hold an opinion that I > should never enter a programmer's territory. It is not what I am > talking about. > Reviewers have infinite time to review the patch. Let them collect > their notes and give a comprehensive list of what they think is > acceptable to them. > I hope I am not placing an un-reasonable demand. > We are talking of an implicit social contract that reviewers and patch > submitters should adhere to. Unfortunately, it is only the patch > submitters end of the contract that gets much emphasis. > Jambunathan K. >>> + * vc/vc-dir.el (vc-dir-hide-these-states): New custom variable. >> >> Don't bother. Just always default to up-to-date. >> >>> +(defun vc-dir-hide-some-states (&optional states) >> >> Make it `state' and not a list. >> >>> + (interactive >>> + ;; Interactive use. >> >> Redundant comment. >> >>> + ;; Non-interactive use. >>> + (unless (called-interactively-p 'any) >>> + (setq states (or states vc-dir-hide-these-states))) >> >> The test is wrong (it prevents non-interactive use where you specify >> the state explicitly). >> The above should simply be (unless state (setq state 'up-to-date)). >> >>> +(defun vc-dir-hide-up-to-date () >>> + "Hide up-to-date items from display." >>> + (interactive) >>> + (vc-dir-hide-some-states '("up-to-date"))) >> >> Why bother? >> >> >> Stefan