From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: checkdoc-batch.el v.3 Date: Wed, 12 May 2010 21:38:59 -0400 Message-ID: <4BEB5833.40805@siege-engine.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1273721498 4605 80.91.229.12 (13 May 2010 03:31:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 13 May 2010 03:31:38 +0000 (UTC) Cc: Kevin Ryde , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 13 05:31:36 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OCP8e-0001c5-Dc for ged-emacs-devel@m.gmane.org; Thu, 13 May 2010 05:31:32 +0200 Original-Received: from localhost ([127.0.0.1]:37404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCP8a-0002TM-L0 for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 23:31:04 -0400 Original-Received: from [140.186.70.92] (port=43303 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCOvu-0001ou-2v for emacs-devel@gnu.org; Wed, 12 May 2010 23:18:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCNMk-00008b-JF for emacs-devel@gnu.org; Wed, 12 May 2010 21:37:36 -0400 Original-Received: from bird.interbax.net ([75.126.100.114]:37812) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCNMk-00008I-Dy for emacs-devel@gnu.org; Wed, 12 May 2010 21:37:34 -0400 Original-Received: (qmail 26328 invoked from network); 12 May 2010 20:37:31 -0500 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 12 May 2010 20:37:30 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124732 Archived-At: Hi, I missed the first post, and perhaps I have misinterpreted what the original post was. On 05/12/2010 11:10 AM, Stefan Monnier wrote: >> This spot of code runs M-x checkdoc in "batch" style, giving a report of >> problems instead of going through interactively fixing them. > > This sounds desirable. If you pass a prefix argument to checkdoc-current-buffer, and a couple other functions, it logs all the messages to a buffer. If you are instead discussing the doc strings in the C code, here is some code I posted a long time ago: http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg00760.html >> The implementation is diabolical, > > That sounds less so. > > I generally like checkdoc, but it's too much in-your-face for my taste. I have found that once code is clean, checkdoc doesn't complain. If it does I fix the code and it stops complaining. If you work constantly in non-compliant code, this would indeed be a pain. Checkdoc follows a model similar to unit tests for your C code. If a test fails, the build fails, and you have to fix it or you can play with your change. Of course, you can always set the checkdoc-autofix-flag to 'never, which won't ask you questions. I don't really remember what it would do. > If you're interested, it would be wonderful if you could change it so it > doesn't signal errors all the time, but just messages/warnings instead. > > The intention would be: > - make it possible/bearable to enable checkdoc-mode unconditionally > (so M-C-x will always check your docstrings, whether you want it or > not, which clearly requires reducing substantially the > in-your-faceness factor). See above. > - solve the problem you mention that rejecting one suggestion can make > you miss subsequent ones. Using the log mode I mentioned above solves this. Eric